A lot of companies don't have the skill set to produce high-quality maintainable drivers. Not that they're bad engineers, but they put more effort into hardware design, and whatever functionality the device has. This makes sense; I'd much rather have a device that follows the PCI spec correctly than one where the vendor knows how to work around the quirks in the driver.
The best devices are ones that use non-vendor-specific drivers. For example, disk controllers are increasingly "AHCI", and, so long as they behave as specified, they don't need new drivers at all, because the ahci driver handles all of them without any vendor-specific input. I've got an SD card reader in my laptop from a vendor that doesn't have any Linux relationship at all, but the hardware works fine because it follows a published spec. Likewise, USB storage devices. "HDA" sound devices get partway there (the device behaves in a standard way, but then you need drivers for the codec, which is extra exciting because it's a chip from yet another vendor; I've got a Lenovo laptop with an Intel sound card, with two codecs: an Analog Devices one, and a Cirrus (I think) one; it's unclear who'd provide the necessary software to the end user here, but ALSA handles it all fine, afaict).
Of course, half of the knowledge needed to write a good Linux driver is about Linux, rather than about the hardware, and not understanding the Linux side is more likely to cause system instability and problems that aren't easy to identify.
What I'd like vendors to do, as far as Linux support in the device box, is list the mainline kernel driver options you need and the names of the modules you'll get, and the kernel version you need in order to have the driver (and have it know about the device).
IIRC, the algorithm the same group chose for AES was patent-free. This was despite some people wanting them to choose a patented algorithm because the contest requirements included that the winner would have to license any necessary patents to everyone for free. So choosing a patented algorithm would have meant that you and I could use one more AES-finalist-quality algorithm.
The software vendors in Cambodia are selling MS Office for the same price as OpenOffice, and they actually bother to put both of them out. That should suggest that MS Office isn't wildly more popular. And it's probably true, because, if you want OpenOffice, you go out and pay $2 for it, but if you want MS Office, you go out, pay $2 for it, and learn English so you can read the text in the UI. Sure, learning English is a good way to get ahead, too, but if you just want a [Khmer text removed by slashdot] to get some work done, MS Office isn't going to help.
I believe that all of the weather sites get their model runs from the NWS, but they each interpret them partially individually. The big computer in the basement spits out a lot of values for various things, but the daily low in Houston isn't exactly one of them. There's a lot of "the model says this, but that pocket of cold air over there is just as likely to go north or south of the model output, so we'll say something different". Also, there are a number of different models with different behavior. The NWS does have forecaster discussion about what the total probably means, but sites often make their own judgments based on their forecasters' experience with the models.
Then, of course, actual individuals don't care too much about the weather in Houston. They care about the weather in their yard, which may be substantially different from the offical measurement point, especially with respect to extreme weather. So sites will often modify their forecasts to try to make the fewest people unhappy (e.g., if you think there will be hazardous weather somewhere in your area, you predict it, because the guy whose water park trip is ruined by hail isn't going to be impressed that the storm didn't hit most of the rest of the forecast area; the people who stay home and see clear skies will be disappointed but forget about it quickly). But how to do this analysis is up to the sites, and they all do it differently.
Really, if you want to get a good weather forecast, you have to look at commentary, not just figures, because you might want to know about the storm that will affect only 5% of the area. And you want to look at the radar loop, which is really useful for telling what's in the area, whether it's likely to miss you by a few miles, and when it's likely to hit.
I don't see why Google would have to make it difficult to extract your data. Unlike Microsoft, they're not planning to make their users want to switch away, because their business model doesn't put them in an adversarial position with respect to their users. (Their business model is based on showing ads to people who might actually want what's advertized, which is beneficial to everybody involved.)
Most business models involve making it easy for people to adopt your product at some point. That doesn't mean that the rest of the plan is the same.
Chances are that, if Google acted like Microsoft, they'd be sued by their stockholders, because their prospectus actually says that their future value is based on having a good reputation, and that they intend to sacrifice short-term profits for this reputation.
Chances are that OpenXML will get shot down in the ISO process. It's not going fast-track thanks to Britain, and the slow track process goes through the same committee that's just done ODF, and ODF is better in every way than OpenXML. Everybody on the committee except for the Microsoft representative is going to be looking for anything that they should send over to OASIS for ODF 1.2, not looking to approve a conflicting standard with no different useful design goals.
Of course, it would probably be wise for Texas to mandate the use of an ISO-standard document format without picking out ODF in particular. But they should maybe also specify that it should be one where another state government has experience in implementing a migration and supporting users, since this is a useful criterion which will be possible to meet.
The real issue is that people use extensions based on the container format, which is totally irrelevant to anything. Why would you ever care that your file uses the Ogg container, but not care what codec it uses or even what sort of media is encoded in it? I give all of my Ogg Vorbis files the extension ".audio", same as my mp3 files. Any software that's likely to be able to play them is going to be able to tell from the file contents what container format it uses. But it's useful to me to know whether I should be playing a file with a music player or a video player.
Of course, I think most people would be more comfortable giving their Ogg Vorbis files the extension ".mp3", since that's commonly and unambiguously used for files containing only audio.
Yeah, people in Boston really freak out when they see boxes with lights in the city. I hear people in other cities are a lot more used to it, because there are boxes with lights at every intersection.
For Linux, you want gcc, avr-libc, and avrdude. One nice thing about the AVR over the 8051 is that GCC supports it. This means that you can use perfectly standards-compliant C99 with all the trivial optimizations (which is really nice, because you can write your numeric constants as explanatory expressions without wasting cycles in the resulting code).
It's also worth noting that the AVR datasheets are incredibly detailed and require very little background information. E.g., the section about I2C (aka TWI) is actually one of the best references for the bus protocol, as well as telling you exactly how to program the chip to do it. Of course, they're huge documents, but you only have to read a small portion of each of them, because the section on timer 2 doesn't assume that you've read the section on timer 0 and therefore explains from scratch how timers work on the AVR. Read the data sheets with a PDF reader with table of contents, index, and search.
Then they'd have probably gone off some time in the two weeks that they've been up there without anybody official doing anything or particularly noticing. These weren't put up recently; it's just that nobody was looking for them during the daytime until somebody brought one of them to the attention of the police, and they destroyed it not knowing what it was.
It's not Microsoft-style bloat, it's Linux-style bloat. It doesn't have any effect on the kernel binary unless you enable it. And you can't enable it in an x86 or x86_64 kernel, because it's a PPC platform configuration. Linux-style bloat is that the kernel source tree has everything possible in it, but it only gets built if you actually manage to ask for it, and then it's generally a module and only gets loaded if you actually need it. But it's in the source tree, because developers want to know about as much as possible of the code that might need to get updated if things change or might have bugs or incorrect assumptions.
Hardware manufacturers don't provide tech support to end users at all, normally. Usually, they provide drivers to device manufacturers, who then say fairly useless things to actual customers. It doesn't really matter to the people who interact with users who writes the drivers, because it's never them anyway.
For that matter, there are going to be three classes of problems users will have using devices on Linux: (1) the driver isn't installed, (2) the driver is working, but no programs are trying to use the device, or (3) the device is broken. For (1) and (2), the vendor is going to have no clue what to do; for (3), the OS doesn't matter.
You're still *reading* security advisories? "glsa-check -f new" or "glsa-check -l affected" But you should be aware that Gentoo doesn't do glsas for the kernel, which may be important to an ISP and is not entirely obvious.
Gentoo does reasonably well with configuration stuff (certainly better than any other system I've seen), but I still think it should be better; it'd be really nice if upgrades that change config files would be built but not installed, and then you'd be guided through updating the config file stored in the new package, and then it would install the package, overwriting your old config file with the version you prepared separately. And then it could stop the service right before installation and start it again right after, because the new configuration would already be in place.
The other thing that would be great would be if it could build packages with their dependancies built but not yet installed. Then it could do the revdep-rebuild *before* there were any non-working programs on the system.
But really, the only case where I've had problems with Gentoo on my server is when there's a difference between what services are running now and what services would be started if I rebooted and got to the current runlevel. (I.e., you install something and start it but don't add it to the default runlevel, and when you eventually reboot, you don't realize it's not running until somebody complains that the thing they need isn't working.)
They've most likely just changed how link text is used in calculations, not eliminated it entirely. For example, it would make sense measure pages for a search on multiple metrics: Is the page talking about what the search is asking about? Is it a respected authority on that topic? It makes sense to multiply these measures rather than adding them. So a page that scores 1/4 on each of these would beat a page that's 1% on one and 99% on the other.
SHA-512 and SHA-256 are essential the "SHA-2" family, with different details (leading to different output lengths). The SHA-1 flaw doesn't apply to them (which is why NIST is saying to move to SHA-256 from SHA-1 (-512 is a tad excessive if you weren't previously worried about length with 160 bits, and are leaving SHA-1 due to algorithm weakness).
Also, many uses for a secure hash are still safe with SHA-1 as far as has been published; the only issue presently is that people could prepare pairs of colliding documents with less effort than should be required, although this raises the concern that there are techniques for doing other things to SHA-1 hashes which haven't been published (or discovered) yet.
Okay, so people are accidentally sending Google URLs with their usernames and passwords in them, and Google is then reporting this information to whoever cares.
But the URLs people are submitting are URLs of sites they think are phishing sites. People are effectively saying, "I think this site stole my password, which is 12345." Okay, so maybe Google shouldn't widely distribute this accidentally-disclosed information, but... how much do you care about whether the general public can see your password, when you've already provided it to somebody who was actually trying to collect it for presumably nefarious purposes? Surely these passwords have been changed, right? Right?
Actually, if these labels managed to actually make it infeasible to copy their music, people would lose interest in it. It is increasingly the case that the way people know that a song is available and interesting to buy is unauthorized copying or performance. If they actually got DRM to prevent causal copying, it would be just like they hadn't released the album. People need to be able to tell each other, "I'm listening to this great album, and you should, too" in order for music to be popular. If a mechanism prevents them from actually sharing their favorite music, their friends will have different music, which can actually be shared.
The problem with your approach is that most of the bugs that last for more than a development cycle and are in 2.6.19.y at this point are very old bugs, from 2.6.0 if not before. If you're using 2.6.8, for example, you may get file corruption for Berkeley DB. The incorrect behavior was introduced in the 2.5 series, made to trigger frequently with a recent (correct) patch, and then fixed. When this was publicized, people started mentioning that they'd been getting corruption that fits the symptoms for years, and had assumed it was application bugs. Before too long, the mainline is going to switch to new IDE code, at which point any bugs remaining in the old IDE code will probably never get fixed (and the current IDE code is known to be irreparably flaky in the case of disk errors, which is one reason it's being replaced).
If you look at kernel releases in terms of the expected number of significant bugs in a release, 2.6.19.2 is probably the best kernel available.
The kernels to avoid are 2.6.x (3-digit) ones; they contain known bugs for which the correct fix in terms of long-term maintainability and clean code is too risky or intrusive to apply late in the release cycle. These bugs are left in 2.6.x and fixed in a way that's obviously right but not clean in 2.6.x.1 and in the long-term viable way in 2.6.x+1-git1. Personally, I think that Linus should turn over the 2.6.x version numbers to the stable team, and have his final release be 2.6.20-rcmax, with 2.6.20 (stable team) and 2.6.21-git1 (him) forking at that point. This would then permit the stable team to be more relaxed about their first patch in a series (because the kernel they're fixing isn't an all-digit, stable-looking version) and they can make sure that all of the known issues are fixed before going into the regime where fixes need to be released quickly because they affect a kernel production users are encouraged to use.
(Of course, 2.4.x was really bad in terms of stability; vendor 2.4.x kernels contained many backports of important features from 2.5/2.6, and these backports were never seen by the original developers and untested by the community outside of that particular distro. And the original developers generally wrote those features expecting that they'd be used in the context of 2.6, so there's no telling what assumptions they made.)
Militaries have to design armor that you can actually do useful stuff in. With his early suits at least, you couldn't really do much other than watch sleeping bears. The hard part isn't really making yourself nearly indestructable; it's making yourself nearly indestructable and still able to chase people, open doors, hear people sneaking up on you, grab things, etc. If this guy were on patrol in Iraq, insurgants would kidnap him by catching him in a net, dragging him off, and removing the suit. It's not any better than just staying in a bunker all the time.
The DRM doesn't actually help Apple translate iPod sales into iTMS sales. Not having DRM that doesn't work on the iPod does help, but not having DRM at all would have the same effect. The major factor in people buying song online for their iPod from iTMS is other sites using DRM that the iPod doesn't support. You could maybe argue that Apple would like to keep the music industry demanding that sites put DRM on their music sales so that non-iTMS sites can't sell anything people want to buy. But, of course, the music industry doesn't really want to be limited to a single distribution channel, and iTMS competitors don't want to be irrelevant, so it's only in Apple's interest, and it's not Apple decision.
Music bought from iTMS isn't a big factor in whether they buy iPods. People's music collections are mostly in mp3, ripped from CDs, especially if they don't already have iPods. And Apple's brand loyalty is legendary, so people with iPods are generally not in the market for non-iPod music players, regardless of whether they have any music from iTMS. People know that the main reason to get Apple products is the user experience, and they know that you get this experience by continuing to buy from Apple.
IDE-SCSI no longer works from 2.6.10 onwards at least up to 2.6.16
It's ironic that you mention IDE-SCSI as not working. The latest excitement is that devices that used to be treated as IDE are now being treated as SCSI if you build the appropriate drivers, so people are finding that the drives they thought were "IDE" are actually "ATA", and on/dev/sda now. Not only is the functionality of treating "IDE" devices as "SCSI" still available, it doesn't require a special module, and it's becoming default. They're eventually going to ditch "IDE" entirely, because it's crufty old code that nobody really likes. Of course, with any luck, PATA controllers will be enumerated and the information put in sysfs along with master/slave, so you'll still be able to get/dev/hda out of udev for your PATA hard drive.
As far as stability is concerned, I've had exactly one kernel problem using a kernel that has ~9 patches that aren't from mainline. And that problem (it would break a device sharing a legacy IRQ with an nvidia ethernet card on a system with MSI support if you don't use msi=disable) was fixed in 2.6.18.y and 2.6.19.1.
The idea in the 2.4 days was that distros (and only distros) would fork off and maintain a release with hundreds of backported patches from the development series that won't be available in a stable vanilla kernel for several years. The idea now is that the latest 2.6.x should work for everybody. Backporting anything is a bad idea in general, and regressions should be fixed before a 2.6.x comes out, or shortly thereafter.
Actually, what we need is a substantial penalty for badly losing an infringement lawsuit you bring. As it is, the worst you can do by suing somebody is to have to pay their court costs and legal fees, and this only happens if the patent is invalid and you're demonstrated to have known it. (Sure, your patent can end up invalidated if it gets reexamined, but if it was bogus in the first place, you've only lost an asset that should have been worthless.)
If you sue someone for infringing your patent, and you're found to have been willfully misleading to the PTO in getting the patent, you should be liable to the defendants for triple the relief you requested, and the law firm that represented you should be sanctioned.
This would mean that it would be net beneficial to be sued by a patent troll, because you'll probably have an easy case, the plaintiff is likely pro se and incompetent, you'll recover court costs, and probably get any assets the troll happens to have. There'd also be little reason to settle or license bogus patents, because you'd be able to make money infringing them.
The current situation is kind of like how it would be if people convicted of robbing banks only had to give back the money.
Testing doesn't really help much. The cases you're worried about are the ones which aren't going to happen in 12 years of actual use, and which are only triggered by specially-constructed input. If you knew how to test in order to trigger the bug, you could just look at the code and see if the bug is there.
The main thing is really good design, good style, and unrushed review. One important thing is to do all of the tricky pointer-fiddling in a file of utility routines, so that it only has to be right once. Another is to get the compiler to report all your typos (e.g., there's a brilliant C trick with macros for getting the compiler to typecheck arguments in template-like ways before casting this information away and calling a function who correctness depends on things matching). Then, run it through valgrind and fix all of your uninitialized values, off-by-one errors, and memory leaks.
Wikipedia is actually extremely verbose. It's just structured in such a way that having many many short articles isn't too difficult to use. So Wikipedia has the space for a detailed article on the 40th US Congress, and Britannica doesn't. This may seem insignificant, but if you're trying to find out the political conditions surrounding the impeachments of US presidents, it's important, particularly if you also want similar information on the outcome of the election following the impeachment trial.
Slashdot Mirror
A lot of companies don't have the skill set to produce high-quality maintainable drivers. Not that they're bad engineers, but they put more effort into hardware design, and whatever functionality the device has. This makes sense; I'd much rather have a device that follows the PCI spec correctly than one where the vendor knows how to work around the quirks in the driver.
The best devices are ones that use non-vendor-specific drivers. For example, disk controllers are increasingly "AHCI", and, so long as they behave as specified, they don't need new drivers at all, because the ahci driver handles all of them without any vendor-specific input. I've got an SD card reader in my laptop from a vendor that doesn't have any Linux relationship at all, but the hardware works fine because it follows a published spec. Likewise, USB storage devices. "HDA" sound devices get partway there (the device behaves in a standard way, but then you need drivers for the codec, which is extra exciting because it's a chip from yet another vendor; I've got a Lenovo laptop with an Intel sound card, with two codecs: an Analog Devices one, and a Cirrus (I think) one; it's unclear who'd provide the necessary software to the end user here, but ALSA handles it all fine, afaict).
Of course, half of the knowledge needed to write a good Linux driver is about Linux, rather than about the hardware, and not understanding the Linux side is more likely to cause system instability and problems that aren't easy to identify.
What I'd like vendors to do, as far as Linux support in the device box, is list the mainline kernel driver options you need and the names of the modules you'll get, and the kernel version you need in order to have the driver (and have it know about the device).
IIRC, the algorithm the same group chose for AES was patent-free. This was despite some people wanting them to choose a patented algorithm because the contest requirements included that the winner would have to license any necessary patents to everyone for free. So choosing a patented algorithm would have meant that you and I could use one more AES-finalist-quality algorithm.
The software vendors in Cambodia are selling MS Office for the same price as OpenOffice, and they actually bother to put both of them out. That should suggest that MS Office isn't wildly more popular. And it's probably true, because, if you want OpenOffice, you go out and pay $2 for it, but if you want MS Office, you go out, pay $2 for it, and learn English so you can read the text in the UI. Sure, learning English is a good way to get ahead, too, but if you just want a [Khmer text removed by slashdot] to get some work done, MS Office isn't going to help.
I believe that all of the weather sites get their model runs from the NWS, but they each interpret them partially individually. The big computer in the basement spits out a lot of values for various things, but the daily low in Houston isn't exactly one of them. There's a lot of "the model says this, but that pocket of cold air over there is just as likely to go north or south of the model output, so we'll say something different". Also, there are a number of different models with different behavior. The NWS does have forecaster discussion about what the total probably means, but sites often make their own judgments based on their forecasters' experience with the models.
Then, of course, actual individuals don't care too much about the weather in Houston. They care about the weather in their yard, which may be substantially different from the offical measurement point, especially with respect to extreme weather. So sites will often modify their forecasts to try to make the fewest people unhappy (e.g., if you think there will be hazardous weather somewhere in your area, you predict it, because the guy whose water park trip is ruined by hail isn't going to be impressed that the storm didn't hit most of the rest of the forecast area; the people who stay home and see clear skies will be disappointed but forget about it quickly). But how to do this analysis is up to the sites, and they all do it differently.
Really, if you want to get a good weather forecast, you have to look at commentary, not just figures, because you might want to know about the storm that will affect only 5% of the area. And you want to look at the radar loop, which is really useful for telling what's in the area, whether it's likely to miss you by a few miles, and when it's likely to hit.
I don't see why Google would have to make it difficult to extract your data. Unlike Microsoft, they're not planning to make their users want to switch away, because their business model doesn't put them in an adversarial position with respect to their users. (Their business model is based on showing ads to people who might actually want what's advertized, which is beneficial to everybody involved.)
Most business models involve making it easy for people to adopt your product at some point. That doesn't mean that the rest of the plan is the same.
Chances are that, if Google acted like Microsoft, they'd be sued by their stockholders, because their prospectus actually says that their future value is based on having a good reputation, and that they intend to sacrifice short-term profits for this reputation.
Chances are that OpenXML will get shot down in the ISO process. It's not going fast-track thanks to Britain, and the slow track process goes through the same committee that's just done ODF, and ODF is better in every way than OpenXML. Everybody on the committee except for the Microsoft representative is going to be looking for anything that they should send over to OASIS for ODF 1.2, not looking to approve a conflicting standard with no different useful design goals.
Of course, it would probably be wise for Texas to mandate the use of an ISO-standard document format without picking out ODF in particular. But they should maybe also specify that it should be one where another state government has experience in implementing a migration and supporting users, since this is a useful criterion which will be possible to meet.
The real issue is that people use extensions based on the container format, which is totally irrelevant to anything. Why would you ever care that your file uses the Ogg container, but not care what codec it uses or even what sort of media is encoded in it? I give all of my Ogg Vorbis files the extension ".audio", same as my mp3 files. Any software that's likely to be able to play them is going to be able to tell from the file contents what container format it uses. But it's useful to me to know whether I should be playing a file with a music player or a video player.
Of course, I think most people would be more comfortable giving their Ogg Vorbis files the extension ".mp3", since that's commonly and unambiguously used for files containing only audio.
Yeah, people in Boston really freak out when they see boxes with lights in the city. I hear people in other cities are a lot more used to it, because there are boxes with lights at every intersection.
I'm sure everything on these USB sticks, aside from music, will be other files. (Who uses directories these days?)
C'mon, this is slashdot. You don't have to say "other files", you can say "pr0n" here...
For Linux, you want gcc, avr-libc, and avrdude. One nice thing about the AVR over the 8051 is that GCC supports it. This means that you can use perfectly standards-compliant C99 with all the trivial optimizations (which is really nice, because you can write your numeric constants as explanatory expressions without wasting cycles in the resulting code).
It's also worth noting that the AVR datasheets are incredibly detailed and require very little background information. E.g., the section about I2C (aka TWI) is actually one of the best references for the bus protocol, as well as telling you exactly how to program the chip to do it. Of course, they're huge documents, but you only have to read a small portion of each of them, because the section on timer 2 doesn't assume that you've read the section on timer 0 and therefore explains from scratch how timers work on the AVR. Read the data sheets with a PDF reader with table of contents, index, and search.
Then they'd have probably gone off some time in the two weeks that they've been up there without anybody official doing anything or particularly noticing. These weren't put up recently; it's just that nobody was looking for them during the daytime until somebody brought one of them to the attention of the police, and they destroyed it not knowing what it was.
It's not Microsoft-style bloat, it's Linux-style bloat. It doesn't have any effect on the kernel binary unless you enable it. And you can't enable it in an x86 or x86_64 kernel, because it's a PPC platform configuration. Linux-style bloat is that the kernel source tree has everything possible in it, but it only gets built if you actually manage to ask for it, and then it's generally a module and only gets loaded if you actually need it. But it's in the source tree, because developers want to know about as much as possible of the code that might need to get updated if things change or might have bugs or incorrect assumptions.
Hardware manufacturers don't provide tech support to end users at all, normally. Usually, they provide drivers to device manufacturers, who then say fairly useless things to actual customers. It doesn't really matter to the people who interact with users who writes the drivers, because it's never them anyway.
For that matter, there are going to be three classes of problems users will have using devices on Linux: (1) the driver isn't installed, (2) the driver is working, but no programs are trying to use the device, or (3) the device is broken. For (1) and (2), the vendor is going to have no clue what to do; for (3), the OS doesn't matter.
You're still *reading* security advisories? "glsa-check -f new" or "glsa-check -l affected" But you should be aware that Gentoo doesn't do glsas for the kernel, which may be important to an ISP and is not entirely obvious.
Gentoo does reasonably well with configuration stuff (certainly better than any other system I've seen), but I still think it should be better; it'd be really nice if upgrades that change config files would be built but not installed, and then you'd be guided through updating the config file stored in the new package, and then it would install the package, overwriting your old config file with the version you prepared separately. And then it could stop the service right before installation and start it again right after, because the new configuration would already be in place.
The other thing that would be great would be if it could build packages with their dependancies built but not yet installed. Then it could do the revdep-rebuild *before* there were any non-working programs on the system.
But really, the only case where I've had problems with Gentoo on my server is when there's a difference between what services are running now and what services would be started if I rebooted and got to the current runlevel. (I.e., you install something and start it but don't add it to the default runlevel, and when you eventually reboot, you don't realize it's not running until somebody complains that the thing they need isn't working.)
They've most likely just changed how link text is used in calculations, not eliminated it entirely. For example, it would make sense measure pages for a search on multiple metrics: Is the page talking about what the search is asking about? Is it a respected authority on that topic? It makes sense to multiply these measures rather than adding them. So a page that scores 1/4 on each of these would beat a page that's 1% on one and 99% on the other.
SHA-512 and SHA-256 are essential the "SHA-2" family, with different details (leading to different output lengths). The SHA-1 flaw doesn't apply to them (which is why NIST is saying to move to SHA-256 from SHA-1 (-512 is a tad excessive if you weren't previously worried about length with 160 bits, and are leaving SHA-1 due to algorithm weakness).
Also, many uses for a secure hash are still safe with SHA-1 as far as has been published; the only issue presently is that people could prepare pairs of colliding documents with less effort than should be required, although this raises the concern that there are techniques for doing other things to SHA-1 hashes which haven't been published (or discovered) yet.
Okay, so people are accidentally sending Google URLs with their usernames and passwords in them, and Google is then reporting this information to whoever cares.
But the URLs people are submitting are URLs of sites they think are phishing sites. People are effectively saying, "I think this site stole my password, which is 12345." Okay, so maybe Google shouldn't widely distribute this accidentally-disclosed information, but... how much do you care about whether the general public can see your password, when you've already provided it to somebody who was actually trying to collect it for presumably nefarious purposes? Surely these passwords have been changed, right? Right?
Actually, if these labels managed to actually make it infeasible to copy their music, people would lose interest in it. It is increasingly the case that the way people know that a song is available and interesting to buy is unauthorized copying or performance. If they actually got DRM to prevent causal copying, it would be just like they hadn't released the album. People need to be able to tell each other, "I'm listening to this great album, and you should, too" in order for music to be popular. If a mechanism prevents them from actually sharing their favorite music, their friends will have different music, which can actually be shared.
The problem with your approach is that most of the bugs that last for more than a development cycle and are in 2.6.19.y at this point are very old bugs, from 2.6.0 if not before. If you're using 2.6.8, for example, you may get file corruption for Berkeley DB. The incorrect behavior was introduced in the 2.5 series, made to trigger frequently with a recent (correct) patch, and then fixed. When this was publicized, people started mentioning that they'd been getting corruption that fits the symptoms for years, and had assumed it was application bugs. Before too long, the mainline is going to switch to new IDE code, at which point any bugs remaining in the old IDE code will probably never get fixed (and the current IDE code is known to be irreparably flaky in the case of disk errors, which is one reason it's being replaced).
If you look at kernel releases in terms of the expected number of significant bugs in a release, 2.6.19.2 is probably the best kernel available.
The kernels to avoid are 2.6.x (3-digit) ones; they contain known bugs for which the correct fix in terms of long-term maintainability and clean code is too risky or intrusive to apply late in the release cycle. These bugs are left in 2.6.x and fixed in a way that's obviously right but not clean in 2.6.x.1 and in the long-term viable way in 2.6.x+1-git1. Personally, I think that Linus should turn over the 2.6.x version numbers to the stable team, and have his final release be 2.6.20-rcmax, with 2.6.20 (stable team) and 2.6.21-git1 (him) forking at that point. This would then permit the stable team to be more relaxed about their first patch in a series (because the kernel they're fixing isn't an all-digit, stable-looking version) and they can make sure that all of the known issues are fixed before going into the regime where fixes need to be released quickly because they affect a kernel production users are encouraged to use.
(Of course, 2.4.x was really bad in terms of stability; vendor 2.4.x kernels contained many backports of important features from 2.5/2.6, and these backports were never seen by the original developers and untested by the community outside of that particular distro. And the original developers generally wrote those features expecting that they'd be used in the context of 2.6, so there's no telling what assumptions they made.)
Militaries have to design armor that you can actually do useful stuff in. With his early suits at least, you couldn't really do much other than watch sleeping bears. The hard part isn't really making yourself nearly indestructable; it's making yourself nearly indestructable and still able to chase people, open doors, hear people sneaking up on you, grab things, etc. If this guy were on patrol in Iraq, insurgants would kidnap him by catching him in a net, dragging him off, and removing the suit. It's not any better than just staying in a bunker all the time.
The DRM doesn't actually help Apple translate iPod sales into iTMS sales. Not having DRM that doesn't work on the iPod does help, but not having DRM at all would have the same effect. The major factor in people buying song online for their iPod from iTMS is other sites using DRM that the iPod doesn't support. You could maybe argue that Apple would like to keep the music industry demanding that sites put DRM on their music sales so that non-iTMS sites can't sell anything people want to buy. But, of course, the music industry doesn't really want to be limited to a single distribution channel, and iTMS competitors don't want to be irrelevant, so it's only in Apple's interest, and it's not Apple decision.
Music bought from iTMS isn't a big factor in whether they buy iPods. People's music collections are mostly in mp3, ripped from CDs, especially if they don't already have iPods. And Apple's brand loyalty is legendary, so people with iPods are generally not in the market for non-iPod music players, regardless of whether they have any music from iTMS. People know that the main reason to get Apple products is the user experience, and they know that you get this experience by continuing to buy from Apple.
IDE-SCSI no longer works from 2.6.10 onwards at least up to 2.6.16
/dev/sda now. Not only is the functionality of treating "IDE" devices as "SCSI" still available, it doesn't require a special module, and it's becoming default. They're eventually going to ditch "IDE" entirely, because it's crufty old code that nobody really likes. Of course, with any luck, PATA controllers will be enumerated and the information put in sysfs along with master/slave, so you'll still be able to get /dev/hda out of udev for your PATA hard drive.
It's ironic that you mention IDE-SCSI as not working. The latest excitement is that devices that used to be treated as IDE are now being treated as SCSI if you build the appropriate drivers, so people are finding that the drives they thought were "IDE" are actually "ATA", and on
As far as stability is concerned, I've had exactly one kernel problem using a kernel that has ~9 patches that aren't from mainline. And that problem (it would break a device sharing a legacy IRQ with an nvidia ethernet card on a system with MSI support if you don't use msi=disable) was fixed in 2.6.18.y and 2.6.19.1.
The idea in the 2.4 days was that distros (and only distros) would fork off and maintain a release with hundreds of backported patches from the development series that won't be available in a stable vanilla kernel for several years. The idea now is that the latest 2.6.x should work for everybody. Backporting anything is a bad idea in general, and regressions should be fixed before a 2.6.x comes out, or shortly thereafter.
Actually, what we need is a substantial penalty for badly losing an infringement lawsuit you bring. As it is, the worst you can do by suing somebody is to have to pay their court costs and legal fees, and this only happens if the patent is invalid and you're demonstrated to have known it. (Sure, your patent can end up invalidated if it gets reexamined, but if it was bogus in the first place, you've only lost an asset that should have been worthless.)
If you sue someone for infringing your patent, and you're found to have been willfully misleading to the PTO in getting the patent, you should be liable to the defendants for triple the relief you requested, and the law firm that represented you should be sanctioned.
This would mean that it would be net beneficial to be sued by a patent troll, because you'll probably have an easy case, the plaintiff is likely pro se and incompetent, you'll recover court costs, and probably get any assets the troll happens to have. There'd also be little reason to settle or license bogus patents, because you'd be able to make money infringing them.
The current situation is kind of like how it would be if people convicted of robbing banks only had to give back the money.
Testing doesn't really help much. The cases you're worried about are the ones which aren't going to happen in 12 years of actual use, and which are only triggered by specially-constructed input. If you knew how to test in order to trigger the bug, you could just look at the code and see if the bug is there.
The main thing is really good design, good style, and unrushed review. One important thing is to do all of the tricky pointer-fiddling in a file of utility routines, so that it only has to be right once. Another is to get the compiler to report all your typos (e.g., there's a brilliant C trick with macros for getting the compiler to typecheck arguments in template-like ways before casting this information away and calling a function who correctness depends on things matching). Then, run it through valgrind and fix all of your uninitialized values, off-by-one errors, and memory leaks.
Wikipedia is actually extremely verbose. It's just structured in such a way that having many many short articles isn't too difficult to use. So Wikipedia has the space for a detailed article on the 40th US Congress, and Britannica doesn't. This may seem insignificant, but if you're trying to find out the political conditions surrounding the impeachments of US presidents, it's important, particularly if you also want similar information on the outcome of the election following the impeachment trial.