Under the GPL they would have to release any changes they make to the kernel back into the public domain.
You are correct that no current open source project is going to make it as CMM level 5. That doesn't mean that everything about open source is incompatible. There is nothing about CMM level 5 that I'm aware of that would prevent releasing the code under an open source license. It is the organization and project that are CMM level 5. The code is a product of that. Accepting code into the project from outside, as you said, wouldn't cut it.
As for having to release any deltas to the Linux kernel. Nope, the GPL doesn't require that. You can modify anything released under the GPL for your own use. Have fun with it. The requirement is that if you modify it, and release the modifications, you have to release the source as well and the modifications are also covered by the GPL.
I already hold a broader patent for breathing in general which obviously encompasses you paltry attempt to hijack my IP.
That better be completely silent. Any sound you make while doing it would violate my patent on Sound Production Via Gaseous Motion Across Biological Components.
Re:gcc 3.x compilers have serious C++ perfs issues
on
GCC 3.3 Released
·
· Score: 1
I would not consider 3-5% a serious impact unless it came completely without other benefits. The bug report you linked to talks about a runtime performance impact of 2-5 times slower, not 3-5%. Nobody is going to accept an impact like that except to fix serious bugs in the generated code.
By putting the safe and tested material on the radio, they are driving people seeking new music to other distribution channels. This is only going to bring on the day that record labels and radio are completely irrelevant to music that much sooner. I stopped listening to mainstream radio a decade ago. Today, I get my music live or off of an alternative station.
There is a place for safe, predictable radio. But it can be filled just as easily with a CD changer. The thing that is driving this right now is that advertisers are willing to pay well to air their ads to a specific market niche all across the country. When those listeners wander away out of boredom, either the programming will change or the company will go bankrupt.
We have one station here that is so predictable that you can announce the next song in advance if you've been listening carefully for a couple of days. At least their play list doesn't repeat every hour. They're on a daily rotation.
I've known some speakers of Quenya and Esperanto who learned those languages just because it interested them, not because they were obsessed
I know lots of Esperantists personally, being one myself. And yes, I learned it just because it struck me as interesting.
I think the truly rare person would be someone who is a fluent (more than shouting catchphrases from the show at the masked ball) speaker of Klingon who is employable...
The biggest differences between Esperanto and Klingon in terms of having translators available are twofold. First, Esperanto was created to be a complete language for intercommunication between speakers of different languages. Thus, there has been considerable effort to provide it with a complete vocabulary. Second, Esperanto has been around long enough that there is a sizeable number of speakers around the world. There are even some native speakers. Klingon could go on to be as popular, or it could end up nearly forgotten like so many other constructed language projects.
My first programs were in FORTRAN, for the moment I'm doing Java, and I'm hoping for Lisp in another 10 years...
Not a bad goal. Lisp has certainly weathered well over the years. It has fallen somewhat out of favor in the past decade. I attribute that to two things. First, it has suffered by association with AI. Second, Lisp is not a language one grasps quickly. The power is contained in idioms and composition of features one with another. That doesn't invite the newbie.
When you can look at Paul Graham's book On Lisp and Andrei Alexandrescu's Modern C++ Design and understand the similarities, you are ready to code in any language.
The more experienced (often but not always older) programmer/analysts are the better listeners who remember that our primary purpose is to build software systems that people can use intuitively to accomplish their work more effectively. They are also the ones that can resist the temptation to build "clever" code remembering from past code maintenance nightmares that just because something is possible doesn't mean it is good idea.
The last time I was looking, I went through the usual exercise of putting into words the reasons I'm doing this. I like delivering working products. Yes, new technologies are cool. Sure, I'll use them. And at the end of the day, I want a real user clicking on the stuff I built. I've found that managers and customers like having me around.
The article we are discussing is about Java, so your point about operator overloading is irrelevent.
Earlier in this thread someone stated that x++ is supposed to be less efficient than ++x. I was detailed the reason why that is true in the case of objects in the presence of operator overloading. I also pointed out why it can be particularly detrimental because it is commonly used for incrementing interators in loops. Presumably, you are looping over a sizeable amount of data at least some of the time. That's the reason I brought up loops.
You are correct that in Java or C, with a decent optimizer, you should get the same instructions. In the absense of a good optimizer, the extra overhead is very small at worst. You would store the value prior to the increment and return that. Your optimizer can spot that the temporary that is generated for that is never used and remove it. The two versions look like this:
++x;
x = x+1;
x++;
tmp = x;
x = x+1;
return tmp;
The whole problem arises when the original value must be returned by the expression in a context where it is too difficult for the optimizer to make that temporary go away.
Part of my point was to illustrate why it makes only a slight difference, if at all, in C and Java because our discussion here is about Java. IMHO, operator overloading is a good thing, but it should not be overused. When the analogy to the behavior of plain old data is a good one, it enhances readability. I've seen operator+=() used for a function that appends an object to a collection. The fact that list += obj; is not equivalent to list = list + obj; is a strong argument against overloading either the + or += operator for a container.
x++ is the standard way of writing the statement, used by most coders in preference to ++x (in my experience anyway.) The fact that there is such a convention is reason enough to use it IMHO; if I see ++x in a piece of code, it's a warning that something unusual is going on.
When used with native data types, x++ is at worst only marginally less efficient than ++x. Unfortunately, when dealing with operator overloading (my experience draws heavily on C++ here) you can run into some efficiency problems. Because you should, assuming that you mimic the behavior of postfix ++ on native types, return the value of the object before the increment, you have to make a copy. You have the overhead of executing the copy-constructor. You may be adding significant overhead that you don't need.
It has also been my experience that the single most common use of ++ and -- is in loops that iterate over something. The variable in question may be an int used as an array index, a pointer into an array or an interator that is actually an object. It is this final case where the overhead really shows. Generating the same code from x++ and ++x when the value of the expression is not used is a fairly common optimization for POD types, I think. I wouldn't expect it to be done for objects as a general rule.
Actually, I do buy the argument because we've been seeing it. I'm using a driver for my NIC that was developed by Intel and nVidia developed the driver for my graphics card. Because of the number of people using Linux, there is a large enough market to make it worthwhile to develop the drivers. Okay, that doesn't add knew core functionality, but it generates a virtuous cycle. New hardware is better supported now than it was a few years ago. That makes adoption of Linux even more attractive for people who don't want to hack the kernel or don't have the time because they are working on other things, like porting apps to Linux. It's the Network Effect. Some products become more useful simply because their user base grows. Communication technologies are the classic example of that.
Every time I read a newspaper on any topic I know something about, I find more errors than facts. I don't expect them to understand technical areas that reporters never learn. But I catch them misquoting sources, misspelling names and getting people's jobs titles wrong when all the correct information is available on a company web site within easy cut-and-paste range. I wouldn't take a newspaper as the final answer on any subject.
The vast majority of software written is not written for the commercial marketplace. It's written for inhouse use.
Or embedded, or targetted at a specific industry. I've got *mumble* years of experience working on plenty of software that was sold to customers. It was written for specific target markets. It was never the sort of stuff that would fit in a shrink-wrapped box on a store shelf.
Anyone writing code that isn't targetted at desktop users (embedded, turnkey, server, etc.) who doesn't at least consider open source platforms is overlooking a possible area of cost savings.
I'm exaggerating a little, but there's an important point here, and I'll illustrate it with a little bit of personal history. In 1985, I was told by a well-meaning acquaintance that I might want to reconsider my chosen career path because 4GLs were going to make programmers obsolete. Programming was going to be easy enough that anyone could do it.
That argument was already recycled at the time, although my would-be mentor probably didn't realize it. Compilers for high-level languages were originally going to put programmers out of a job. COBOL was going to be so much like English that businessmen (not businesspeople, it was the 1950's) would be able to understand it.
The flaw in this whole theory is vital to understanding business, and where the future of programming is likely to go. If you own a business and your product is not computer software or hardware, you do not make your money from writing code. You spend your time learning the skills relevant to your business. You research the market for what you sell, not the latest programming language.
Programs capture knowledge. That is one of their most important functions. As programmers, we have a great deal of specialized knowledge that is common across broad ranges of software. We know a variety of algorithms, strategies for error handling, data formats, network protocols, etc. None of that has anything to do with most businesses, any more than the guy running the sub shop down the street needs to know the electrical code.
Businesses use software the way they use lots of things. It makes no sense for them to learn to wire the building or build their web site. The sub shop owner has business needs. He needs lighting and power for the cash register, and a refridgerator over there. He may need to put up a web site advertising his business. But his interest in programming is at the content level: deliver web pages with particular information, and maybe take orders.
Putting up web sites from a tool that just lets users write some content, and select some options will necessarily limit those users to the options that are available. The full flexibility to innovate requires a tool that acts more like a language. Doing new things is a Turing equivalent problem. Doing existing things, even in new combinations does not have to be. The majority of users will never be programmers in the sense that specialists are. It doesn't matter that huge numbers of kids have learned some programming in school. I took biology in high school. I'm not a biologist.
It's all about division of labor. People who aren't overly technophobic will use tools that programmers provide. Millions of people use word processors, spreadsheets, presentation packages, and even indirectly, databases. Most won't ever write a macro for their word processor or a schema for a database, nor should they. They use the tools that specialists provide to help them do what they do well.
You can protect 99.99999% of the time, but pure freak chance will always get you in the end. But at least those vulnerabilities will be fewer (hopefully?) than microsoft's products.
Yes, and there is another way to look at this too. When your code is written around an architecture that is designed to provide security and protection of one program from another, even if you have as many vulnerabilities, most of them can be fixed without changes to the design.
I don't think that Microsoft's buffer overflows are any easier or harder for them to fix than buffer overflows in any open source project. Allowing code to be executed from incoming e-mail on the other hand is more fundamental to the design. If it were limited to something like Java's security sandbox, at least any holes that were found could be plugged. Sharing macros in documents wasn't horribly unsafe when the only place you were getting them from was a coworker down the hall. But now, protecting from dangerous actions those macros can execute is difficult.
And when someone finds a security hole in a commonly used version of Mozilla or Evolution, that could hit a significant percent of desktop Linux users. If we make the assumption that the number of such users is going to grow, I think it is safe to assume that they are not as likely to use something that doesn't look like a Windows e-mail client. They want to make the transition as simply as possible.
There will be Linux viruses. We will get hit. Currently, the smaller installed base and the diversity of distributions, client software, kernel versions, etc. is making Linux harder to target. If 90% of desktop users were using Linux, and 80-90% of those all used the same e-mail client, browser, and word processor, Linux would provide a rich target environment. More virus writers would target it.
If you do enjoy what you're doing, then you'll be more likely to consider the time invested in a degree, and your current career, worthwhile, even if you're not making huge money.
And you'll be more likely to learn things that expand your skills and keep them up-to-date because you enjoy learning it.
Maybe games and entertainment will continue to need programmers, but in general, without moving formats like Word and Excel, there is no need to purchase more applications.
Long after word processors and spreadsheets were essentially feature-complete, we still found needs for new software other than games. The general trend I see is that new hardware innovations make new tools/toys possible and drive development of new categories of applications.
Reduction in size and power consumption of processors along with the ability to substitute RAM for disks made PDAs possible. There was a need for applications tailored to fast access to data on a small screen.
Similarly, cheaper, smaller RAM helped make digital photography affordable. Now we all want software to download, manipulate and catalog all thos pictures.
Faster processors, bigger disks and cheap CD/RWs made video editing on a PC is serious possibility. Gotta have software for that.
Figure out what hardware is going to develop fastest over the next few years and get ahead of the curve on writing apps to run on it or use the data it produces.
The real value in this is that it helps to keep the commons populated. The commercial value of computing texts after 28 years is effectively nothing. But this makes tracking down older reference materials easier if someone is willing to make them available online. Sure, most technical books are long-forgotten after nearly three decades, but the first edition of Kernighan and Ritchie's The C Programming Language is 25 years old, and Knuth's The Art of Computer Programming goes back several years farther than that. I don't begrudge either the authors or the publishers of those books a penny. But they are still in print in later editions. Releasing other books into the public domain at a time when they aren't profittable to keep in print helps to ensure that they don't disappear entirely from neglect.
There is little chance that they can win this. IANAL, so I can't speak to the question of whether their claims have a chance in court. I could argue the point of whether they make sense, but I don't want to get involved in that.
However, IBM has the resources and the motivation to fight this. SCO's market cap is a whole lot less than IBM's investment in, and presumably revenue from, open source software. From a business perspective, it would make sense for IBM to buy SCO and release the patents to the open source community. If winning this fight would cost them more, they can do that. If winning it costs less, they can fight it and effectively disarm SCO.
I think within a short time what we are going to see is that open source software will effectively become very safe from lawsuits. The day is coming when it will be a safe bet to use open source because you will know that it has already survived these attacks.
Does anyone have a URL that can be published prominently on Slashdot so that we can all visit their site and view their pretty ads? I mean, there are so many of us who want to know how well this technology will work.
Slashdot Mirror
Okay, the earliest sightings of smileys were found. How long will it take us to agree on when the earliest reference to Imminent Death of the Net Predicted was? I found one dating to April 11, 1991. Does anyone know of an earlier one?
Under the GPL they would have to release any changes they make to the kernel back into the public domain.
You are correct that no current open source project is going to make it as CMM level 5. That doesn't mean that everything about open source is incompatible. There is nothing about CMM level 5 that I'm aware of that would prevent releasing the code under an open source license. It is the organization and project that are CMM level 5. The code is a product of that. Accepting code into the project from outside, as you said, wouldn't cut it.
As for having to release any deltas to the Linux kernel. Nope, the GPL doesn't require that. You can modify anything released under the GPL for your own use. Have fun with it. The requirement is that if you modify it, and release the modifications, you have to release the source as well and the modifications are also covered by the GPL.
I already hold a broader patent for breathing in general which obviously encompasses you paltry attempt to hijack my IP.
That better be completely silent. Any sound you make while doing it would violate my patent on Sound Production Via Gaseous Motion Across Biological Components.
I would not consider 3-5% a serious impact unless it came completely without other benefits. The bug report you linked to talks about a runtime performance impact of 2-5 times slower, not 3-5%. Nobody is going to accept an impact like that except to fix serious bugs in the generated code.
By putting the safe and tested material on the radio, they are driving people seeking new music to other distribution channels. This is only going to bring on the day that record labels and radio are completely irrelevant to music that much sooner. I stopped listening to mainstream radio a decade ago. Today, I get my music live or off of an alternative station.
There is a place for safe, predictable radio. But it can be filled just as easily with a CD changer. The thing that is driving this right now is that advertisers are willing to pay well to air their ads to a specific market niche all across the country. When those listeners wander away out of boredom, either the programming will change or the company will go bankrupt.
16% Katz bash.
Well, if this is true it explains the decline in quality in recent years. I haven't seen Katz bashed in ages.
We have one station here that is so predictable that you can announce the next song in advance if you've been listening carefully for a couple of days. At least their play list doesn't repeat every hour. They're on a daily rotation.
I've known some speakers of Quenya and Esperanto who learned those languages just because it interested them, not because they were obsessed
I know lots of Esperantists personally, being one myself. And yes, I learned it just because it struck me as interesting.
I think the truly rare person would be someone who is a fluent (more than shouting catchphrases from the show at the masked ball) speaker of Klingon who is employable...
The biggest differences between Esperanto and Klingon in terms of having translators available are twofold. First, Esperanto was created to be a complete language for intercommunication between speakers of different languages. Thus, there has been considerable effort to provide it with a complete vocabulary. Second, Esperanto has been around long enough that there is a sizeable number of speakers around the world. There are even some native speakers. Klingon could go on to be as popular, or it could end up nearly forgotten like so many other constructed language projects.
It's hard to read a book on a language when you don't have time to code in it.
I agree. Programming is not abstract knowledge. It requires practice or the techniques just don't stick.
My first programs were in FORTRAN, for the moment I'm doing Java, and I'm hoping for Lisp in another 10 years...
Not a bad goal. Lisp has certainly weathered well over the years. It has fallen somewhat out of favor in the past decade. I attribute that to two things. First, it has suffered by association with AI. Second, Lisp is not a language one grasps quickly. The power is contained in idioms and composition of features one with another. That doesn't invite the newbie.
When you can look at Paul Graham's book On Lisp and Andrei Alexandrescu's Modern C++ Design and understand the similarities, you are ready to code in any language.
The more experienced (often but not always older) programmer/analysts are the better listeners who remember that our primary purpose is to build software systems that people can use intuitively to accomplish their work more effectively. They are also the ones that can resist the temptation to build "clever" code remembering from past code maintenance nightmares that just because something is possible doesn't mean it is good idea.
The last time I was looking, I went through the usual exercise of putting into words the reasons I'm doing this. I like delivering working products. Yes, new technologies are cool. Sure, I'll use them. And at the end of the day, I want a real user clicking on the stuff I built. I've found that managers and customers like having me around.
The article we are discussing is about Java, so your point about operator overloading is irrelevent.
Earlier in this thread someone stated that x++ is supposed to be less efficient than ++x. I was detailed the reason why that is true in the case of objects in the presence of operator overloading. I also pointed out why it can be particularly detrimental because it is commonly used for incrementing interators in loops. Presumably, you are looping over a sizeable amount of data at least some of the time. That's the reason I brought up loops.
You are correct that in Java or C, with a decent optimizer, you should get the same instructions. In the absense of a good optimizer, the extra overhead is very small at worst. You would store the value prior to the increment and return that. Your optimizer can spot that the temporary that is generated for that is never used and remove it. The two versions look like this:
++x;
x = x+1;
x++;
tmp = x;
x = x+1;
return tmp;
The whole problem arises when the original value must be returned by the expression in a context where it is too difficult for the optimizer to make that temporary go away.
Part of my point was to illustrate why it makes only a slight difference, if at all, in C and Java because our discussion here is about Java. IMHO, operator overloading is a good thing, but it should not be overused. When the analogy to the behavior of plain old data is a good one, it enhances readability. I've seen operator+=() used for a function that appends an object to a collection. The fact that list += obj; is not equivalent to list = list + obj; is a strong argument against overloading either the + or += operator for a container.
My code was hard to write to it should be hard to read. :)
"Real Programmers don't need comments-- the code is obvious."
-- Real Programmers Don't Use Pascal
x++ is the standard way of writing the statement, used by most coders in preference to ++x (in my experience anyway.) The fact that there is such a convention is reason enough to use it IMHO; if I see ++x in a piece of code, it's a warning that something unusual is going on.
When used with native data types, x++ is at worst only marginally less efficient than ++x. Unfortunately, when dealing with operator overloading (my experience draws heavily on C++ here) you can run into some efficiency problems. Because you should, assuming that you mimic the behavior of postfix ++ on native types, return the value of the object before the increment, you have to make a copy. You have the overhead of executing the copy-constructor. You may be adding significant overhead that you don't need.
It has also been my experience that the single most common use of ++ and -- is in loops that iterate over something. The variable in question may be an int used as an array index, a pointer into an array or an interator that is actually an object. It is this final case where the overhead really shows. Generating the same code from x++ and ++x when the value of the expression is not used is a fairly common optimization for POD types, I think. I wouldn't expect it to be done for objects as a general rule.
Actually, I do buy the argument because we've been seeing it. I'm using a driver for my NIC that was developed by Intel and nVidia developed the driver for my graphics card. Because of the number of people using Linux, there is a large enough market to make it worthwhile to develop the drivers. Okay, that doesn't add knew core functionality, but it generates a virtuous cycle. New hardware is better supported now than it was a few years ago. That makes adoption of Linux even more attractive for people who don't want to hack the kernel or don't have the time because they are working on other things, like porting apps to Linux. It's the Network Effect. Some products become more useful simply because their user base grows. Communication technologies are the classic example of that.
go read a newspaper and you'll see that I'm right
Every time I read a newspaper on any topic I know something about, I find more errors than facts. I don't expect them to understand technical areas that reporters never learn. But I catch them misquoting sources, misspelling names and getting people's jobs titles wrong when all the correct information is available on a company web site within easy cut-and-paste range. I wouldn't take a newspaper as the final answer on any subject.
The vast majority of software written is not written for the commercial marketplace. It's written for inhouse use.
Or embedded, or targetted at a specific industry. I've got *mumble* years of experience working on plenty of software that was sold to customers. It was written for specific target markets. It was never the sort of stuff that would fit in a shrink-wrapped box on a store shelf.
Anyone writing code that isn't targetted at desktop users (embedded, turnkey, server, etc.) who doesn't at least consider open source platforms is overlooking a possible area of cost savings.
I'm exaggerating a little, but there's an important point here, and I'll illustrate it with a little bit of personal history. In 1985, I was told by a well-meaning acquaintance that I might want to reconsider my chosen career path because 4GLs were going to make programmers obsolete. Programming was going to be easy enough that anyone could do it.
That argument was already recycled at the time, although my would-be mentor probably didn't realize it. Compilers for high-level languages were originally going to put programmers out of a job. COBOL was going to be so much like English that businessmen (not businesspeople, it was the 1950's) would be able to understand it.
The flaw in this whole theory is vital to understanding business, and where the future of programming is likely to go. If you own a business and your product is not computer software or hardware, you do not make your money from writing code. You spend your time learning the skills relevant to your business. You research the market for what you sell, not the latest programming language.
Programs capture knowledge. That is one of their most important functions. As programmers, we have a great deal of specialized knowledge that is common across broad ranges of software. We know a variety of algorithms, strategies for error handling, data formats, network protocols, etc. None of that has anything to do with most businesses, any more than the guy running the sub shop down the street needs to know the electrical code.
Businesses use software the way they use lots of things. It makes no sense for them to learn to wire the building or build their web site. The sub shop owner has business needs. He needs lighting and power for the cash register, and a refridgerator over there. He may need to put up a web site advertising his business. But his interest in programming is at the content level: deliver web pages with particular information, and maybe take orders.
Putting up web sites from a tool that just lets users write some content, and select some options will necessarily limit those users to the options that are available. The full flexibility to innovate requires a tool that acts more like a language. Doing new things is a Turing equivalent problem. Doing existing things, even in new combinations does not have to be. The majority of users will never be programmers in the sense that specialists are. It doesn't matter that huge numbers of kids have learned some programming in school. I took biology in high school. I'm not a biologist.
It's all about division of labor. People who aren't overly technophobic will use tools that programmers provide. Millions of people use word processors, spreadsheets, presentation packages, and even indirectly, databases. Most won't ever write a macro for their word processor or a schema for a database, nor should they. They use the tools that specialists provide to help them do what they do well.
You can protect 99.99999% of the time, but pure freak chance will always get you in the end. But at least those vulnerabilities will be fewer (hopefully?) than microsoft's products.
Yes, and there is another way to look at this too. When your code is written around an architecture that is designed to provide security and protection of one program from another, even if you have as many vulnerabilities, most of them can be fixed without changes to the design.
I don't think that Microsoft's buffer overflows are any easier or harder for them to fix than buffer overflows in any open source project. Allowing code to be executed from incoming e-mail on the other hand is more fundamental to the design. If it were limited to something like Java's security sandbox, at least any holes that were found could be plugged. Sharing macros in documents wasn't horribly unsafe when the only place you were getting them from was a coworker down the hall. But now, protecting from dangerous actions those macros can execute is difficult.
you are right... it needs Microsoft Outlook.
And when someone finds a security hole in a commonly used version of Mozilla or Evolution, that could hit a significant percent of desktop Linux users. If we make the assumption that the number of such users is going to grow, I think it is safe to assume that they are not as likely to use something that doesn't look like a Windows e-mail client. They want to make the transition as simply as possible.
There will be Linux viruses. We will get hit. Currently, the smaller installed base and the diversity of distributions, client software, kernel versions, etc. is making Linux harder to target. If 90% of desktop users were using Linux, and 80-90% of those all used the same e-mail client, browser, and word processor, Linux would provide a rich target environment. More virus writers would target it.
If you do enjoy what you're doing, then you'll be more likely to consider the time invested in a degree, and your current career, worthwhile, even if you're not making huge money.
And you'll be more likely to learn things that expand your skills and keep them up-to-date because you enjoy learning it.
Long after word processors and spreadsheets were essentially feature-complete, we still found needs for new software other than games. The general trend I see is that new hardware innovations make new tools/toys possible and drive development of new categories of applications.
Figure out what hardware is going to develop fastest over the next few years and get ahead of the curve on writing apps to run on it or use the data it produces.
The real value in this is that it helps to keep the commons populated. The commercial value of computing texts after 28 years is effectively nothing. But this makes tracking down older reference materials easier if someone is willing to make them available online. Sure, most technical books are long-forgotten after nearly three decades, but the first edition of Kernighan and Ritchie's The C Programming Language is 25 years old, and Knuth's The Art of Computer Programming goes back several years farther than that. I don't begrudge either the authors or the publishers of those books a penny. But they are still in print in later editions. Releasing other books into the public domain at a time when they aren't profittable to keep in print helps to ensure that they don't disappear entirely from neglect.
There is little chance that they can win this. IANAL, so I can't speak to the question of whether their claims have a chance in court. I could argue the point of whether they make sense, but I don't want to get involved in that.
However, IBM has the resources and the motivation to fight this. SCO's market cap is a whole lot less than IBM's investment in, and presumably revenue from, open source software. From a business perspective, it would make sense for IBM to buy SCO and release the patents to the open source community. If winning this fight would cost them more, they can do that. If winning it costs less, they can fight it and effectively disarm SCO.
I think within a short time what we are going to see is that open source software will effectively become very safe from lawsuits. The day is coming when it will be a safe bet to use open source because you will know that it has already survived these attacks.
Does anyone have a URL that can be published prominently on Slashdot so that we can all visit their site and view their pretty ads? I mean, there are so many of us who want to know how well this technology will work.