In my case just now, "/dev/hdb1 has gone 180 days without being checked; check forced". But normally my machine (which only starts things I want) takes less time than it takes Windows XP to wake up if you let it go to sleep (I don't think I've ever seen Windows XP boot).
Many distributions are slow because they check for new hardware, involving probing for a ton of stuff that requires I/O bus cycles. But if you happen to have Oracle, that's what will take all the time.
If they refuse to release code, they're in violation of the copyright law, which carries its own penalties, but doesn't mean that they have to accept license terms; they could stop distribting the copyrighted work, pay penalties, and go about their business. This would be the right thing to do if they had other obligations to other companies (which incidentally, are likely to be based on copyright law as well, involving some code owned by someone else licensed to them; releasing this code would not only be illegal, but would still not put it under the GPL, as it belongs to a non-liable third party). If they get into a situation where their obligations can't all be fulfilled, they get to pick which contract to breach, and deal with those consequences.
That said, what I mentioned is probably not the case with LinkSys, but is the case with nVidia; nVidia has been much more careful, as well. In addition, nVidia produces Linux-related work which is beneficial only to Linux users, unlike LinkSys, which produces Linux-related devices which are sold as complete systems. If nVidia were forced to stop distributing their drivers, Linux users with this chipset would be upset, and nobody else would be affected. For that matter, nVidia wouldn't lose money at that point, since people had already bought the cards. It would be a different matter if the nVidia Windows driver were derived from Linux, but that's unlikely.
First, a Oklahoma City court says that the FTC doesn't have the authority to regulate phone calls (previous story). In response, the FCC takes over (this story). Also, Congress specifically give the FTC authority to do this.
In Denver, the court buys the discrimination claim (sort of oddly, since discrimination has nothing to do with freedom of speach). The FTC plans to appeal the ruling.
Here is where it gets exciting: the FTC is adding to but no longer publishing the list, pending the appeal of the Denver ruling. On the other hand, the FCC is ready to start enforcing it on Wednesday. The telemarketters have asked for help, but the FCC, the Denver court, and the Supreme Court member overseeing the Denver court have all turned them down.
This means that, on Wednesday, telemarketters will be unable to determine whether or not you're on the list and illegal to call, and all three branches of the government are unsympathetic.
I personally feel that we should all congratulate the government on the situation. Except, of course, that the government is busy acting like they didn't want this to happen, but the telemarketters forced it to be this way.
The increased productivity caused by computers increases unemployment of people whose work did not create wealth, but instead allowed wealth to be created. Once these jobs don't require people, the people are then free to do things that do create wealth. Of course, that's not the most useful benefit, because there wasn't really a shortage of people who could do things before (at least since the end of the dot-com bubble). On the other hand, the versatility and intelligence of the average unemployed person increases, because people who used to do tasks that are easy for computers but hard for people are available to learn other skilled work.
What this means is that there are a lot of people who could do important tasks if they were trained; it is just necessary to identify the tasks that still require people, and train people to do them.
In some cases, they can't release complete specs for the hardware, because some of their proprietary stuff (or, worse, other people's) is in software. On the other hand, I'd be happy if they'd at least release something that's only missing user-space code. I.e., "take your data, and run it through this binary, and send it to the device; we won't tell you what the code does, but the rest of the system can be protected from it."
One thing I'd really like to see is the ability for the kernel to support user-space driver plug-ins, so that nVidia can do their thing in user-space and not taint the kernel; the kernel driver would do the final communication with the device so as to avoid the possibility of the plug-in messing up the system state. As a nice extra, it should be possible to run the same code in kernel space for performance, at the cost of tainting the kernel. Then people could debug the nVidia driver somewhat by putting it into userspace and seeing it if segfaults there.
I'd actually combine 1 and 2, to say that the location of any RFID tag must be clearly marked, and RFID tags in consumer products must be capable of being destroyed without damaging the product. Might as well leave it to the consumer to buy their own device for deactivating the tag. (Considering the frequency with which stores fail to deactivate EAS tags, I wouldn't want to rely on the store doing it for an RFID tag unless an alarm went off if it failed).
I think it's only for some products that there's a significant privacy issue involving the tags; I don't care if people can identify my couch, since it's sitting in my living room, which is easily identifiable. The bigger concern is tags on things I will carry around with me being used to track me; I'll be upset when somebody can recognize me by the wallet in my pocket.
(On 3, you're not going to get much security against humans with a safe without a changeable combination; those fire safes are only really useful to protect against a fire, and hold documents of importance but little value)
But it doesn't suck if it's not good music as much as buying albums sucks if they aren't good, because you it only costs you 15 second of your listening time to try something. It can't really suck; at worst, it's useless (if your taste and theirs don't intersect at all).
Furthermore, it doesn't even take up any of your listening time if you get your friends to listen to it and tell you what's good. It would be a neat hack to set up your mail client to provide the "X-Now-Playing" header, and, when reading a message, see if it's freely available and offer the option to play the song that the author was listening to while you read the message. Then, if you like it, buy the album.
The tuning being done for 2.6 is primarily based on reducing the latency of interactive tasks in the face of intensive background tasks. That is, your normal desktop PC will be a better desktop at the cost of being a worse workstation (your windows move smoothly, your keyboard and mouse respond instantly, your music doesn't skip, but your compiler may take longer).
This is largely due to people finding way to measure the sorts of performance you actually care about for desktops. This is at the expense of other benchmarks.
This benchmark is more relevant to servers, and shows improvement on large servers and a bit of degradation on small servers.
A regular telephone line isn't data. A regular telephone line is a piece of copper which is strung between your house and a telephone pole. A regular telephone line also involves space in routing tables, rights to some use of the cables between the telephone poles, and so forth.
The tax is due to the infrastructure requirements of the phone line, not due to the data sent over it. If the want to replace the telephone taxes with something relevant to VoIP, they should be taxing the last mile connections.
Not a chemical reaction, but just that the particular dyes don't really absorb the full spectrum between them. Remember that, while eyes only see three colors (and combinations of them), there is a spectrum of wavelengths of light, and you have to stop all of them to get black. Doing so effectively is best done with a fourth ink.
Another problem with the "rational economizer" idea is that it fails to take into account the costs and benefits of busily calculating costs and benefits. Thinking too hard about your situation may not be the optimal thing to do (in fact, in the limit, it's no better than doing nothing at all, and far more boring). For most people, gut instinct and not worrying produces better results than trying to be rational, but those results are much harder to predict. So add a third factor: laziness. A person will only choose one thing over another based on selfishness or compassion if the benefits to themself or others outweigh the effort of establishing those benefits. Otherwise the person will chose randomly or based on insignificant factors.
Concerning compassion and selfishness, there are interesting game theory results showing that, in many circumstances the optimal strategy for an individual is to try to help anyone who has not been found to be taking advantage of you, and to forgive as quickly as possible if the other's behavior improves. So a rational participant who realizes this will act with compassion toward anyone who shows compassion and toward anyone new. If anyone is at all helpful, the cooperative group will quickly exclude and outcompete the uncompassionate individuals.
Of course, this depends on a situation in which it is productive to cooperate; if there's nothing to be gained in your particular situation by working together, there's no point in being compassionate.
It wouldn't be a very good DNC list if they couldn't tell who was on it, would it? But if your number is on the list, and the rule is not in effect, and they call you, you don't have to feel rude about hanging up on them.
The situation is actually that it is a pain for them to deal with a list of phone numbers; they just call every possible phone number (except for ones like the weather, the time, information, etc). They don't want to have to exclude numbers from a list, nor do they want to include numbers from a list.
They can understand the gravity of the situation from the number of people the representatives represent. It can also help if people call them and say, "I support this group on this issue." But calling them up and trying to explain the dangers of software patents just takes up their time.
There are a whole lot of citizens, and MEPs only expect to need a relatively small staff. MEPs, even if they don't favor industry representatives, really prefer hearing from representatives over hearing from the entire represented group. On most issues, concerned citizens organize or join existing organizations, which lobby on their behalf. This has become important to a lot of people pretty suddenly, which means that a lot of people are talking to their MEPs directly. It doesn't really give the MEP a good idea of the argument; if that many people are trying to talk to you individually, you can't even figure out what side each one is on, let alone sort out the different arguments or notice arguments you haven't heard before.
In such situations, the correct thing to do is really to deal the legislation, so that the citizens can sort themselves into groups based on their views and make coherent presentations of their concerns.
If mass transit were actually too cheap to meter, the costs associated with the extra riders would be recovered due to not trying to charge either the existing customers or the new riders. For that matter, if you just don't add more trains, you'll limit the ridership due to crowding instead of cost.
Mass transit is not actually too cheap to meter, because metering it is pretty cheap, and the constant costs of mass transit are relatively high. Mass transit is actually a different case, where the incremental costs are small compared to the constant cost. It doesn't cost the subway anything to take you from point A to point B, provided they don't run another train due to you. So the subway doesn't care about turnstile-jumpers so long as there aren't enough that paying riders notice or there is overcrowding.
In this case, someone reading the code found a bug of a type that they had not considered before. So they fixed it, and started looking for other bugs of that type. They found that there were other bugs of the same type, and fixed those. Now they've found a bug in some code they don't use themselves, which has required further patching.
OSS code is not appreciably less buggy than closed code when it is written; it becomes more secure as bugs get fixed that wouldn't have been found if it weren't open. Here we have bugs being found and fixed.
IIRC, that test (or other similar ones) found that there are types of music that sound markedly worse with each codec. For any lossy format, it's possible to construct some music that emphasizes the bit that would be lost. And you might even find someone who would actually like to listen to that music. Also, you can hear different losses on headphones vs computer speakers vs nice speakers.
So, if you want to make sure not to lose anything important from an arbitrary CD, you should use FLAC to make it smaller.
It would actually be interesting for someone to make an OGG variant especially for headphones, which would ditch everything the headphones won't be able to reproduce anyway.
The question should be, is it possible to create a truly secure product when there's no opportunity for public code review? My answer would be "no".
The need is actually for peer review, not public review. Of course, getting most security-expert peers to review something usually requires public review (since most peers wouldn't bother). But the NSA has been able to develop cryptosystems without outside review (by employing half of the experts at the time), and MS might have been able to do it if their codebase weren't too unwieldy to review.
It makes sense that there would be a charge for each phone number, as phone numbers are a limited resource shared with the traditional phone network. It is for pure VoIP applications, where the participants use some mechanism other than the phone system's numbering to find each other, that regulation doesn't make sense.
Vonage doesn't seem to offer the service currently, but it should be possible to avoid this charge if you were willing to not have a phone number, and only take calls directed by your email address (not using email, but using the address as an identifier). For such customers, Vonage wouldn't have to deal with the FSUSF at all. But it makes sense that the telephone-to-VoIP connection should cost something for the telephone side, since that's not generic IP traffic.
Linux is, in fact, totally irrelevant to the possibility for email-borne viruses; as you note, email programs can execute local programs (necessary for viewers, anyway), make TCP connections (like sending email, for instance, which is important), and write to local files owned by the user (like your mailbox and places you wish to save documents).
On the other hand, Linux email clients are more proof against viruses than Outlook, because of the 1% of desktop users who use Linux, they're widely split between email clients, and the security holes in them are different. If someone found the same security hole in pine, mutt, evolution, and mozilla's client, they could write an effective virus, but one of the many security holes that exist for one or another of these will only get you a few users, and not enough to spread the virus very much.
Additionally, plastic is much harder to clean effectively than tile and such, particularly the textured sort of plastic that computers and phones are covered with.
My toilet is cleaner than my telephone, which can easily be determined by inspection. Of course, my toilet is a device whose purpose is to clean itself after every use, so it would be obviously broken if it were not cleaner than most anything else in my house (aside from things like the tea kettle which are designed to be boiled on a regular basis, or the dishwasher, which also cleans itself, but isn't as dirty beforehand).
The reason people find this sort of thing surprising is that, when asked to think of the average bathroom, they actually think of a public restroom in need of cleaning, rather than the actual average bathroom. Certainly the worst bathroom is worse than the worst computer, and people only tend to remember the bad bathrooms.
If they supported third-party applications, those wouldn't be third-party applications, would they? It's up to the third-party applications to track new versions if they want to play. Yahoo doesn't change things so often that it's too much trouble.
And this case is clearly tryable in England; if it was tryable (and went to the Supreme Court) in the US, it stands to reason that it would be tryable in England, which has sort of similar IP law. Furthermore, US Supreme Court descisions don't establish precedent in England, and British law is not identical, either.
Of course, it's unlikely that a victory for Navitaire would be allowed to stand; no software company could really release any software in the UK safely, and UK businesses depend on software.
It's a good thing that sendmail, sshd (and RPC, for that matter) aren't needed on the desktop, then. Hopefully, the people who won't bother to patch their sendmails won't install sendmail in the first place.
It didn't produce new results, and the design already existed. It's a great feat of construction, especially because he built it from spare parts, but not ground-breaking science or engineering.
On the other hand, he should really be on Junkyard Wars.
Slashdot Mirror
In my case just now, "/dev/hdb1 has gone 180 days without being checked; check forced". But normally my machine (which only starts things I want) takes less time than it takes Windows XP to wake up if you let it go to sleep (I don't think I've ever seen Windows XP boot).
Many distributions are slow because they check for new hardware, involving probing for a ton of stuff that requires I/O bus cycles. But if you happen to have Oracle, that's what will take all the time.
If they refuse to release code, they're in violation of the copyright law, which carries its own penalties, but doesn't mean that they have to accept license terms; they could stop distribting the copyrighted work, pay penalties, and go about their business. This would be the right thing to do if they had other obligations to other companies (which incidentally, are likely to be based on copyright law as well, involving some code owned by someone else licensed to them; releasing this code would not only be illegal, but would still not put it under the GPL, as it belongs to a non-liable third party). If they get into a situation where their obligations can't all be fulfilled, they get to pick which contract to breach, and deal with those consequences.
That said, what I mentioned is probably not the case with LinkSys, but is the case with nVidia; nVidia has been much more careful, as well. In addition, nVidia produces Linux-related work which is beneficial only to Linux users, unlike LinkSys, which produces Linux-related devices which are sold as complete systems. If nVidia were forced to stop distributing their drivers, Linux users with this chipset would be upset, and nobody else would be affected. For that matter, nVidia wouldn't lose money at that point, since people had already bought the cards. It would be a different matter if the nVidia Windows driver were derived from Linux, but that's unlikely.
This whole thing is a huge mess at this point.
First, a Oklahoma City court says that the FTC doesn't have the authority to regulate phone calls (previous story). In response, the FCC takes over (this story). Also, Congress specifically give the FTC authority to do this.
In Denver, the court buys the discrimination claim (sort of oddly, since discrimination has nothing to do with freedom of speach). The FTC plans to appeal the ruling.
Here is where it gets exciting: the FTC is adding to but no longer publishing the list, pending the appeal of the Denver ruling. On the other hand, the FCC is ready to start enforcing it on Wednesday. The telemarketters have asked for help, but the FCC, the Denver court, and the Supreme Court member overseeing the Denver court have all turned them down.
This means that, on Wednesday, telemarketters will be unable to determine whether or not you're on the list and illegal to call, and all three branches of the government are unsympathetic.
I personally feel that we should all congratulate the government on the situation. Except, of course, that the government is busy acting like they didn't want this to happen, but the telemarketters forced it to be this way.
The increased productivity caused by computers increases unemployment of people whose work did not create wealth, but instead allowed wealth to be created. Once these jobs don't require people, the people are then free to do things that do create wealth. Of course, that's not the most useful benefit, because there wasn't really a shortage of people who could do things before (at least since the end of the dot-com bubble). On the other hand, the versatility and intelligence of the average unemployed person increases, because people who used to do tasks that are easy for computers but hard for people are available to learn other skilled work.
What this means is that there are a lot of people who could do important tasks if they were trained; it is just necessary to identify the tasks that still require people, and train people to do them.
In some cases, they can't release complete specs for the hardware, because some of their proprietary stuff (or, worse, other people's) is in software. On the other hand, I'd be happy if they'd at least release something that's only missing user-space code. I.e., "take your data, and run it through this binary, and send it to the device; we won't tell you what the code does, but the rest of the system can be protected from it."
One thing I'd really like to see is the ability for the kernel to support user-space driver plug-ins, so that nVidia can do their thing in user-space and not taint the kernel; the kernel driver would do the final communication with the device so as to avoid the possibility of the plug-in messing up the system state. As a nice extra, it should be possible to run the same code in kernel space for performance, at the cost of tainting the kernel. Then people could debug the nVidia driver somewhat by putting it into userspace and seeing it if segfaults there.
I'd actually combine 1 and 2, to say that the location of any RFID tag must be clearly marked, and RFID tags in consumer products must be capable of being destroyed without damaging the product. Might as well leave it to the consumer to buy their own device for deactivating the tag. (Considering the frequency with which stores fail to deactivate EAS tags, I wouldn't want to rely on the store doing it for an RFID tag unless an alarm went off if it failed).
I think it's only for some products that there's a significant privacy issue involving the tags; I don't care if people can identify my couch, since it's sitting in my living room, which is easily identifiable. The bigger concern is tags on things I will carry around with me being used to track me; I'll be upset when somebody can recognize me by the wallet in my pocket.
(On 3, you're not going to get much security against humans with a safe without a changeable combination; those fire safes are only really useful to protect against a fire, and hold documents of importance but little value)
But it doesn't suck if it's not good music as much as buying albums sucks if they aren't good, because you it only costs you 15 second of your listening time to try something. It can't really suck; at worst, it's useless (if your taste and theirs don't intersect at all).
Furthermore, it doesn't even take up any of your listening time if you get your friends to listen to it and tell you what's good. It would be a neat hack to set up your mail client to provide the "X-Now-Playing" header, and, when reading a message, see if it's freely available and offer the option to play the song that the author was listening to while you read the message. Then, if you like it, buy the album.
The tuning being done for 2.6 is primarily based on reducing the latency of interactive tasks in the face of intensive background tasks. That is, your normal desktop PC will be a better desktop at the cost of being a worse workstation (your windows move smoothly, your keyboard and mouse respond instantly, your music doesn't skip, but your compiler may take longer).
This is largely due to people finding way to measure the sorts of performance you actually care about for desktops. This is at the expense of other benchmarks.
This benchmark is more relevant to servers, and shows improvement on large servers and a bit of degradation on small servers.
A regular telephone line isn't data. A regular telephone line is a piece of copper which is strung between your house and a telephone pole. A regular telephone line also involves space in routing tables, rights to some use of the cables between the telephone poles, and so forth.
The tax is due to the infrastructure requirements of the phone line, not due to the data sent over it. If the want to replace the telephone taxes with something relevant to VoIP, they should be taxing the last mile connections.
Not a chemical reaction, but just that the particular dyes don't really absorb the full spectrum between them. Remember that, while eyes only see three colors (and combinations of them), there is a spectrum of wavelengths of light, and you have to stop all of them to get black. Doing so effectively is best done with a fourth ink.
Another problem with the "rational economizer" idea is that it fails to take into account the costs and benefits of busily calculating costs and benefits. Thinking too hard about your situation may not be the optimal thing to do (in fact, in the limit, it's no better than doing nothing at all, and far more boring). For most people, gut instinct and not worrying produces better results than trying to be rational, but those results are much harder to predict. So add a third factor: laziness. A person will only choose one thing over another based on selfishness or compassion if the benefits to themself or others outweigh the effort of establishing those benefits. Otherwise the person will chose randomly or based on insignificant factors.
Concerning compassion and selfishness, there are interesting game theory results showing that, in many circumstances the optimal strategy for an individual is to try to help anyone who has not been found to be taking advantage of you, and to forgive as quickly as possible if the other's behavior improves. So a rational participant who realizes this will act with compassion toward anyone who shows compassion and toward anyone new. If anyone is at all helpful, the cooperative group will quickly exclude and outcompete the uncompassionate individuals.
Of course, this depends on a situation in which it is productive to cooperate; if there's nothing to be gained in your particular situation by working together, there's no point in being compassionate.
It wouldn't be a very good DNC list if they couldn't tell who was on it, would it? But if your number is on the list, and the rule is not in effect, and they call you, you don't have to feel rude about hanging up on them.
The situation is actually that it is a pain for them to deal with a list of phone numbers; they just call every possible phone number (except for ones like the weather, the time, information, etc). They don't want to have to exclude numbers from a list, nor do they want to include numbers from a list.
They can understand the gravity of the situation from the number of people the representatives represent. It can also help if people call them and say, "I support this group on this issue." But calling them up and trying to explain the dangers of software patents just takes up their time.
There are a whole lot of citizens, and MEPs only expect to need a relatively small staff. MEPs, even if they don't favor industry representatives, really prefer hearing from representatives over hearing from the entire represented group. On most issues, concerned citizens organize or join existing organizations, which lobby on their behalf. This has become important to a lot of people pretty suddenly, which means that a lot of people are talking to their MEPs directly. It doesn't really give the MEP a good idea of the argument; if that many people are trying to talk to you individually, you can't even figure out what side each one is on, let alone sort out the different arguments or notice arguments you haven't heard before.
In such situations, the correct thing to do is really to deal the legislation, so that the citizens can sort themselves into groups based on their views and make coherent presentations of their concerns.
If mass transit were actually too cheap to meter, the costs associated with the extra riders would be recovered due to not trying to charge either the existing customers or the new riders. For that matter, if you just don't add more trains, you'll limit the ridership due to crowding instead of cost.
Mass transit is not actually too cheap to meter, because metering it is pretty cheap, and the constant costs of mass transit are relatively high. Mass transit is actually a different case, where the incremental costs are small compared to the constant cost. It doesn't cost the subway anything to take you from point A to point B, provided they don't run another train due to you. So the subway doesn't care about turnstile-jumpers so long as there aren't enough that paying riders notice or there is overcrowding.
In this case, someone reading the code found a bug of a type that they had not considered before. So they fixed it, and started looking for other bugs of that type. They found that there were other bugs of the same type, and fixed those. Now they've found a bug in some code they don't use themselves, which has required further patching.
OSS code is not appreciably less buggy than closed code when it is written; it becomes more secure as bugs get fixed that wouldn't have been found if it weren't open. Here we have bugs being found and fixed.
IIRC, that test (or other similar ones) found that there are types of music that sound markedly worse with each codec. For any lossy format, it's possible to construct some music that emphasizes the bit that would be lost. And you might even find someone who would actually like to listen to that music. Also, you can hear different losses on headphones vs computer speakers vs nice speakers.
So, if you want to make sure not to lose anything important from an arbitrary CD, you should use FLAC to make it smaller.
It would actually be interesting for someone to make an OGG variant especially for headphones, which would ditch everything the headphones won't be able to reproduce anyway.
The question should be, is it possible to create a truly secure product when there's no opportunity for public code review? My answer would be "no".
The need is actually for peer review, not public review. Of course, getting most security-expert peers to review something usually requires public review (since most peers wouldn't bother). But the NSA has been able to develop cryptosystems without outside review (by employing half of the experts at the time), and MS might have been able to do it if their codebase weren't too unwieldy to review.
It makes sense that there would be a charge for each phone number, as phone numbers are a limited resource shared with the traditional phone network. It is for pure VoIP applications, where the participants use some mechanism other than the phone system's numbering to find each other, that regulation doesn't make sense.
Vonage doesn't seem to offer the service currently, but it should be possible to avoid this charge if you were willing to not have a phone number, and only take calls directed by your email address (not using email, but using the address as an identifier). For such customers, Vonage wouldn't have to deal with the FSUSF at all. But it makes sense that the telephone-to-VoIP connection should cost something for the telephone side, since that's not generic IP traffic.
Linux is, in fact, totally irrelevant to the possibility for email-borne viruses; as you note, email programs can execute local programs (necessary for viewers, anyway), make TCP connections (like sending email, for instance, which is important), and write to local files owned by the user (like your mailbox and places you wish to save documents).
On the other hand, Linux email clients are more proof against viruses than Outlook, because of the 1% of desktop users who use Linux, they're widely split between email clients, and the security holes in them are different. If someone found the same security hole in pine, mutt, evolution, and mozilla's client, they could write an effective virus, but one of the many security holes that exist for one or another of these will only get you a few users, and not enough to spread the virus very much.
Additionally, plastic is much harder to clean effectively than tile and such, particularly the textured sort of plastic that computers and phones are covered with.
My toilet is cleaner than my telephone, which can easily be determined by inspection. Of course, my toilet is a device whose purpose is to clean itself after every use, so it would be obviously broken if it were not cleaner than most anything else in my house (aside from things like the tea kettle which are designed to be boiled on a regular basis, or the dishwasher, which also cleans itself, but isn't as dirty beforehand).
The reason people find this sort of thing surprising is that, when asked to think of the average bathroom, they actually think of a public restroom in need of cleaning, rather than the actual average bathroom. Certainly the worst bathroom is worse than the worst computer, and people only tend to remember the bad bathrooms.
If they supported third-party applications, those wouldn't be third-party applications, would they? It's up to the third-party applications to track new versions if they want to play. Yahoo doesn't change things so often that it's too much trouble.
And this case is clearly tryable in England; if it was tryable (and went to the Supreme Court) in the US, it stands to reason that it would be tryable in England, which has sort of similar IP law. Furthermore, US Supreme Court descisions don't establish precedent in England, and British law is not identical, either.
Of course, it's unlikely that a victory for Navitaire would be allowed to stand; no software company could really release any software in the UK safely, and UK businesses depend on software.
It's a good thing that sendmail, sshd (and RPC, for that matter) aren't needed on the desktop, then. Hopefully, the people who won't bother to patch their sendmails won't install sendmail in the first place.
It didn't produce new results, and the design already existed. It's a great feat of construction, especially because he built it from spare parts, but not ground-breaking science or engineering.
On the other hand, he should really be on Junkyard Wars.