And of course, before we reach that point, we'll be doing our damnedest to undo any natural correction the planet might offer and increase the rate of decline.
"The globe is warmer!" "Shit, well crank the AC!"
"Plants are growing faster due to the higher CO2 levels!" "Damn weeds! Break out the machetes and gasoline, it's time to slash and burn."
Natural cycles are all well and good, but all the corrective measures the planet has at its disposal tend to be inconvenient for individual humans, so we're likely to fight them every step of the way.
ALS is a genetic disease that affects the nerve cells involved in voluntary muscle movements only. It's not transmissible, and it doesn't affect internal organs that aren't under voluntary control (and for the record, your lungs aren't under voluntary control, they expand and contract based on the movement of your diaphragm). A heart, lung or liver from an ALS patient would be no worse for you than any other organ transplant (and heck, it might be better since most other organ donations come from accident victims, where trauma is a concern, and you don't have time to test the organs for viability and safety as thoroughly).
Well, inviting death is somewhat different than guaranteeing it. I don't disagree with your unstated conclusion, but the rationale is somewhat different. My opinion is that if someone's experience of life is already painful, and guaranteed to get worse with no hope of recovery, they should be allowed to end it. And if they want to help others in the process, that's gravy.
Your numbers are way off. If the entire unpopulated area of the Sahara were covered in photoelectric (at current efficiency levels), it would produce somewhere in the 600-800 terawatt range. The entire planet uses about 13.5 terawatts. Even with transmission losses on high voltage DC lines, you could still power the whole planet using only 1% of the uninhabited area of the Sahara. The picture at the bottom of this article illustrates it nicely, with squares indicating how much would need to be covered in panels to power specific regions.
They still aren't paying the full cost of the negative externalities of coal. Burning it is only one part of the equation (and you neglected to mention the radioactive material and CO2 emitted which isn't scrubbed). Even if you ignore the results of burning the coal, the mining processes are poisoning the water table, destroying mountains (which have value, even if a scenic view is hard to put a price tag), etc. And of course, there's always the argument that we need to transition to renewables eventually (even if it takes 1000 years to burn all our coal, we still need to transition eventually, and the transition is easier if we don't wait until the last second), so delaying the transition to something sustainable is just passing on more debts to our descendants.
To be fair, if we engaged in fuel reprocessing, the amount of waste would reduce drastically. There are still security concerns (reprocessing produces bomb grade fissionable material) and political concerns (we use our no-reprocessing stance to pressure other countries to not do so, as an anti-proliferation measure), but the Yucca mountain issue could be mostly solved by reprocessing.
To be fair, France benefits from a much more centralized population. The U.S. can't just build enormous nuke plants and send power by wire across the country without serious losses on the line. France is small enough that it can send power to a larger number of people with shorter lines, and moreover, they benefit from economies of scale, because they aren't just powering France, they're selling the power to neighboring countries (presumably at a profit).
They also engage in fuel reprocessing, which the U.S. does not, and that makes a huge difference in the economic factors. The U.S. policy is due to a fear of plutonium being stolen from reprocessing facilities for use by terrorists or rogue states, combined with a need to "set an example" to other countries; if we reprocess fuel, then they'll claim they should be allowed to as well, but reprocessing fuel is an easy way to produce bomb grade fissionable material. I don't know if I agree with the U.S. policy (wasting tons upon tons of usable reactor fuel to set an example seems pointless when no one follows the example, and you end up with political quagmires like what to do with all the waste), but the costs in the U.S. are definitely higher.
Of course, that same level of care tends to lead to all sorts of annoyances down the road, especially in networking code that is marketed commercially. Microsoft's Remote Desktop has a number of cases where it decided to minimize protocol costs by limiting field width for certain values, only to discover that it became a problem when those assumptions were invalidated. Screen sizes being capped at 4096x2048, working around that to discover that mouse input is not accepted beyond 32767 pixels to the right of the primary monitor, fields that hold IP addresses in string form, and have to be hacked around to make them send IPv4 addresses as strings, but IPv6 addresses as raw binary in order to fit them, etc. And in most cases it doesn't even do that much good, because as they added compression to the protocol, many of the "wasted" bytes were compressed away. For example, in testing, they found that 32 bit color was no more expensive than 24 bit color, and close enough to 16 bit color that you'd be better off tweaking virtually any other display parameter to improve performance before trying to limit color depth. 8 bit color gives you some savings, but it looks like crap, and many modern programs rely on color gradients that require at least 16 bit color to render readably.
If the protocol had been a little less worried about shaving every byte, it would have been easier to extend. They later managed to fit in a virtual channel protocol that allows arbitrary communication between client and server, so servers that support it can do a lot more without needing to change the underlying protocol, but the overhead of wrapping the extender protocols in that way means it's less efficient now in some scenarios because they insisted on perf boosting compromises in the past.
And of course, just because they were writing code doesn't mean they were programmers by trade. I've rewritten a decent amount of old F77 Fortran code into C (C99), where the original Fortran was written by mathematicians with enough knowledge to directly translate their equations into code, but not to do it well. This code was running on vector processing machines, and Fortran was designed to take advantage of that in a way the C never was, so the Fortran code should have had the advantage, but they made such elementary algorithmic mistakes that those benefits were wasted.
For example, in a trebly nested loop (the most touched code in the program), they were counting the bits set in an integer (that was most of the work in the innermost loop actually). They used the naive approach, as opposed to one of the many,many,many portable, efficient means of doing so, and as opposed to using a provided header that defined these sorts of operations as a macro, such that it defaulted to a performant portable technique, but used the most efficient method available for a number of known processors (many of them have an assembly instruction that does what these portable algorithms do, but requires a single instruction, instead of cluttering the line cache with the step by step instructions). The mathematics were beyond my skills at the time, but it was trivial to find and fix all the "mathematically correct, but practically inefficient" sections of the code without needing to understand it all in detail, and the end result in C ran on the same machine in less than 10% of the time, and over half of that savings came simply from swapping in the efficient bit counting macro.
The end result was not only significantly faster, but was half the length (since macros did a lot of work that had been hand-coded poorly), and easier to read (even before I commented it). Though frankly, anything is easier to read than F77, with its horrible label based loops that make no distinction between the end of the loop and a C-style "continue" statement; it was my first experience with Fortran, and most of the time converting to C was spent figuring out that the fifty "continues" could be converted to C as three loops with a few break and continue statements scattered about (and far less than the original program used; in a nested if statement where each branch triggered a return to the top of the loop, it would be coded individually for each case, rather than putting it in the outer if once, even though it was functionally equivalent).
In summary, don't let your professional mathematicians implement their own equations.
Thank you for that. Now I can code my C more like Perl (while claiming I'm following standards)! TIMTOWTDI! Bwahahaha! Suffer and die code reviewers!;-)
I don't see how implicit variables are necessarily bad practice. It's a language convention. Programmers write for loops that iterate over variables named 'i' all the time, and it's usually accepted, if not condoned, even if it's just as lacking in descriptiveness as $_ (and $_ has a well defined role, where i is purely by convention). Perl uses $_ as the default loop variable, certain methods process it by default when provided no arguments, etc. If you know Perl well, it's quite natural. Similarly, @_ holds arguments passed to a function (having it be the default storage for return values is deprecated, so you don't see it all that often in other contexts), and shifting off it is standard. Don't assume your lack of familiarity means it's automatically poor style.
.COM languages? You mean a web language? You do realize Perl was written as a replacement for sed, awk and the shell languages (csh, bash, etc.), to make systems administration easier by providing a single language that used a familiar, C-like syntax and made text parsing trivial. The web was a non-entity when Perl was created. The fact that it was an acceptable language for web development is tied to the initial design goal of parsing text quickly, but that was never the purpose of Perl, and the spread of the language was not solely (and not even primarily) due to its use on the web.
Example: the 100-200 line perl scripts that can be done in 10 lines of regular oldfashion shell.
Clearly you're not using Perl the way it was meant to be used. This obsession with coding Perl the way you'd code Java (with classes/objects, libraries to do what shell utilities do, etc.) makes it very verbose. But if you use it the old way (quick and dirty scripts, no compunctions about calling to external shell utilities where they can do the job quicker, not bothering with use strict or use warnings, using the implicit variables shamelessly, etc.), Perl is, almost be definition, just as compact as shell. After all, if shell can do it, so can Perl, you just need to wrap it in backticks (and most of the time, Perl can do it natively with equal or greater compactness). Granted, when you code Perl like that it becomes more fragile and the code is hard to maintain. But then, so was the shell script.
The problem with a lot of verbose Perl scripts is that the developers were taught to program Perl like C with dynamic typing (as I was initially, before I had to do it for a job and read Learning Perl and Effective Perl Programming cover to cover). I'm not completely insane, so I do code with use strict and warnings enabled, but I don't use the awful OO features, and even with the code overhead from use strict, my Perl scripts are usually equal to or less than 120% the length of an equivalent shell script (and often much shorter). Plus, using Perl means you don't need to learn the intricacies of every one of the dozens of shell utilities, most of your code can transfer to environments without the GNU tools (and heck, it doesn't explode if the machine you run on only offers csh and you wrote in bash), and most of what you're doing runs in a single process, instead of requiring multiple processes, piping text from one to another, constantly reparsing from string form to process usable form.
Asynchronous I/O is by no means easier. There's a hell of a lot more to keep track of, and a lot more work to do to make asynchronous I/O work correctly; synchronous I/O is much easier to code, and apparently it's faster on Linux to boot.
What about the approach Ubisoft took in Assassin's Creed 2? Out of 14 Sequences (roughly equivalent to chapters), they shipped with 1-11 and 14. 12 and 13 aren't critical to the plot line, and they wrote around them ("These memories are corrupt, we'll skip to the next non-corrupt memory," which happens to be the final mission). 12 and 13 were later offered as DLC for about $3-4 each.
I played through the game before they were released, and the gap was a little weird, but given that they often skipped a year or two of game time between sequences, the gap was nothing new. There's never a pop-up in game, but once the DLC was released, they notified you on the initial menu; if you reached the end of sequence 11 without the DLC it did the "memory is corrupt" bit and skipped you to 14, but if you bought the DLC, it just transitioned to it with a brief mention about needing to fix the corrupted memory. Would that bother you?
With BP, in theory it should take multiple failures to spill. One single screw up isn't enough. Whereas with a car, you can't design a mechanism that can tell the difference between the driver flooring it and the driver accidentally pressing the gas instead of the brake. No backup mechanism exists, nor is it possible to design one (whereas with an oil well, you could theoretically just layer redundant cap after redundant cap on the hole, up to the point at which the risk of a spill is zero, or the point at which you run out of money). Take a look at the chart in the article. The spike in "sudden acceleration" reports directly coincides to the point at which the news reports were most widespread. People who might otherwise have noticed they had their foot on the wrong pedal started leaping to conclusions about the cause of sudden acceleration (and that's assuming a lack of malice; others may have been looking for lawsuit payout).
64 bit Vista/Win7 has Windows Media Player in both a 32 and 64 bit version, but the default shortcut and file type registrations point to the 32 bit version. Not because of any problem with WMP itself, but because most codecs are still unavailable or unstable in 64 bit mode. Like with Internet Explorer and 32 bit only plugins, the root problem is that it uses third party software to function and the third party developers haven't bothered to upgrade to 64 bit (and of course, they see no reason to hurry, because 32 bit is still the default).
There are some other minor benefits that come with 64 bit, but very few of them are marketable. For example, at least on x86_64 with Windows (and I believe all current OSes), the address space is still limited substantially (to 48 bits or less). One of the advantages to this is that every memory address has at least two bytes of zeroes in it. Most buffer overruns require at least one jump instruction to work, but with two nulls in every memory address, typical buffer overruns (triggered by an unbounded strcpy) don't work, because any address you use will terminate the string prematurely. Granted, not using strcpy would provide the same benefits, but you can limit your attack surface simply by recompiling for 64 bit, no need to scan every line of code for strcpy or other code with the same behavior that isn't so easy to find with grep.
Other benefits include taking advantage of memory mapping for performance and simplified coding. Memory mapping is much easier to work with, but on 32 bit architectures you have to be much more careful with it, since each mapping eats a contiguous chunk of your virtual memory space. A single 2.001 GB file, or a couple large files mapped to non-optimal locations can cause you to run out of your process's virtual address space and crash. To handle that case, you'd have to write the non-mmapped version of your I/O anyway, which means you aren't saving any complexity, even if you get the small performance boost. But on a 64 bit system, you can mmap files willy-nilly, no need to worry about running out of address space.
Intel briefly revived 32-bit only processors with the Core (Solo and Duo), before releasing the Core 2 (Solo, Duo, Quad, etc.) line that used a similar architecture but supported x86_64. The 32 bit Core was first released in January 2006, and for about half a year it was the only form Core-series processors were available in. Starting in July 2006, they started selling Core 2 processors, but Core laptops continued to be sold for another year or so, though Core 2's displaced them quickly.
Hmm... Curious. Does it have long term negative effects in infected adults aside from the mildly increased neurotic behavior? If not, it seems like a cat owner would be better off intentionally exposing themselves to it a year or two before having children.
Well, all those sexy women are likely to produce stillborn babies, or babies with long term structural and neurological damage. So on the one hand, you have outgoing women, but on the other hand, you get deformed offspring.
Eh. Defaulting to a more usable but less secure state is standard practice for anyone that wants to sell software to consumer. If you care about it, it's trivial to fix:
Tools->Options->Privacy->Select "Use custom settings for history"->Uncheck "Remember Search and Form History"
Tools->Options->Security->Uncheck "Remember passwords for sites"
My girlfriend does it first thing after installing Firefox on every machine she's ever owned (and she's not particularly computer savvy; she's a science nerd, not a computer geek). Of course, she makes up for the added security of not saving those fields by using the same password everywhere, so it's not exactly an improvement.
Which is why I didn't belabor it, or introduce it out of context. I was pointing out that Firefox's scheme is only as secure as the master password you choose. The particular bad password I chose for the Spaceballs reference on the hope that it might get a chuckle or trigger a brief moment of pleasant nostalgia, forgetting that on/., every joke must be beaten to death and explained, rehashed, insulted, re-explained by someone who thinks the insult came due to unfamiliarity, etc., until all traces of humor vanish. Oh well...
Hmm... This is an old story, so this probably won't receive any mods, but I have no idea what I'd mod it if I were moderating. Flamebait/Insightful/Funny/Interesting/Off-topic maybe? Mods, if you can coordinate to apply each of those once, it would be awesome (and I'd end up with overall neutral Karma!).:-)
Slashdot Mirror
And of course, before we reach that point, we'll be doing our damnedest to undo any natural correction the planet might offer and increase the rate of decline.
"The globe is warmer!" "Shit, well crank the AC!"
"Plants are growing faster due to the higher CO2 levels!" "Damn weeds! Break out the machetes and gasoline, it's time to slash and burn."
Natural cycles are all well and good, but all the corrective measures the planet has at its disposal tend to be inconvenient for individual humans, so we're likely to fight them every step of the way.
ALS is a genetic disease that affects the nerve cells involved in voluntary muscle movements only. It's not transmissible, and it doesn't affect internal organs that aren't under voluntary control (and for the record, your lungs aren't under voluntary control, they expand and contract based on the movement of your diaphragm). A heart, lung or liver from an ALS patient would be no worse for you than any other organ transplant (and heck, it might be better since most other organ donations come from accident victims, where trauma is a concern, and you don't have time to test the organs for viability and safety as thoroughly).
Well, inviting death is somewhat different than guaranteeing it. I don't disagree with your unstated conclusion, but the rationale is somewhat different. My opinion is that if someone's experience of life is already painful, and guaranteed to get worse with no hope of recovery, they should be allowed to end it. And if they want to help others in the process, that's gravy.
Your numbers are way off. If the entire unpopulated area of the Sahara were covered in photoelectric (at current efficiency levels), it would produce somewhere in the 600-800 terawatt range. The entire planet uses about 13.5 terawatts. Even with transmission losses on high voltage DC lines, you could still power the whole planet using only 1% of the uninhabited area of the Sahara. The picture at the bottom of this article illustrates it nicely, with squares indicating how much would need to be covered in panels to power specific regions.
They still aren't paying the full cost of the negative externalities of coal. Burning it is only one part of the equation (and you neglected to mention the radioactive material and CO2 emitted which isn't scrubbed). Even if you ignore the results of burning the coal, the mining processes are poisoning the water table, destroying mountains (which have value, even if a scenic view is hard to put a price tag), etc. And of course, there's always the argument that we need to transition to renewables eventually (even if it takes 1000 years to burn all our coal, we still need to transition eventually, and the transition is easier if we don't wait until the last second), so delaying the transition to something sustainable is just passing on more debts to our descendants.
Umm... France reprocesses nuclear fuel all the time.
To be fair, if we engaged in fuel reprocessing, the amount of waste would reduce drastically. There are still security concerns (reprocessing produces bomb grade fissionable material) and political concerns (we use our no-reprocessing stance to pressure other countries to not do so, as an anti-proliferation measure), but the Yucca mountain issue could be mostly solved by reprocessing.
To be fair, France benefits from a much more centralized population. The U.S. can't just build enormous nuke plants and send power by wire across the country without serious losses on the line. France is small enough that it can send power to a larger number of people with shorter lines, and moreover, they benefit from economies of scale, because they aren't just powering France, they're selling the power to neighboring countries (presumably at a profit).
They also engage in fuel reprocessing, which the U.S. does not, and that makes a huge difference in the economic factors. The U.S. policy is due to a fear of plutonium being stolen from reprocessing facilities for use by terrorists or rogue states, combined with a need to "set an example" to other countries; if we reprocess fuel, then they'll claim they should be allowed to as well, but reprocessing fuel is an easy way to produce bomb grade fissionable material. I don't know if I agree with the U.S. policy (wasting tons upon tons of usable reactor fuel to set an example seems pointless when no one follows the example, and you end up with political quagmires like what to do with all the waste), but the costs in the U.S. are definitely higher.
Of course, that same level of care tends to lead to all sorts of annoyances down the road, especially in networking code that is marketed commercially. Microsoft's Remote Desktop has a number of cases where it decided to minimize protocol costs by limiting field width for certain values, only to discover that it became a problem when those assumptions were invalidated. Screen sizes being capped at 4096x2048, working around that to discover that mouse input is not accepted beyond 32767 pixels to the right of the primary monitor, fields that hold IP addresses in string form, and have to be hacked around to make them send IPv4 addresses as strings, but IPv6 addresses as raw binary in order to fit them, etc. And in most cases it doesn't even do that much good, because as they added compression to the protocol, many of the "wasted" bytes were compressed away. For example, in testing, they found that 32 bit color was no more expensive than 24 bit color, and close enough to 16 bit color that you'd be better off tweaking virtually any other display parameter to improve performance before trying to limit color depth. 8 bit color gives you some savings, but it looks like crap, and many modern programs rely on color gradients that require at least 16 bit color to render readably.
If the protocol had been a little less worried about shaving every byte, it would have been easier to extend. They later managed to fit in a virtual channel protocol that allows arbitrary communication between client and server, so servers that support it can do a lot more without needing to change the underlying protocol, but the overhead of wrapping the extender protocols in that way means it's less efficient now in some scenarios because they insisted on perf boosting compromises in the past.
And of course, just because they were writing code doesn't mean they were programmers by trade. I've rewritten a decent amount of old F77 Fortran code into C (C99), where the original Fortran was written by mathematicians with enough knowledge to directly translate their equations into code, but not to do it well. This code was running on vector processing machines, and Fortran was designed to take advantage of that in a way the C never was, so the Fortran code should have had the advantage, but they made such elementary algorithmic mistakes that those benefits were wasted.
For example, in a trebly nested loop (the most touched code in the program), they were counting the bits set in an integer (that was most of the work in the innermost loop actually). They used the naive approach, as opposed to one of the many, many, many portable, efficient means of doing so, and as opposed to using a provided header that defined these sorts of operations as a macro, such that it defaulted to a performant portable technique, but used the most efficient method available for a number of known processors (many of them have an assembly instruction that does what these portable algorithms do, but requires a single instruction, instead of cluttering the line cache with the step by step instructions). The mathematics were beyond my skills at the time, but it was trivial to find and fix all the "mathematically correct, but practically inefficient" sections of the code without needing to understand it all in detail, and the end result in C ran on the same machine in less than 10% of the time, and over half of that savings came simply from swapping in the efficient bit counting macro.
The end result was not only significantly faster, but was half the length (since macros did a lot of work that had been hand-coded poorly), and easier to read (even before I commented it). Though frankly, anything is easier to read than F77, with its horrible label based loops that make no distinction between the end of the loop and a C-style "continue" statement; it was my first experience with Fortran, and most of the time converting to C was spent figuring out that the fifty "continues" could be converted to C as three loops with a few break and continue statements scattered about (and far less than the original program used; in a nested if statement where each branch triggered a return to the top of the loop, it would be coded individually for each case, rather than putting it in the outer if once, even though it was functionally equivalent).
In summary, don't let your professional mathematicians implement their own equations.
wanna fuck with someone? include and use this guy: http://en.wikipedia.org/wiki/Iso646.h
Thank you for that. Now I can code my C more like Perl (while claiming I'm following standards)! TIMTOWTDI! Bwahahaha! Suffer and die code reviewers! ;-)
I don't see how implicit variables are necessarily bad practice. It's a language convention. Programmers write for loops that iterate over variables named 'i' all the time, and it's usually accepted, if not condoned, even if it's just as lacking in descriptiveness as $_ (and $_ has a well defined role, where i is purely by convention). Perl uses $_ as the default loop variable, certain methods process it by default when provided no arguments, etc. If you know Perl well, it's quite natural. Similarly, @_ holds arguments passed to a function (having it be the default storage for return values is deprecated, so you don't see it all that often in other contexts), and shifting off it is standard. Don't assume your lack of familiarity means it's automatically poor style.
.COM languages? You mean a web language? You do realize Perl was written as a replacement for sed, awk and the shell languages (csh, bash, etc.), to make systems administration easier by providing a single language that used a familiar, C-like syntax and made text parsing trivial. The web was a non-entity when Perl was created. The fact that it was an acceptable language for web development is tied to the initial design goal of parsing text quickly, but that was never the purpose of Perl, and the spread of the language was not solely (and not even primarily) due to its use on the web.
Example: the 100-200 line perl scripts that can be done in 10 lines of regular oldfashion shell.
Clearly you're not using Perl the way it was meant to be used. This obsession with coding Perl the way you'd code Java (with classes/objects, libraries to do what shell utilities do, etc.) makes it very verbose. But if you use it the old way (quick and dirty scripts, no compunctions about calling to external shell utilities where they can do the job quicker, not bothering with use strict or use warnings, using the implicit variables shamelessly, etc.), Perl is, almost be definition, just as compact as shell. After all, if shell can do it, so can Perl, you just need to wrap it in backticks (and most of the time, Perl can do it natively with equal or greater compactness). Granted, when you code Perl like that it becomes more fragile and the code is hard to maintain. But then, so was the shell script.
The problem with a lot of verbose Perl scripts is that the developers were taught to program Perl like C with dynamic typing (as I was initially, before I had to do it for a job and read Learning Perl and Effective Perl Programming cover to cover). I'm not completely insane, so I do code with use strict and warnings enabled, but I don't use the awful OO features, and even with the code overhead from use strict, my Perl scripts are usually equal to or less than 120% the length of an equivalent shell script (and often much shorter). Plus, using Perl means you don't need to learn the intricacies of every one of the dozens of shell utilities, most of your code can transfer to environments without the GNU tools (and heck, it doesn't explode if the machine you run on only offers csh and you wrote in bash), and most of what you're doing runs in a single process, instead of requiring multiple processes, piping text from one to another, constantly reparsing from string form to process usable form.
Asynchronous I/O is by no means easier. There's a hell of a lot more to keep track of, and a lot more work to do to make asynchronous I/O work correctly; synchronous I/O is much easier to code, and apparently it's faster on Linux to boot.
What about the approach Ubisoft took in Assassin's Creed 2? Out of 14 Sequences (roughly equivalent to chapters), they shipped with 1-11 and 14. 12 and 13 aren't critical to the plot line, and they wrote around them ("These memories are corrupt, we'll skip to the next non-corrupt memory," which happens to be the final mission). 12 and 13 were later offered as DLC for about $3-4 each.
I played through the game before they were released, and the gap was a little weird, but given that they often skipped a year or two of game time between sequences, the gap was nothing new. There's never a pop-up in game, but once the DLC was released, they notified you on the initial menu; if you reached the end of sequence 11 without the DLC it did the "memory is corrupt" bit and skipped you to 14, but if you bought the DLC, it just transitioned to it with a brief mention about needing to fix the corrupted memory. Would that bother you?
A great excuse to stay away from Motorola. It's not the OS, it's the hardware, and only Motorola (that we know of) is doing this crap.
With BP, in theory it should take multiple failures to spill. One single screw up isn't enough. Whereas with a car, you can't design a mechanism that can tell the difference between the driver flooring it and the driver accidentally pressing the gas instead of the brake. No backup mechanism exists, nor is it possible to design one (whereas with an oil well, you could theoretically just layer redundant cap after redundant cap on the hole, up to the point at which the risk of a spill is zero, or the point at which you run out of money). Take a look at the chart in the article. The spike in "sudden acceleration" reports directly coincides to the point at which the news reports were most widespread. People who might otherwise have noticed they had their foot on the wrong pedal started leaping to conclusions about the cause of sudden acceleration (and that's assuming a lack of malice; others may have been looking for lawsuit payout).
64 bit Vista/Win7 has Windows Media Player in both a 32 and 64 bit version, but the default shortcut and file type registrations point to the 32 bit version. Not because of any problem with WMP itself, but because most codecs are still unavailable or unstable in 64 bit mode. Like with Internet Explorer and 32 bit only plugins, the root problem is that it uses third party software to function and the third party developers haven't bothered to upgrade to 64 bit (and of course, they see no reason to hurry, because 32 bit is still the default).
There are some other minor benefits that come with 64 bit, but very few of them are marketable. For example, at least on x86_64 with Windows (and I believe all current OSes), the address space is still limited substantially (to 48 bits or less). One of the advantages to this is that every memory address has at least two bytes of zeroes in it. Most buffer overruns require at least one jump instruction to work, but with two nulls in every memory address, typical buffer overruns (triggered by an unbounded strcpy) don't work, because any address you use will terminate the string prematurely. Granted, not using strcpy would provide the same benefits, but you can limit your attack surface simply by recompiling for 64 bit, no need to scan every line of code for strcpy or other code with the same behavior that isn't so easy to find with grep.
Other benefits include taking advantage of memory mapping for performance and simplified coding. Memory mapping is much easier to work with, but on 32 bit architectures you have to be much more careful with it, since each mapping eats a contiguous chunk of your virtual memory space. A single 2.001 GB file, or a couple large files mapped to non-optimal locations can cause you to run out of your process's virtual address space and crash. To handle that case, you'd have to write the non-mmapped version of your I/O anyway, which means you aren't saving any complexity, even if you get the small performance boost. But on a 64 bit system, you can mmap files willy-nilly, no need to worry about running out of address space.
Intel briefly revived 32-bit only processors with the Core (Solo and Duo), before releasing the Core 2 (Solo, Duo, Quad, etc.) line that used a similar architecture but supported x86_64. The 32 bit Core was first released in January 2006, and for about half a year it was the only form Core-series processors were available in. Starting in July 2006, they started selling Core 2 processors, but Core laptops continued to be sold for another year or so, though Core 2's displaced them quickly.
Hmm... Curious. Does it have long term negative effects in infected adults aside from the mildly increased neurotic behavior? If not, it seems like a cat owner would be better off intentionally exposing themselves to it a year or two before having children.
Well, all those sexy women are likely to produce stillborn babies, or babies with long term structural and neurological damage. So on the one hand, you have outgoing women, but on the other hand, you get deformed offspring.
My girlfriend does it first thing after installing Firefox on every machine she's ever owned (and she's not particularly computer savvy; she's a science nerd, not a computer geek). Of course, she makes up for the added security of not saving those fields by using the same password everywhere, so it's not exactly an improvement.
Which is why I didn't belabor it, or introduce it out of context. I was pointing out that Firefox's scheme is only as secure as the master password you choose. The particular bad password I chose for the Spaceballs reference on the hope that it might get a chuckle or trigger a brief moment of pleasant nostalgia, forgetting that on /., every joke must be beaten to death and explained, rehashed, insulted, re-explained by someone who thinks the insult came due to unfamiliarity, etc., until all traces of humor vanish. Oh well...
Hmm... This is an old story, so this probably won't receive any mods, but I have no idea what I'd mod it if I were moderating. Flamebait/Insightful/Funny/Interesting/Off-topic maybe? Mods, if you can coordinate to apply each of those once, it would be awesome (and I'd end up with overall neutral Karma!). :-)