2^32 times the addressing space of 32 bit, so goodbye 4 gig limit.
Actually the Opteron uses 40 bit physical addressing and 48 bit virtual addressing (similar to the Alpha).
This will give you a cap of 1 TB of memory or 256 TB if you want to play funky software games.
And greater speed / precision ratio.
There is no inherent speed benefit to 64 bit computing (read: addressing). In fact there are some significant drawbacks when you are talking about applications that have complex data structures containing a lot of pointers (memory size increases).
Also, they have the exact same precision. You can do 64 bit integer math on a 32 bit CPU, it just takes a little longer if it doesn't have 64 bit registers.
MS will NOT be distributing a version of the CLR for *BSD or Linux.. I guaran-damn-tee it! Excepting other non-MS.NET implementations such as Mono, in order to put a CLR on the Opteron, MS will need an operating system to support it.
While this doesn't contain a good portion of the CLR libraries themselves, it does contain everything necessary to execute/compile it. The only thing that would be left is the icky task of porting CLR libraries that have native code in them (Windows.Forms).
The real question is what they want to use this title for. For a business card? For a resume? To explain what you do to the rest of the company? To explain what you do to the rest of the world?
Few have clear cut titles. Do you think "Software Developer" is specific or clear to anyone unfamiliar with you personally? What about "Product Development"? "Business Development"? In a big enough company these can mean pretty much anything.
So what do you say for your business card and resume? x Administrator or if you are in telecommunications you'd probably be a Technician. You have all sorts of space under your title on a resume to put descriptions; use it.
What do you have to explain what you do to the rest of the company? IT -> Department (Corporate, Internet, Service, etc.) -> Specialization (Systems, Network, Email, Security, UNIX, etc.) -> Administrator. Org charts don't work particularly well once you get to certain size, so invest in real people management software for goodness sakes.
What do you do to explain what you do to the rest of the world? Computer Infrastructure Management or just describe it for goodness sakes. "I make sure the email systems work."
Sure, just let me have the same amount of access to it as I have to Windows 2003 while installing it. Give me your key and access to your machine/network stream while you ssh out and I'll hand you the decrypted plaintext of your session.
Of course this has little to do with the security of this particular authentication mechanism which simply looks up a secret key in a database of issued to see if it is valid and has enough licenses available. Volume licensing is always the problem in this case.
Repeat after me: There is no such thing as security in an insecure environment.
Re:Open Source and DRM are fundamentally incompati
on
Open Source DRM
·
· Score: 1
That's a good point. But if you had some secure hardware like TCPA, open source DRM could work. What would happen is that the hash of your open source application gets reported to the remote system, using the secure hardware. If the hash is different from what it is supposed to be, then the remote system won't send you the data.
This is why you don't modify the application on disk. Instead you modify it at runtime or alternatively monitor the memory address where the decrypted frames are being read before being passed to the decompressor externally.
Heck you could even build a memory bus logger if the apps are run in some sort of protected VM to get access to the decrypted frames (once you figure out the offset that is).
But this is all really beside the point. People are willing to put up with the quality of radio, movies shot in theaters by digital cameras, horribly overcompressed digital cable tv and all sorts of other inferior media products. Somehow I doubt anyone is going to notice an extra A/D conversion done down the line to bypass all this silly DRM stuff with a $5 cable bought at radio shack.
When the weaknesses began to show in Napster's overly centralized model, Gnutella stepped in with a distributed, decentralized network.
The only weeknesses in Napster's model were legal. BitTorrent uses a model nearly identical to Napsters.
The "tracker" is akin to a Napster server that provides clients with a list of users who have a pariticular file. Sure they added a couple nice features like multi-source downloading, multiple file via single torrent and uploading before a complete download, but the network model is the same.
And can the sendmail developers be brave trailblazers and finally change the config file syntax to just text words like httpd.conf?
My main sendmail config file is a whole 32 lines long and includes SMTP authentication methods, blacklists, load avg checks, privacy options and of course the delivery mechanism.
The only thing I don't have that I've been thinking about adding is LDAP support, but that's only another line in my conf file and modification to where all the db maps point to.
I have trouble sharing your confusion in configuring something that needs so few options in a typical setup.
So beside the fact that sendmail is the standard, quite mature and very flexible if you know how to config it, does it have any big edge over postfix or qmail that everyone should know about?
Mmm, I would have thought being standard, mature and extremely flexible would be enough.
Just buy sendmail from sendmail.com if you don't know how to configure all those really advanced options like priority boosts for certain types of messages, different delivery paths based on if a message has attachments (virus scanners are too slow to handle all messages in big environments), quarantine of potential spam for manual review by administrators (very useful in companies), or manually tune outgoing queues to force sendmail to do MX lookups for up to 5 minutes 10 seconds before attempting to dequeue a message with more than 1000 addresses to reduce bandwidth usage (the same mail server handling multiple domains can send to two users using only one message body).
They give you a nice little GUI that makes everything nice and easy to configure. Not to mention a high availability solution and a stupidly high volume mail solution.
Having worked at companies that have outsourced from everything from local companies to German companies, I've found that outsourcing really does have its limits.
If you run a company that only needs small easily defined utilities to automate tasks and don't need them done immediately, outsourcing works very well.
However, if you run a company that needs to turn on a dime to enter new markets, exploit existing ones, handle complex B2B integration issues or have vague software requirements, outsourcing falls flat. Even if you are dealing with a company 20 miles away, the simple fact that the programmers there don't understand your business leads to design mistakes and missing features that a dedicated well trained programmer that spends his time thinking how to improve your business should have caught.
As businesses face stiffer competition in the world market and the complexity of the software systems they run increases, I believe they will find it harder and harder not to justify hiring local talent they can train to understand their business.
If anything, I believe the US needs to do two things to help slow the departure of development jobs:
First, we need to better educate programmers to make them more rounded. The better they understand the complexities of specific industries, the better they can anticipate the needs of their employeers. A developer should be positioned in a company to understand how it can improve, not be a monkey that hammers out what the business side of the company thinks it wants.
Second, we need to sell the benefits of hiring in-house programmers over outsourcing. Marketing is really something developers aren't particularly good at, but has to change.
Now this won't stop the migration of jobs to foreign countries, but it will assure that it is relegated only to simple grunt work keeping the highest paying skilled work at home.
That may be true, but the (de)marshalling routines were only about 100 lines long. I think if I have to implement all the callbacks and calls to the functions anyway, writing an extra 100 lines in another language for new marshalling/demarshalling routines is somewhat minor.
The XSLT transform was a little longer, but the modifications necessary to move it to another language are trivial. The benefit of not having all that overhead during runtime far outweighed the cost of development (which was about a day and a half).
Plus I can just reuse the code over and over for anything I choose, just define new commands in XML and away I go. Essentially it is nothing more than an XML version of IDL, but that's beside the point.:)
Repeat after me, XML is NOT a language. Certainly not in the sense that C++ is a language. XML is a standard that defines how one structures data.
No, it is a language like English is a language. It has a basic grammar and a small set of verbs (?xml, !entity, !doctype, etc). It is a definition language not a programming language, but a language just the same.
Anyone who has been programming for any length of time knows that while binary is more compact, it is less flexible and potentially more error prone. Want to add a new field in the middle of your data, boy you better not get your software versions mixed. Want to write an app that can do reasonably intelligent things with ANY data it recieves, binary is not the way to go.
This is completely based on the binary format and how you've implemented it, not an intrinsic characteristic of binary formats.
The last binary protocol I implemented was a simple hierarchial key based protocol with the protocol encoders/decoders functions generated via an XML definition and an XSLT transformation. It was essentially just a compacted binary form of XML, but without the parsing or size overhead. In fact, you could read the binary data and generate XML with it pretty easily (useful for visualizing the data being sent back and forth).
XML is great for a lot of things (storing structured data for long periods and still being able to read it 20 years from now being one of them), but don't think that binary is evil because of problems that exist with certain binary formats.
There's actually a good reason why that is true in many situations. The reason is that a JIT / interpreter can dynamically analyze and optimize the code. Think about it. A JIT is a compiler - just like a C/C++ compiler. But it compiles from (for example) Java bytecode to native code rather than from C/C++ source code to native code. Now, if it does the compilation before or while the program runs, like the Sun Hotspot Java VM does, then it can actually profile the compiled code and see where the "hot spots" are. That is, it can analyze which parts would benefit the most from optimization, and then optimize those parts much more than a normal C/C++ compiler would do, and with much more knowledge than a C/C++ can ever have.
Just a couple notes.
First, profiling compilers exist for C++. Intel's compiler is one of them. While it can only handle the general case, it is more than enough to optimize branch points, comparisons and what not.
Second, if Intel has its way with EPIC, branch prediction won't matter (EPIC just executes both branches at once) making the most important JIT optimization a moot point. EPIC also requires the compiler to handle a lot more of the optimization making it much harder to build JIT compilers.
Also keep in mind that many things that are done in high level languages like Java are actually done with native code. For example the graphics toolkit in Java is now hardware accelerated on Windows. So when you blit an Image to another, that's being done in hardware. This means that many things are "just as fast" in Java as in C/C++, because the part of the app that actually uses any considerable CPU cycles is exactly the same in Java as in a native application.
Except the overhead of the exception handling code, garbage collector, bound checking, abstracted memory, relatively huge number of objects (even compared to C++) and excessively long call depths in the standard library does in fact make it noticably slower than the C++ equivilent for any application does real work and GUI at the same time.
Look, languages for the most part don't matter. In time CPUs will get so stupidly fast that the cost trade off related to development and maintenance time won't make any sense for the bulk of the applications. A lot of business applications fall into this world right now which is why Java is so popular.
But to claim a language which has huge amounts of overhead related to bounds checking, garbage collection, exception handling etc. is just as fast a language without it is silly.
I've heard that the added water will raise combustion point of the gas and in some cars increase the percentage of fuel that is combusted. Pre-ignition is less likely to happen and the volitility of the gas is reduced requiring a higher temperature to ignite it.
This is essentially what higher octane fuels at gas stations do except instead of water they use other additives.
Actually Japan has very few old buildings. A huge number of them were leveled in WW2, major earthquakes like the one in 1923 and still more were lost to fire. This includes pretty much all major architectual landmarks as well as ordinary homes.
They were often rebuilt over the years in the same style so they "look" old. Osaka Castle for instance was originally built in 1586, but was destroyed in 1600. The castle was rebuilt and destroyed two more times. Finally in 1931 they rebuilt the castle from old paintings with concrete. The Imperial Palace was rebuilt 10 times due to fire and once due to being leveled in WW2.
Now that isn't to say there aren't any old buildings around, but it is nothing like say, China, Greece, Turkey, etc.
So does this tax apply to high-end business hardware too?
I'd hate to have to pay an extra $3.2 million for my brand new $20 million supercomputer because someone thought I was going to pirate music instead of model the weather.
These taxes really are silly. With Canada charging small-time independent musicians a hefty tax for CD media they use to distribute their own works to pay other artists to the US's piracy tax on DATs which are used almost exclusively by the IT world.
What is next? A per-kbps tax on internet connections because the media industries don't want to sue their own customers?
Is it just me, or does anyone else find it ironic that on the same page as this "How Hydrogen can Save America" article, there's a GIANT FUCKING AD FOR AN SUV
I'd like to point out that there are SUVs coming out that are more efficient than the vast majority of cars on the road. The size of SUVs makes them an easy target for hybrid engines and fuel cells.
For example, the 2003 Ford Escape HEV is a hybrid electric that gets 40 mpg and can still tow 1000 lbs behind it.
The 2005 GM Saturn Vue will supposedly get 40 mpg.
The 2004 Lexas RX 330 is another hybrid that is coming out. No hard numbers on fuel efficiency have been published though.
The Toyota RAV4 EV was an electric SUV, but was discontinued. There are some of them on the road though.
Now, I'm more woried about "mini"-vans than anything else. They are even less fuel efficient than SUVs and seem to be the Urban Assault Vehicle of choice among a lot of soccer moms.
Judging by my extremely small sample size, I'd say... you've got to be out of your mind. Sure, smarter people are worth more than dumber people, independent of their education. However, given two coders of equal intelligence/aptitude, the one with a good degree and 1 year of experience beats the hell out of the one with 5 years of experience.
Where to start, where to start...
First, realize that most programming jobs that exist out there in the world are to handle a particular task working in a legacy environment. When you get interviewed for a position like that, they are looking for someone who already knows the ins and outs of their particular environment not general "principles."
In this case, experience trumps all. If this job is working with Oracle working on system that uses Asynchronous Queues and connecting to an inhouse financials system, the guy who knows that system best gets the job.
The fact of the matter is that your resume will get filtered early on if you don't have the necessary experience with their legacy systems.
Second, your "equal intelligence" comment demonstrates that you've never tried interviewing a software engineer. It is extremely difficult to judge relative intelligence from a group of people with historically bad social skills. The best you can usually do in an interview is see if a person is capable of doing the job you want and judge how they solve problems.
Experience, with line items for achievements, can really help in this area simply because you can ask questions about their role and how they solved various issues and get them to open up.
Third, the idea of a "good" degree is terribly difficult to judge these days. Universities today hand out A's like candy and it possible to get a degree and still not know anything.
Finally, I would like to point out that the environment really matters. An established corporation will look much more kindly on a person with a degree and little experience than a startup or small business. This is especially true in the valley where startups simply don't have the money to spend training someone to have them jump ship for a higher paying job once they gain some experience.
At least we'll have the Platinum Edition, Superbit Edition, Limited Edition, Full Screen Edition, Widescreen Edition, Platinum Series Exteneded Edition, Collector's Edition, Boomstick Edition, Box Set, Unrated Edition, Criterion Edition, Ultimate Edition, 20th Anniversary Edition (in 20 years), Director's Cut, Deluxe Edition and of course this Super Collectors Special Edition to buy and enjoy!
There are a couple important notes about Serial-attached SCSI (SAS) that I think are important.
First, SAS uses a point-to-point topology similar to Serial-ATA instead of a shared bus like SCSI. This means each drive has access to full bandwidth, not just one (the bottleneck being the card itself).
Second, according to the SAS working group, SAS comes in three speeds; 150, 300 and 600 MB/s. I'm not sure where that 3 Gbps figure came from.
Third, unlike Serial-ATA or parallel SCSI, SAS is full duplex like fibre channel. This should have some interesting effects on latency.
Fourth, SAS uses the same physical connector as Serial-ATA and in fact can use Serial-ATA drives in legacy mode.
It think it is possible to move to a different protocol than SMTP by building a protocol over it, rather than throwing it out.
SMTP has evolved over the years for goodness sakes. It isn't like they wrote RFC821 and stopped.
Since The original SMTP RFC, there has been:
RFC 1425 - SMTP Service Extensions RFC 1426 - SMTP Service Extension for 8bit-MIMEtransport RFC 1427 - SMTP Service Extension for Message Size Declaration RFC 1652 - SMTP Service Extension for 8bit-MIMEtransport RFC 1845 - SMTP Service Extension for Checkpoint/Restart RFC 1869 - SMTP Service Extensions (ESMTP) RFC 1985 - SMTP Service Extensions for Remote Message Queue Starting RFC 2554 - SMTP Service Extensions for Authentication RFC 2821 - SMTP (Latest version of SMTP Apr 2001) RFC 3207 - SMTP Service Extension for Secure SMTP over Transport Layer Security
And it goes on and on and on and on.
Spam is tricky, but the average person can block most spam by filtering all messages from users not in their address book since the average grandma doesn't get messages from anyone but people she knows.
DVD, ATSC (US HDTV), ISDB (JP HDTV) and DVB (EU HDTV) all use MPEG-2, so it isn't much of a surprise that Blu-Ray uses it as well.
This is especially true when you factor in the cost of adding an MPEG-2 decoder chip anyway for DVD backwards compatibility and the general availability of high-quality MPEG-2 encoding hardware.
That is known as CLCC packaging. It was used for a couple versions of the Intel 80186 (made by AMD), Siemens 80286, Intel 80286 (made by AMD) and AMD 80286.
In addition, slot-based packaging (SEP, Slot-A, etc.) all used gold fingers just like PCI cards.
I don't understand why this is news or why it required any level of study.
The root servers handling zone '.' such as F.ROOT-SERVERS.NET put refresh periods of 48 hours on most every query. That means that at most once every 48 hours every name server on the planet should re-ask the root servers where to get answers for each of the gtlds, com, net, org, arpa, etc.
What they should receive the most queries for are domains that don't exist because everything else is cached for such a long period of time. That is the point of the root servers.
If the root servers are having trouble handling the query load then they should be upgraded for goodness sake. These are root servers after all and I think the global internet community could spare a few dollars to add some spare capacity if it is required.
To improve on this, BIND could up the maximum negative RR cache default time to live. Right now I believe it is set to 3 hours and the root servers use a 1 day SOA.MINIMUM instead, so BIND is always lowering it by default.
Of course, other nameservers are different. Some older versions of BIND by default only stored negative RR for 10 minutes.
Slashdot Mirror
2^32 times the addressing space of 32 bit, so goodbye 4 gig limit.
Actually the Opteron uses 40 bit physical addressing and 48 bit virtual addressing (similar to the Alpha).
This will give you a cap of 1 TB of memory or 256 TB if you want to play funky software games.
And greater speed / precision ratio.
There is no inherent speed benefit to 64 bit computing (read: addressing). In fact there are some significant drawbacks when you are talking about applications that have complex data structures containing a lot of pointers (memory size increases).
Also, they have the exact same precision. You can do 64 bit integer math on a 32 bit CPU, it just takes a little longer if it doesn't have 64 bit registers.
MS will NOT be distributing a version of the CLR for *BSD or Linux.. I guaran-damn-tee it! Excepting other non-MS .NET implementations such as Mono, in order to put a CLR on the Opteron, MS will need an operating system to support it.
Microsoft 'Shared Source' C# CLI for FreeBSD/MacOS X
While this doesn't contain a good portion of the CLR libraries themselves, it does contain everything necessary to execute/compile it. The only thing that would be left is the icky task of porting CLR libraries that have native code in them (Windows.Forms).
The real question is what they want to use this title for. For a business card? For a resume? To explain what you do to the rest of the company? To explain what you do to the rest of the world?
Few have clear cut titles. Do you think "Software Developer" is specific or clear to anyone unfamiliar with you personally? What about "Product Development"? "Business Development"? In a big enough company these can mean pretty much anything.
So what do you say for your business card and resume? x Administrator or if you are in telecommunications you'd probably be a Technician. You have all sorts of space under your title on a resume to put descriptions; use it.
What do you have to explain what you do to the rest of the company? IT -> Department (Corporate, Internet, Service, etc.) -> Specialization (Systems, Network, Email, Security, UNIX, etc.) -> Administrator. Org charts don't work particularly well once you get to certain size, so invest in real people management software for goodness sakes.
What do you do to explain what you do to the rest of the world? Computer Infrastructure Management or just describe it for goodness sakes. "I make sure the email systems work."
Sure, just let me have the same amount of access to it as I have to Windows 2003 while installing it. Give me your key and access to your machine/network stream while you ssh out and I'll hand you the decrypted plaintext of your session.
Of course this has little to do with the security of this particular authentication mechanism which simply looks up a secret key in a database of issued to see if it is valid and has enough licenses available. Volume licensing is always the problem in this case.
Repeat after me: There is no such thing as security in an insecure environment.
That's a good point. But if you had some secure hardware like TCPA, open source DRM could work. What would happen is that the hash of your open source application gets reported to the remote system, using the secure hardware. If the hash is different from what it is supposed to be, then the remote system won't send you the data.
This is why you don't modify the application on disk. Instead you modify it at runtime or alternatively monitor the memory address where the decrypted frames are being read before being passed to the decompressor externally.
Heck you could even build a memory bus logger if the apps are run in some sort of protected VM to get access to the decrypted frames (once you figure out the offset that is).
But this is all really beside the point. People are willing to put up with the quality of radio, movies shot in theaters by digital cameras, horribly overcompressed digital cable tv and all sorts of other inferior media products. Somehow I doubt anyone is going to notice an extra A/D conversion done down the line to bypass all this silly DRM stuff with a $5 cable bought at radio shack.
When the weaknesses began to show in Napster's overly centralized model, Gnutella stepped in with a distributed, decentralized network.
The only weeknesses in Napster's model were legal. BitTorrent uses a model nearly identical to Napsters.
The "tracker" is akin to a Napster server that provides clients with a list of users who have a pariticular file. Sure they added a couple nice features like multi-source downloading, multiple file via single torrent and uploading before a complete download, but the network model is the same.
EA games does make every game with the exception of all the good ones.
And can the sendmail developers be brave trailblazers and finally change the config file syntax to just text words like httpd.conf?
My main sendmail config file is a whole 32 lines long and includes SMTP authentication methods, blacklists, load avg checks, privacy options and of course the delivery mechanism.
The only thing I don't have that I've been thinking about adding is LDAP support, but that's only another line in my conf file and modification to where all the db maps point to.
I have trouble sharing your confusion in configuring something that needs so few options in a typical setup.
So beside the fact that sendmail is the standard, quite mature and very flexible if you know how to config it, does it have any big edge over postfix or qmail that everyone should know about?
Mmm, I would have thought being standard, mature and extremely flexible would be enough.
Just buy sendmail from sendmail.com if you don't know how to configure all those really advanced options like priority boosts for certain types of messages, different delivery paths based on if a message has attachments (virus scanners are too slow to handle all messages in big environments), quarantine of potential spam for manual review by administrators (very useful in companies), or manually tune outgoing queues to force sendmail to do MX lookups for up to 5 minutes 10 seconds before attempting to dequeue a message with more than 1000 addresses to reduce bandwidth usage (the same mail server handling multiple domains can send to two users using only one message body).
They give you a nice little GUI that makes everything nice and easy to configure. Not to mention a high availability solution and a stupidly high volume mail solution.
Having worked at companies that have outsourced from everything from local companies to German companies, I've found that outsourcing really does have its limits.
If you run a company that only needs small easily defined utilities to automate tasks and don't need them done immediately, outsourcing works very well.
However, if you run a company that needs to turn on a dime to enter new markets, exploit existing ones, handle complex B2B integration issues or have vague software requirements, outsourcing falls flat. Even if you are dealing with a company 20 miles away, the simple fact that the programmers there don't understand your business leads to design mistakes and missing features that a dedicated well trained programmer that spends his time thinking how to improve your business should have caught.
As businesses face stiffer competition in the world market and the complexity of the software systems they run increases, I believe they will find it harder and harder not to justify hiring local talent they can train to understand their business.
If anything, I believe the US needs to do two things to help slow the departure of development jobs:
First, we need to better educate programmers to make them more rounded. The better they understand the complexities of specific industries, the better they can anticipate the needs of their employeers. A developer should be positioned in a company to understand how it can improve, not be a monkey that hammers out what the business side of the company thinks it wants.
Second, we need to sell the benefits of hiring in-house programmers over outsourcing. Marketing is really something developers aren't particularly good at, but has to change.
Now this won't stop the migration of jobs to foreign countries, but it will assure that it is relegated only to simple grunt work keeping the highest paying skilled work at home.
Three more years until two of the three main Apple patents that cover hinting go away.
Three more long years. It actually might be 6 more years, but I'm not sure if that patent term extension from 17 to 20 years is retroactive or not.
To be honest though, I haven't heard of Apple suing anyone for infringing on that particular patent and I imagine quite a few people have.
That may be true, but the (de)marshalling routines were only about 100 lines long. I think if I have to implement all the callbacks and calls to the functions anyway, writing an extra 100 lines in another language for new marshalling/demarshalling routines is somewhat minor.
:)
The XSLT transform was a little longer, but the modifications necessary to move it to another language are trivial. The benefit of not having all that overhead during runtime far outweighed the cost of development (which was about a day and a half).
Plus I can just reuse the code over and over for anything I choose, just define new commands in XML and away I go. Essentially it is nothing more than an XML version of IDL, but that's beside the point.
Repeat after me, XML is NOT a language. Certainly not in the sense that C++ is a language. XML is a standard that defines how one structures data.
No, it is a language like English is a language. It has a basic grammar and a small set of verbs (?xml, !entity, !doctype, etc). It is a definition language not a programming language, but a language just the same.
Anyone who has been programming for any length of time knows that while binary is more compact, it is less flexible and potentially more error prone. Want to add a new field in the middle of your data, boy you better not get your software versions mixed. Want to write an app that can do reasonably intelligent things with ANY data it recieves, binary is not the way to go.
This is completely based on the binary format and how you've implemented it, not an intrinsic characteristic of binary formats.
The last binary protocol I implemented was a simple hierarchial key based protocol with the protocol encoders/decoders functions generated via an XML definition and an XSLT transformation. It was essentially just a compacted binary form of XML, but without the parsing or size overhead. In fact, you could read the binary data and generate XML with it pretty easily (useful for visualizing the data being sent back and forth).
XML is great for a lot of things (storing structured data for long periods and still being able to read it 20 years from now being one of them), but don't think that binary is evil because of problems that exist with certain binary formats.
There's actually a good reason why that is true in many situations. The reason is that a JIT / interpreter can dynamically analyze and optimize the code. Think about it. A JIT is a compiler - just like a C/C++ compiler. But it compiles from (for example) Java bytecode to native code rather than from C/C++ source code to native code. Now, if it does the compilation before or while the program runs, like the Sun Hotspot Java VM does, then it can actually profile the compiled code and see where the "hot spots" are. That is, it can analyze which parts would benefit the most from optimization, and then optimize those parts much more than a normal C/C++ compiler would do, and with much more knowledge than a C/C++ can ever have.
Just a couple notes.
First, profiling compilers exist for C++. Intel's compiler is one of them. While it can only handle the general case, it is more than enough to optimize branch points, comparisons and what not.
Second, if Intel has its way with EPIC, branch prediction won't matter (EPIC just executes both branches at once) making the most important JIT optimization a moot point. EPIC also requires the compiler to handle a lot more of the optimization making it much harder to build JIT compilers.
Also keep in mind that many things that are done in high level languages like Java are actually done with native code. For example the graphics toolkit in Java is now hardware accelerated on Windows. So when you blit an Image to another, that's being done in hardware. This means that many things are "just as fast" in Java as in C/C++, because the part of the app that actually uses any considerable CPU cycles is exactly the same in Java as in a native application.
Except the overhead of the exception handling code, garbage collector, bound checking, abstracted memory, relatively huge number of objects (even compared to C++) and excessively long call depths in the standard library does in fact make it noticably slower than the C++ equivilent for any application does real work and GUI at the same time.
Look, languages for the most part don't matter. In time CPUs will get so stupidly fast that the cost trade off related to development and maintenance time won't make any sense for the bulk of the applications. A lot of business applications fall into this world right now which is why Java is so popular.
But to claim a language which has huge amounts of overhead related to bounds checking, garbage collection, exception handling etc. is just as fast a language without it is silly.
I've heard that the added water will raise combustion point of the gas and in some cars increase the percentage of fuel that is combusted. Pre-ignition is less likely to happen and the volitility of the gas is reduced requiring a higher temperature to ignite it.
This is essentially what higher octane fuels at gas stations do except instead of water they use other additives.
Actually Japan has very few old buildings. A huge number of them were leveled in WW2, major earthquakes like the one in 1923 and still more were lost to fire. This includes pretty much all major architectual landmarks as well as ordinary homes.
They were often rebuilt over the years in the same style so they "look" old. Osaka Castle for instance was originally built in 1586, but was destroyed in 1600. The castle was rebuilt and destroyed two more times. Finally in 1931 they rebuilt the castle from old paintings with concrete. The Imperial Palace was rebuilt 10 times due to fire and once due to being leveled in WW2.
Now that isn't to say there aren't any old buildings around, but it is nothing like say, China, Greece, Turkey, etc.
So does this tax apply to high-end business hardware too?
I'd hate to have to pay an extra $3.2 million for my brand new $20 million supercomputer because someone thought I was going to pirate music instead of model the weather.
These taxes really are silly. With Canada charging small-time independent musicians a hefty tax for CD media they use to distribute their own works to pay other artists to the US's piracy tax on DATs which are used almost exclusively by the IT world.
What is next? A per-kbps tax on internet connections because the media industries don't want to sue their own customers?
Is it just me, or does anyone else find it ironic that on the same page as this "How Hydrogen can Save America" article, there's a GIANT FUCKING AD FOR AN SUV
I'd like to point out that there are SUVs coming out that are more efficient than the vast majority of cars on the road. The size of SUVs makes them an easy target for hybrid engines and fuel cells.
For example, the 2003 Ford Escape HEV is a hybrid electric that gets 40 mpg and can still tow 1000 lbs behind it.
The 2005 GM Saturn Vue will supposedly get 40 mpg.
The 2004 Lexas RX 330 is another hybrid that is coming out. No hard numbers on fuel efficiency have been published though.
The Toyota RAV4 EV was an electric SUV, but was discontinued. There are some of them on the road though.
Now, I'm more woried about "mini"-vans than anything else. They are even less fuel efficient than SUVs and seem to be the Urban Assault Vehicle of choice among a lot of soccer moms.
Judging by my extremely small sample size, I'd say... you've got to be out of your mind. Sure, smarter people are worth more than dumber people, independent of their education. However, given two coders of equal intelligence/aptitude, the one with a good degree and 1 year of experience beats the hell out of the one with 5 years of experience.
Where to start, where to start...
First, realize that most programming jobs that exist out there in the world are to handle a particular task working in a legacy environment. When you get interviewed for a position like that, they are looking for someone who already knows the ins and outs of their particular environment not general "principles."
In this case, experience trumps all. If this job is working with Oracle working on system that uses Asynchronous Queues and connecting to an inhouse financials system, the guy who knows that system best gets the job.
The fact of the matter is that your resume will get filtered early on if you don't have the necessary experience with their legacy systems.
Second, your "equal intelligence" comment demonstrates that you've never tried interviewing a software engineer. It is extremely difficult to judge relative intelligence from a group of people with historically bad social skills. The best you can usually do in an interview is see if a person is capable of doing the job you want and judge how they solve problems.
Experience, with line items for achievements, can really help in this area simply because you can ask questions about their role and how they solved various issues and get them to open up.
Third, the idea of a "good" degree is terribly difficult to judge these days. Universities today hand out A's like candy and it possible to get a degree and still not know anything.
Finally, I would like to point out that the environment really matters. An established corporation will look much more kindly on a person with a degree and little experience than a startup or small business. This is especially true in the valley where startups simply don't have the money to spend training someone to have them jump ship for a higher paying job once they gain some experience.
Well I guess we can't have everything.
At least we'll have the Platinum Edition, Superbit Edition, Limited Edition, Full Screen Edition, Widescreen Edition, Platinum Series Exteneded Edition, Collector's Edition, Boomstick Edition, Box Set, Unrated Edition, Criterion Edition, Ultimate Edition, 20th Anniversary Edition (in 20 years), Director's Cut, Deluxe Edition and of course this Super Collectors Special Edition to buy and enjoy!
My god I'm stick of DVD editions.
There are a couple important notes about Serial-attached SCSI (SAS) that I think are important.
First, SAS uses a point-to-point topology similar to Serial-ATA instead of a shared bus like SCSI. This means each drive has access to full bandwidth, not just one (the bottleneck being the card itself).
Second, according to the SAS working group, SAS comes in three speeds; 150, 300 and 600 MB/s. I'm not sure where that 3 Gbps figure came from.
Third, unlike Serial-ATA or parallel SCSI, SAS is full duplex like fibre channel. This should have some interesting effects on latency.
Fourth, SAS uses the same physical connector as Serial-ATA and in fact can use Serial-ATA drives in legacy mode.
It think it is possible to move to a different protocol than SMTP by building a protocol over it, rather than throwing it out.
SMTP has evolved over the years for goodness sakes. It isn't like they wrote RFC821 and stopped.
Since The original SMTP RFC, there has been:
RFC 1425 - SMTP Service Extensions
RFC 1426 - SMTP Service Extension for 8bit-MIMEtransport
RFC 1427 - SMTP Service Extension for Message Size Declaration
RFC 1652 - SMTP Service Extension for 8bit-MIMEtransport
RFC 1845 - SMTP Service Extension for Checkpoint/Restart
RFC 1869 - SMTP Service Extensions (ESMTP)
RFC 1985 - SMTP Service Extensions for Remote Message Queue Starting
RFC 2554 - SMTP Service Extensions for Authentication
RFC 2821 - SMTP (Latest version of SMTP Apr 2001)
RFC 3207 - SMTP Service Extension for Secure SMTP over Transport Layer Security
And it goes on and on and on and on.
Spam is tricky, but the average person can block most spam by filtering all messages from users not in their address book since the average grandma doesn't get messages from anyone but people she knows.
You think you have it bad.
I'm the Chief Deneedler at a haystack company. You don't know what hell is until you spend 40 hours a week searching haystacks for needles.
DVD, ATSC (US HDTV), ISDB (JP HDTV) and DVB (EU HDTV) all use MPEG-2, so it isn't much of a surprise that Blu-Ray uses it as well.
This is especially true when you factor in the cost of adding an MPEG-2 decoder chip anyway for DVD backwards compatibility and the general availability of high-quality MPEG-2 encoding hardware.
That is known as CLCC packaging. It was used for a couple versions of the Intel 80186 (made by AMD), Siemens 80286, Intel 80286 (made by AMD) and AMD 80286.
In addition, slot-based packaging (SEP, Slot-A, etc.) all used gold fingers just like PCI cards.
I don't understand why this is news or why it required any level of study.
The root servers handling zone '.' such as F.ROOT-SERVERS.NET put refresh periods of 48 hours on most every query. That means that at most once every 48 hours every name server on the planet should re-ask the root servers where to get answers for each of the gtlds, com, net, org, arpa, etc.
What they should receive the most queries for are domains that don't exist because everything else is cached for such a long period of time. That is the point of the root servers.
If the root servers are having trouble handling the query load then they should be upgraded for goodness sake. These are root servers after all and I think the global internet community could spare a few dollars to add some spare capacity if it is required.
To improve on this, BIND could up the maximum negative RR cache default time to live. Right now I believe it is set to 3 hours and the root servers use a 1 day SOA.MINIMUM instead, so BIND is always lowering it by default.
Of course, other nameservers are different. Some older versions of BIND by default only stored negative RR for 10 minutes.