I can think of several widely used systems that are backed by databases that work just fine. Slashdot wasn't built on a massive budget. Amazon doesn't have a history of "bleeding" data from one user to another. Google and Yahoo are certainly capable of handling tremendous loads.
I see several possible problems here. First, it is possible that this software was rushed into use before it was ready. Given the political pressures involved, I suspect that is part of the problem.
Second, I doubt that all of the programmers involved are of guru caliber. I don't intend to malign them. Even assuming that you have nothing but above-average programmers, when you build a huge project with lots of designers and coders, there are going to be miscommunications and some details that just aren't communicated.
Third, I would bet that this project has so much design documentation done up front that it is impossible for anyone to wrap their brains around the whole thing. This is, at best, a 1.0 release. And there are going to be design flaws in it. And the guys writing the code aren't likely to have a broad enough overview of it to spot them all. They also undoubtedly tripped over a lot of things that weren't specified up front and should have been. It is the nature of the game. But they weren't free to just choose a good solution when the questions came up.
The projects I cited at the beginning were developed by small teams with a vision of what they wanted to build. Within the constraints of the tools they had to work with and the general idea of what they were building, they were free to change the rules. They could refactor to their hearts' content. That is not going to be the case on huge government contracts.
Everything that we know about open source, agile/extreme programming, etc. doesn't apply to this kind of project.
Some solutions are easier to use. For example, building a GUI from a standard set of widgets is dirt simple using Visual Studio. But good design is still hard, and good analysis is even harder. Even assuming that your app doesn't have bugs that crash it, many naive algorithms that work just fine with your sample data don't scale to huge databases or high transaction rates or huge numbers of users.
That doesn't make ease of use bad in itself. However, there is also a very real danger that bosses, customers and users will perceive the project as being done because the GUI looks complete and polished. Joel on Software has a good article on this very problem entitled "The Iceberg Secret, Revealed"
Prof. David D. Friedman explains at some length in Chapter 19: The Political Marketplace of his book Price Theory: An Intermediate Text the harm that is done by tariffs. The problem is that the benefit is very concentrated, while the cost is spread throughout the rest of the economy. In this case, it is even tougher because Micron is making the argument that their request is in response to subsidies favoring their competitor. I'm sure that most Slashdot readers can follow Friedman's math if they have the patience for it. But for those who can't or don't, he makes his argument in words as well as equations.
While this tariff would benefit Micron, it would cost lots of other companies money. What I would prefer to see is for the US to push the threat of a tariff. Let South Korea take their case to the WTO. Send in a team of vicious attack lawyers who will readily agree that both the tariff and the South Korean subsidy are wrong. Let's see Micron and Hynix compete head-to-head without tariffs or subsidies.
Their subsidy is at least as harmful to their economy as a tariff would be to ours. Simply put, we have the option of avoiding the tariff by not buying the goods. The citizens of South Korea pay for the subsidy regardless of their own individual choices, and at least in the short run, regardless of whether the chips even get sold.
That sounds pretty familiar. I've been seeing symptoms like that under 2.4.18 with Debian. I thought I was tripping over a bug in the nVidia driver, but I'm not sure anymore. The video certainly went to "plaid mode". I can't reliably reproduce it now because I tripped over what appears to be an ext3 bug that is fixed in 2.4.20. The ext3 driver didn't handle corrupted inodes at all well. I got a kernel oops while running fsck after a hard reboot because the thing hung. If you want to see an unusable file system, try crashing part way through an fsck./var is one of the file systems that got hit. I've been intending to reformat and reload that box when I finally diagnose the root cause of the problem. This sounds like it might be it, although I welcome other insights.
I am currently working on a software development project migrating code _away_ from QNX to Linux. Every time I have to work on the old QNX project I want to bang my head against the monitor.
That can depend a great deal on which version of QNX you are looking at. It you really have an older project that is running on say, QNX 4, then it would be painful. I've worked quite a bit with it. The most painful thing about it is that I remember when Linux looked and felt like that years ago. That's because QNX 6 is current. Most of the things that you've come to expect under Linux are available under QNX.
Where QNX really shines, is in faster context switches, and a predictable real time scheduler. Of course, if you invert the priority of your processes, good luck. The QNX folks have also provided a nice message passing library. Okay, there are other ways to handle interprocess communication. But their stuff just keeps on working.
The only reason that I would recommend porting away from QNX to Linux is if there was a specific need driving the port. If all of your other code is under Linux, or you need to save the licensing costs, or there are specific tools or libraries that haven't been ported. QNX has a pretty familiar feel to anyone familiar with multiple Unices.
Now the GUI libraries (I'm talking QNX 4 here, not the newer Photon stuff), are a bit of a pain. They harken back to darker days. The effort to port QNX 4 GUI code to anything else would be bigger than it is worth in a lot of cases.
QNX gets the embedded, real time stuff right. Don't underrate that.
Compiling and installing drivers for different kernel versions is not rocket science. If every distro installed the kernel source, make, and gcc by default, supplying drivers with installation scripts that just do it wouldn't be hard at all. They'd just do the standard:
./configure make install
automatically for you. It wouldn't really matter what your distro was.
Yes, but its in your best interest to release your changes back to the communtiy so you won't have to manually merge code in later versions.
In fact, I believe you have the strongest argument for releasing deltas back to the community. Basically, the benefits of open source are generally the greatest with code that serves a widely used general purpose. Individual developers will do the porting work to new platforms or add specific new features. But everyone gets to leverage the larger body of code.
You pay for that in one of two ways. First, you can keep all of your work private. You don't release your modification and you can keep the source secret. You have to merge your changes into each subsequent release yourself. You end up paying an additional price for any later work the other contributors do. And there is a very real possibility that someone else will implement the same feature you did, with a different interface.
The second way you can pay for it is to release your own changes. Your legal department was right to emphasize that you have to exercise caution not to release code that is to be kept proprietary. But you gain the benefits of getting your code out to a wider audience. It will be more rigorously reviewed and tested. It may get enhanced in ways that are useful to you in turn.
A rule of thumb to use is to do development on open source tools to enhance those tools only. If the latest release of something no longer runs on your development platform, do the port and release the changes back to the community. Let your company's lawyers understand the reasons for the code you wrote. There are often two reasons. The first is because you needed a tool that did that. The second is that the cheapest, fastest way to get it was to enhance an open source project that was close. And releasing your own changes back to the community will usually cost less and get you more in the long run.
number, street, city, state, and postal code all become 10 digits.
Which is fine when you are printing the addresses from a database. That's great for businesses. But remembering addresses is going to be a real pain. Worse still, it divorces the postal address from the real world components that you use to physically find the place. Oh, and most of the addresses I use on a regular basis are clustered. So only a few of the digits will vary. So I will be trying to remember a new piece of information about each of my friends. And it will be non-mnemonic and easily interchangable with the addresses of each of several other friends. No thanks.
I read the entire Illuminatis trilogy straight through in about 3 days. I think I was supposed to be doing something else at the time. Never trust anyone with the initials H.C.
I think a 24% crash in SCOs stock price today shows what the market thinks of this news, and exactly how much Linus has to fear.
Although if I were Linus I wouldn't exactly take the market as my best legal opinion in the matter... IANAL and the M(arket) is sure as hell is NAL either.
No question about it. The stock market is not a legal advisor. However, there doesn't seem to be a great deal of confidence that SCO will win this one. What that indicates is that a wider world than Slashdot has judged their claims to be weak.
This functionality is now provided by instant messengers.
Actually, I thought about that point when I wrote my original comment. You are completely right. And it validates my point. Charging for e-mail will drive people to alternative protocols. There are already numerous ways to communicate with people online. If e-mail costs per message, we'll grab onto something else in a big hurry.
Frankly, I could see a merging of e-mail, P2P and IM creating something with some of the capabilities of each. A distributed file sharing service to find addresses, and a P2P IM system to provide e-mail without a server to friends who are currently online. That's just a back-of-the-envelope brainstorm. Build whatever protocol you like on top of TCP, UDP or even raw IP.
<!-- You could even bury messages in comments posted on major web sites and build clients to send and retrieve them. -->
Right now, part of the problem is that ISPs and users are bearing the cost of spam. In the end, any of the costs to the ISPs are passed on to their customers. Making us pay to send, is going to cut down on the usefulness of e-mail to legitimate users. If I have to pay by the message, I'm going to think twice about a quick note to a friend asking if he wants to meet for lunch. I'll pass along fewer cool URLs.
On the flip side, spammers will still send from addresses that can't be collected from. Many spammers are willing to harass people, steal the bandwidth they've paid for, and lie to people about everything from the return address on the e-mail to the fact that the opt-out procedure is actually just a verification that they have a live address. We won't even go into their claims about the efficacy of the products they sell. Is it even a stretch to believe that they will continue to lie to ISPs and defraud them of payments for the e-mail they send?
What about all of the free software out there? Emacs gets downloaded as source, precompiled binaries for various platforms, and bundled with virtually every free OS out there. How can you aggregate all of the numbers from all of the servers and get a single number for the most downloaded app.
Giving statistics for the number of downloads from a single service is at least possible. But it falls far short of measuring the most downloaded app. Most free software downloads are off of many other sites.
I think a fair number of hackers aren't satisfied until they know how something works, why it works, and that it works well and will continue to. I think this translates into an urge to do a lot of things ourselves. On the darker side, it feeds the "Not Invented Here" syndrome.
We trust what we've made ourselves, and what we've taken apart and reassembled. When a real hacker say he understands something, he truly does understand it. He generally could recreate it given the same materials the original was built with and the same tools. Often, he can make many of the tools too.
I think a lot of people would fail to see the connection between FIRST and "That Segway Guy..." but hey, the segway got lots of coverage in the news so it's got to be good, right?
I've met Dean Kamen. I don't think I've ever seen anyone with so much energy. Honestly, I think that the Segway was a business mistake, but technically, it is quite an achievement. I try not to emphasize the connection because he has done so many other things that have never made the news. Once Segway comes up, people seem to miss everything else.
The Robot Wars phenomenon, begun in San Francisco...
The phenomenom, in the form of robots actually attacking each other, may have started there. But robotic competitions have a longer history. There is an annual competition for high school students called FIRST (For Inspiration and Recognition of Science and Technology) that is well worth the time to get involved with. Adults get to play too. The teams need sponsors and mentors.
For many megs of answers about why software isn't 100% reliable, read Risks Digest.
There is indeed hardware out there with this level of reliability (like an AT&T 5ESS/Lucent 7R/E phone switch) however it is highly expensive and very unflexable.
I don't mean to bash AT&T. In fact, the very infrequency of this sort of problem is a strong argument for their reliability. I had to go back to the pre-Lucent days for this one, folks. However, they do have some occasional bugs in their software. And it makes the news when they do:
Over time, the size and complexity of the problems we can solve with computers has increased because of two factors. First, hardware has become faster, more reliable, and tailored to our use. Secondly, the software tools we use have increased the number and scope of things we can abstract away. Thus, we continue to work at the boundary of our capabilities, or not terribly far from it. The demands of scientific curiousity and the marketplace will continue to drive that.
Up to a point, we demand reliability. For all that Windows has a reputation for crashing, Microsoft has improved it over the years. Whether Windows XP is more or less stable than Linux or *BSD can be debated endlessly. But there is no refuting the fact that it is more stable than Windows 95 was.
Beyond a certain point, additional reliability cost more than it is worth. This is true even if we are talking about the most demanding uses. When the cost of additional reliability makes a technology unaffordable, compromises will be made. The point at which extra reliability is too expensive differs from user to user and application to application.
It is not clear that it is possible to write software that is provably bug-free. What is clear is that reducing the number of bugs while holding the development methodology constant will tend to increase the cost. Extreme Programming and other similar disciplines have argued, convincingly, that in the long run, this can reduce costs over the life of a product. But when you are trying to hit a market window, or launch a product before your venture capital runs out, corners often get cut.
I think that the long term trend is for each lower layer of abstraction to become more reliable over time. At the same time, more is added at the leading edge. New development, especially in uncharted territory, has new bugs.
I can't confirm this with statistics, but I suspect that the reliability of software as an aggregate has either varied around a constant, or has improved slightly over time. What I wonder is whether the reliablity measured against the total amount of code has been slowly improving.
There's one problem with IBM countersuing right now. If they do sue SCO into bankruptcy, someone else will end up with the IP rights that SCO is suing over. This whole thing could come up again. Assuming that we are correct and that IBM is extremely likely to win this case, it is in their interest to get it decided in their favor. Then it doesn't matter much what happens to SCO.
I get spam from a lot of places. I read several I18N/L10N mailing lists as well. I can't even read many of the languages I get spammed in. (For the record, I like the Korean spam the best. So far, it appears to have been for kitchen products. It is nicely formatted. I presume it would be readable if I read Korean.) But my point is, spam is coming from places outside their jurisdiction.
Slashdot Mirror
I can think of several widely used systems that are backed by databases that work just fine. Slashdot wasn't built on a massive budget. Amazon doesn't have a history of "bleeding" data from one user to another. Google and Yahoo are certainly capable of handling tremendous loads.
I see several possible problems here. First, it is possible that this software was rushed into use before it was ready. Given the political pressures involved, I suspect that is part of the problem.
Second, I doubt that all of the programmers involved are of guru caliber. I don't intend to malign them. Even assuming that you have nothing but above-average programmers, when you build a huge project with lots of designers and coders, there are going to be miscommunications and some details that just aren't communicated.
Third, I would bet that this project has so much design documentation done up front that it is impossible for anyone to wrap their brains around the whole thing. This is, at best, a 1.0 release. And there are going to be design flaws in it. And the guys writing the code aren't likely to have a broad enough overview of it to spot them all. They also undoubtedly tripped over a lot of things that weren't specified up front and should have been. It is the nature of the game. But they weren't free to just choose a good solution when the questions came up.
The projects I cited at the beginning were developed by small teams with a vision of what they wanted to build. Within the constraints of the tools they had to work with and the general idea of what they were building, they were free to change the rules. They could refactor to their hearts' content. That is not going to be the case on huge government contracts.
Everything that we know about open source, agile/extreme programming, etc. doesn't apply to this kind of project.
Some solutions are easier to use. For example, building a GUI from a standard set of widgets is dirt simple using Visual Studio. But good design is still hard, and good analysis is even harder. Even assuming that your app doesn't have bugs that crash it, many naive algorithms that work just fine with your sample data don't scale to huge databases or high transaction rates or huge numbers of users.
That doesn't make ease of use bad in itself. However, there is also a very real danger that bosses, customers and users will perceive the project as being done because the GUI looks complete and polished. Joel on Software has a good article on this very problem entitled "The Iceberg Secret, Revealed"
Prof. David D. Friedman explains at some length in Chapter 19: The Political Marketplace of his book Price Theory: An Intermediate Text the harm that is done by tariffs. The problem is that the benefit is very concentrated, while the cost is spread throughout the rest of the economy. In this case, it is even tougher because Micron is making the argument that their request is in response to subsidies favoring their competitor. I'm sure that most Slashdot readers can follow Friedman's math if they have the patience for it. But for those who can't or don't, he makes his argument in words as well as equations.
While this tariff would benefit Micron, it would cost lots of other companies money. What I would prefer to see is for the US to push the threat of a tariff. Let South Korea take their case to the WTO. Send in a team of vicious attack lawyers who will readily agree that both the tariff and the South Korean subsidy are wrong. Let's see Micron and Hynix compete head-to-head without tariffs or subsidies.
Their subsidy is at least as harmful to their economy as a tariff would be to ours. Simply put, we have the option of avoiding the tariff by not buying the goods. The citizens of South Korea pay for the subsidy regardless of their own individual choices, and at least in the short run, regardless of whether the chips even get sold.
That sounds pretty familiar. I've been seeing symptoms like that under 2.4.18 with Debian. I thought I was tripping over a bug in the nVidia driver, but I'm not sure anymore. The video certainly went to "plaid mode". I can't reliably reproduce it now because I tripped over what appears to be an ext3 bug that is fixed in 2.4.20. The ext3 driver didn't handle corrupted inodes at all well. I got a kernel oops while running fsck after a hard reboot because the thing hung. If you want to see an unusable file system, try crashing part way through an fsck. /var is one of the file systems that got hit. I've been intending to reformat and reload that box when I finally diagnose the root cause of the problem. This sounds like it might be it, although I welcome other insights.
I am currently working on a software development project migrating code _away_ from QNX to Linux. Every time I have to work on the old QNX project I want to bang my head against the monitor.
That can depend a great deal on which version of QNX you are looking at. It you really have an older project that is running on say, QNX 4, then it would be painful. I've worked quite a bit with it. The most painful thing about it is that I remember when Linux looked and felt like that years ago. That's because QNX 6 is current. Most of the things that you've come to expect under Linux are available under QNX.
Where QNX really shines, is in faster context switches, and a predictable real time scheduler. Of course, if you invert the priority of your processes, good luck. The QNX folks have also provided a nice message passing library. Okay, there are other ways to handle interprocess communication. But their stuff just keeps on working.
The only reason that I would recommend porting away from QNX to Linux is if there was a specific need driving the port. If all of your other code is under Linux, or you need to save the licensing costs, or there are specific tools or libraries that haven't been ported. QNX has a pretty familiar feel to anyone familiar with multiple Unices.
Now the GUI libraries (I'm talking QNX 4 here, not the newer Photon stuff), are a bit of a pain. They harken back to darker days. The effort to port QNX 4 GUI code to anything else would be bigger than it is worth in a lot of cases.
QNX gets the embedded, real time stuff right. Don't underrate that.
make install
automatically for you. It wouldn't really matter what your distro was.
In fact, I believe you have the strongest argument for releasing deltas back to the community. Basically, the benefits of open source are generally the greatest with code that serves a widely used general purpose. Individual developers will do the porting work to new platforms or add specific new features. But everyone gets to leverage the larger body of code.
You pay for that in one of two ways. First, you can keep all of your work private. You don't release your modification and you can keep the source secret. You have to merge your changes into each subsequent release yourself. You end up paying an additional price for any later work the other contributors do. And there is a very real possibility that someone else will implement the same feature you did, with a different interface.
The second way you can pay for it is to release your own changes. Your legal department was right to emphasize that you have to exercise caution not to release code that is to be kept proprietary. But you gain the benefits of getting your code out to a wider audience. It will be more rigorously reviewed and tested. It may get enhanced in ways that are useful to you in turn.
A rule of thumb to use is to do development on open source tools to enhance those tools only. If the latest release of something no longer runs on your development platform, do the port and release the changes back to the community. Let your company's lawyers understand the reasons for the code you wrote. There are often two reasons. The first is because you needed a tool that did that. The second is that the cheapest, fastest way to get it was to enhance an open source project that was close. And releasing your own changes back to the community will usually cost less and get you more in the long run.
A number of states already have their own registries that you can use now. The NY Do Not Call Registry has been up for a while now.
number, street, city, state, and postal code all become 10 digits.
Which is fine when you are printing the addresses from a database. That's great for businesses. But remembering addresses is going to be a real pain. Worse still, it divorces the postal address from the real world components that you use to physically find the place. Oh, and most of the addresses I use on a regular basis are clustered. So only a few of the digits will vary. So I will be trying to remember a new piece of information about each of my friends. And it will be non-mnemonic and easily interchangable with the addresses of each of several other friends. No thanks.
I've got a whole pile of expired, underwater stock options.
Hail Eris!
All hail Discordia!
See the lovely fnords.
I read the entire Illuminatis trilogy straight through in about 3 days. I think I was supposed to be doing something else at the time. Never trust anyone with the initials H.C.
I think a 24% crash in SCOs stock price today shows what the market thinks of this news, and exactly how much Linus has to fear.
Although if I were Linus I wouldn't exactly take the market as my best legal opinion in the matter... IANAL and the M(arket) is sure as hell is NAL either.
No question about it. The stock market is not a legal advisor. However, there doesn't seem to be a great deal of confidence that SCO will win this one. What that indicates is that a wider world than Slashdot has judged their claims to be weak.
This functionality is now provided by instant messengers.
Actually, I thought about that point when I wrote my original comment. You are completely right. And it validates my point. Charging for e-mail will drive people to alternative protocols. There are already numerous ways to communicate with people online. If e-mail costs per message, we'll grab onto something else in a big hurry.
Frankly, I could see a merging of e-mail, P2P and IM creating something with some of the capabilities of each. A distributed file sharing service to find addresses, and a P2P IM system to provide e-mail without a server to friends who are currently online. That's just a back-of-the-envelope brainstorm. Build whatever protocol you like on top of TCP, UDP or even raw IP.
<!-- You could even bury messages in comments posted on major web sites and build clients to send and retrieve them. -->
Right now, part of the problem is that ISPs and users are bearing the cost of spam. In the end, any of the costs to the ISPs are passed on to their customers. Making us pay to send, is going to cut down on the usefulness of e-mail to legitimate users. If I have to pay by the message, I'm going to think twice about a quick note to a friend asking if he wants to meet for lunch. I'll pass along fewer cool URLs.
On the flip side, spammers will still send from addresses that can't be collected from. Many spammers are willing to harass people, steal the bandwidth they've paid for, and lie to people about everything from the return address on the e-mail to the fact that the opt-out procedure is actually just a verification that they have a live address. We won't even go into their claims about the efficacy of the products they sell. Is it even a stretch to believe that they will continue to lie to ISPs and defraud them of payments for the e-mail they send?
Micropayments for e-mail would kill it.
What about all of the free software out there? Emacs gets downloaded as source, precompiled binaries for various platforms, and bundled with virtually every free OS out there. How can you aggregate all of the numbers from all of the servers and get a single number for the most downloaded app.
Giving statistics for the number of downloads from a single service is at least possible. But it falls far short of measuring the most downloaded app. Most free software downloads are off of many other sites.
I think a fair number of hackers aren't satisfied until they know how something works, why it works, and that it works well and will continue to. I think this translates into an urge to do a lot of things ourselves. On the darker side, it feeds the "Not Invented Here" syndrome.
We trust what we've made ourselves, and what we've taken apart and reassembled. When a real hacker say he understands something, he truly does understand it. He generally could recreate it given the same materials the original was built with and the same tools. Often, he can make many of the tools too.
I think a lot of people would fail to see the connection between FIRST and "That Segway Guy..." but hey, the segway got lots of coverage in the news so it's got to be good, right?
I've met Dean Kamen. I don't think I've ever seen anyone with so much energy. Honestly, I think that the Segway was a business mistake, but technically, it is quite an achievement. I try not to emphasize the connection because he has done so many other things that have never made the news. Once Segway comes up, people seem to miss everything else.
(im going to hell for this)
Only if your girlfriend reads it.
The Robot Wars phenomenon, begun in San Francisco...
The phenomenom, in the form of robots actually attacking each other, may have started there. But robotic competitions have a longer history. There is an annual competition for high school students called FIRST (For Inspiration and Recognition of Science and Technology) that is well worth the time to get involved with. Adults get to play too. The teams need sponsors and mentors.
For many megs of answers about why software isn't 100% reliable, read Risks Digest.
There is indeed hardware out there with this level of reliability (like an AT&T 5ESS/Lucent 7R/E phone switch) however it is highly expensive and very unflexable.
I don't mean to bash AT&T. In fact, the very infrequency of this sort of problem is a strong argument for their reliability. I had to go back to the pre-Lucent days for this one, folks. However, they do have some occasional bugs in their software. And it makes the news when they do:
Risks Digest, Volume 9: Issue 69, Tuesday 20 February 1990
Over time, the size and complexity of the problems we can solve with computers has increased because of two factors. First, hardware has become faster, more reliable, and tailored to our use. Secondly, the software tools we use have increased the number and scope of things we can abstract away. Thus, we continue to work at the boundary of our capabilities, or not terribly far from it. The demands of scientific curiousity and the marketplace will continue to drive that.
Up to a point, we demand reliability. For all that Windows has a reputation for crashing, Microsoft has improved it over the years. Whether Windows XP is more or less stable than Linux or *BSD can be debated endlessly. But there is no refuting the fact that it is more stable than Windows 95 was.
Beyond a certain point, additional reliability cost more than it is worth. This is true even if we are talking about the most demanding uses. When the cost of additional reliability makes a technology unaffordable, compromises will be made. The point at which extra reliability is too expensive differs from user to user and application to application.
It is not clear that it is possible to write software that is provably bug-free. What is clear is that reducing the number of bugs while holding the development methodology constant will tend to increase the cost. Extreme Programming and other similar disciplines have argued, convincingly, that in the long run, this can reduce costs over the life of a product. But when you are trying to hit a market window, or launch a product before your venture capital runs out, corners often get cut.
I think that the long term trend is for each lower layer of abstraction to become more reliable over time. At the same time, more is added at the leading edge. New development, especially in uncharted territory, has new bugs.
I can't confirm this with statistics, but I suspect that the reliability of software as an aggregate has either varied around a constant, or has improved slightly over time. What I wonder is whether the reliablity measured against the total amount of code has been slowly improving.
What a headline.
select ipAddress from tblLife where objName="Anonymous Coward";
753422 Rows returned.
"Hey, Joe. Check out this guy. He gets around a lot."
There's one problem with IBM countersuing right now. If they do sue SCO into bankruptcy, someone else will end up with the IP rights that SCO is suing over. This whole thing could come up again. Assuming that we are correct and that IBM is extremely likely to win this case, it is in their interest to get it decided in their favor. Then it doesn't matter much what happens to SCO.
I get spam from a lot of places. I read several I18N/L10N mailing lists as well. I can't even read many of the languages I get spammed in. (For the record, I like the Korean spam the best. So far, it appears to have been for kitchen products. It is nicely formatted. I presume it would be readable if I read Korean.) But my point is, spam is coming from places outside their jurisdiction.