Many of the features meant for Cairo were not feasible for a desktop OS before. Longhorn will be the first OS with all of the features that were meant to be in Cairo.
As far as I can tell, you described exactly what MS is doing with WinFS. WinFS does not cast aside the directory structure underneath, just supplements it with metadata that can provide an alternate view of the data.
The Register is putting words in Microsoft's mouth. The article makes it sound as though Microsoft failed to make WinFS all they wanted it to be, when the fact is that everybody misunderstood MS's plans for WinFS.
NTFS is based on attributes. The filename is an attribute of the file. The ACLs are an attribute of the file. The file data is also an attribute. Some attributes are special and are used by the file system itself, but otherwise a file is just a collection of attributes. So NTFS has always been able to act as a database in the way you mention -- the attributes in Win2K are simply stored as NTFS attributes.
The only thing missing has been indexing. NTFS is not designed to index everything the way a database does. And it doesn't have a query engine. This is what WinFS will add.
What's wrong with NTFS? I think it is a pretty darn good and clean file system, and I haven't heard of any good reasons for Microsoft to drop it. It isn't aging in any way that I know of.
NTFS doesn't have all of the nifty features of WinFS, but lack of features doesn't mean it needs to be replaced.
You have to create a new partition. Existing partitions are set to a particular format. If the existing partition is NTFS, you have to delete it and create a new partition if you want FAT32. If the existing partition is FAT16, you won't be able to format more than 2 GB.
I would be willing to be that this is because the PARTITION was created as FAT16. If you delete the partition and recreate it as a FAT32 partition, you can then format it up to 32 GB.
I probably ought to qualify this by saying that this is my current understanding of WinFS, and the way it works in the leaked editions of Longhorn. Things may change between now and release.
I think you miss the point of WinFS. It is actually a layer abover NTFS, so the actual files will still be stored the same way they are presently (and NTFS is pretty good about reliability). NTFS is already a lot like ReiserFS even without WinFS.
What WinFS adds is more powerful indexing, not a new storage system. Whenever you add or modify a file, WinFS adds the file's attributes to its indexes. The attributes stored are customizable, and vary depending on file type (MP3s have their ID3 info indexed, etc.). For example: somerwhere on my 120 GB disk I have a file named "code.txt" but it will take 10 minutes to find it by scanning the directory structure. Instead, I do a "SELECT Path FROM Files WHERE Filename='code.txt'" and WinFS comes up with the answer right away. If I have full text indexing, I could search for a specific phrase. Even more useful, you don't have to make playlists anymore. Just put all of your MP3s in the same directory, and when you want to hear all of your Bon Jovi, just perform the appropriate query. (Obviously you don't have to know SQL to make this useful.)
Some of this is already present in a more limited form in Unix. For example, I still can't figure out why Windows doesn't have something like the LOCATE database that is set up by default on my FreeBSD box. But WinFS will blow LOCATE away (update is real time, not daily, and it has much more than just the file name).
However, from what I've heard, so far it is a bit of a dog performance-wise. I hope it gets up to speed by ship time... At least it can be turned off if you can't take the perf hit.
Actually, I think the real kicker is the inverse of the problem you describe. It may very well be possible to prove that your C program properly conforms to the Z model. But is your Z model correct?
For many real-world problems, figuring out *exactly* what you want your program to do in all situations (and figuring out what all the situations are in the first place) is the hard part. You can then go implement that in C almost as easily as you can in Z.
I'm not saying this (Z and B) is useless. I just want to focus on the real problem. Using a modeling language just introduces one additional layer of abstraction into the process. While this may make the system easier to discuss and easier to "prove correct", it also introduces another layer at which errors may creep into the system. For some cases, the extra layer introduces fewer errors than it prevents. For other cases, the opposite is true.
I think to some extent it comes down to "how much time are we going to spend making sure this software is darn near perfect." The law of diminishing returns says that the number of flaws fixed per unit of programmer time will go down as more programmer time is applied, providing a "cost to flaw" curve. Customers also have a curve of how much they are willing to pay for additional reliability. The curves meet at some price point/quality level (keeping features constant), and that is where the product will ship. If the customer's need for extra reliability is large enough that the modeling phase can be integrated properly into the product schedule, it becomes worthwhile to spend time with formal models; otherwise, these will only decrease reliability since the modeling phase eats into the time needed for other phases to properly implement the product.
In other words, I think that a formal modeling phase is overkill for most requirements ("doesn't crash too often") since it has less bang for the buck as far as generating features and fixing glaring bugs. But it continues to have at least some bang for the buck long after other processes drop off in effectiveness. So it is worthwhile to add formal modeling when unit testing isn't going to get you to your desired flaw rate.
I think letting "I hate Microsoft" or "I hate open source" sway your decision is unprofessional (besides -- do people really hate open source? I don't even think Bill Gates *hates* open source, he just wants to keep his market share). Rant and rave one way or the other on Slashdot all you want, but make your business decisions based on facts. There are plenty of pros and cons on both sides.
Variety can definitely erode productivity. At work, I have to keep up on the Win32 API, the Windows CE API, C++ (with ATL, MFC, and STL), C#, Perl, 2 variants of SQL, makefiles, with some VBScript and JavaScript thrown in for good measure. At home, I try to keep up with the FreeBSD API, 2 more variants of SQL, PHP, Java, a different structure for makefiles, etc. And the alphabet soup doesn't seem to be getting any better.
Open source seems to have a tendency to have several projects around a given problem (MySQL, PostgreSQL, FireBird, SAP databases), while businesses tend to lead to bigger, more fully featured (also called bloated -- depends on your point of view) products (SQL Server, Oracle, DB2). Performance varies by application -- for jobs that don't need the extra features, sometimes the simpler products are better. And sometimes, open source results in a real beast (Mozilla). Java is somewhere in between I guess. But since the question was more about Java vs..Net than open source in general, I'll get to the point.
I haven't used Java much for web apps, but I have done some general development in Java. I have done some web development with.Net (C# in particular), and a lot of general development. From this limited perspective, here are my observations:
The performance benchmark you linked to was pretty meaningless. It seems to have been funded by Microsoft, so that just might have biased the methodology a bit. Nevertheless, I think there are some general gut feelings that I think are reasonably accurate regarding the performance of Java and.Net. Both have roughly similar execution speeds (both have decent JIT engines under the hood). Most performance differences in benchmarks will probably be found to be due to the quality of the benchmark code or the quality of the libraries (such as database drivers) being used. I know that Microsoft has gone to great lengths to optimize their database drivers, and a while ago some benchmarks were posted that showed some significant advantages to their drivers. Perhaps Java has caught up since then -- I don't know.
As far as IDEs go, I'm not sure why "choice" in this matter is really an advantage..Net only has one decent IDE, and some people don't like it, but it gets the job done well. There are side utilities that fill in any gaps left. I don't have as much experience with Java IDEs, but I'm sure they are also decent, but that there is no one single IDE that makes everybody happy. Since most workshops have to pick one IDE for the team to agree on, somebody is going to be unhappy no matter what, just like some people might be unhappy with the Visual Studio IDE.
As far as language goes, I guess it is nice that.Net supports multiple languages, but I suspect that most workshops will only make heavy use of one or maybe two. It just gets too complicated otherwise. The nice thing is that no matter what language you pick, you can access the same support libraries. But the more important question is which language is better for your purpose -- Java or [whichever language you decide to use].
I personally like C# over Java. Things like ref and out parameters, boxing, and attributes are things that are quite simply missing from Java. They are needed, and they aren't there. Obviously Microsoft took a lot of good ideas from Java, but since they got to start over with it, they got to improve on the parts of Java that drove Java programmers nutty.
On the other hand,.Net hasn't been around as long. And whi
As far as I know (and I have some good sources), the grandparent post is correct: NT4 likely had some BSD code in the TCP/IP stack (since the reference implementation came from Berkely), and they completely rewrote the stack for 2000.
Where did you get the information to the contrary?
I like your idea of tying macros to objects (classes, actually). But they could be more than just inline methods.
Macros might be able to do more than just expand to a method. They could expand to a language construct such as an inner class, a for loop, a return statement, etc.
Obviously, this leads to more complexity for syntax highlighting and compilers. And it leads to constructs that could drive the programmer nutty (ok, who defined "==" as "!="?). Which is why the Java guys don't want them in the language. "Shoot, I can't do that with that set of macros loaded, I need my own personal custom set of macros for this project..."
The current record for TPC-C for non-clustered systems is a Windows Server 2003 (64 bit edition) on a 64 processor IA64 system from HP running SQL Server 2000 64 bit edition. It runs 707k TPM in official benchmarks.
The Intel system mentioned was a 32 processor IA64 system running Oracle. It got a score of "near 600k" in Intel's internal benchmarks.
Intel is keeping quiet about the details, and hasn't yet submitted a system for "official" testing. But it sounds like their kernel tweaks and their optimizing compiler have made a huge difference, and Oracle on Linux is a serious contender.
Very true. There is always the possibility that the commercial vendor is also selling something that is not properly licensed.
But in reality, having the lawyers actually makes a difference in this case. All major software companies pay lawyers to check and make sure that everything is legit. If the lawyers miss something (or if the software company gets caught trying to pull a fast one), a commercial software vendor will be the first target for litigation, and will provide at least some kind of shield for the customer. The software vendor is likely to have a legal team to mount a defense, and is also likely to at least try to negotiate some kind of deal with the plaintiff. With open source, there is no company to attract the first pot-shots, so the users are the primary targets.
For many, this risk is well worth taking, which is why open source projects continue to be used. But it is definitely a real consideration that needs to be examined before you bet the company on an open source project.
I sincerely hope that all of this blows over. I'm very suspect of SCO's claims, especially since they won't let the evidence out, which means that they're going to charge royalties for everyone using their code without telling us exactly what we need to remove their code from Linux. Withholding the evidence is making everyone mad, and preventing us from "coming clean" by removing "their" code or even by licensing "their" Linux if we feel so inclined.
However, let's assume that there are right -- they own Unix, and there are segments of code, up to 80 lines in length, that match between Linux and Unix. What does that show? Still nothing in itself. The code could also be in BSD, in which case it would be free and clear from any SCO claims (although if it lacks the appropriate copyright label, the Berkeley regents might have to send their agents over to rough Linus up a bit (grin)). Or something like that. The code might well be public domain stuff (from an academic paper, from some code library, etc.), so nothing to see.
But assume SCO does own the code. We just rewrite those sections and call it good, right? Wrong. The sections are evidence of contamination, and it will be difficult to determine exactly how far the contamination goes. If someone could copy and paste SCO code, he/she was also probably doing other things -- opening the Unix code in one window, and writing a similar Linux routine in another window, referring back to the Unix code for a "how-to". This is also illegal, as such things need to be done via clean room reverse engineering procedures.
SCO will then argue that the contamination is very deep. IBM and the Open Source people in general will argue that the contamination is insignificant. It might be hard to tell in some cases. SCO will argue that the design patterns in use in Linux were stolen from Unix, and that those design patterns are crucial IP. Everything built around that design will have to be rewritten, probably with a different design to prove that we aren't continuing to steal their precious design. And then everything that depends on that design will also have to be rewritten. Etc. Depending on how deep the problem goes (according to what the courts decide), it may or may not be feasible to rewrite the affected portions and send out patches. The problem is that lawyers may have to get involved, certifying that the portions rewritten comply with all necessary laws and no longer intrude on SCO's IP. It may be necessary to abandon portions of Linux entirely, perhaps importing replacement code from BSD or the like.
In the meantime, all of the big fish who have been using Linux will be sued for royalties. I'm sure that many suits will be dismissed, but some will be upheld.
Whether or not SCO wins, this will be a wakeup call. Before accepting GNU tools for use in the business, managers are now going to be asking, "how can we be certain that this code is legit?" It is a very valid question. All source has pedigree -- are there any portions of this code that might be discovered to belong to someone else? If so, what protects us from having that code yanked out from under us? Somebody could sue us for damages, refuse to license the code to us, and shut down our entire operation.
If SCO wins, beyond the damage to Linux itself, a lot of people are going to get very nervous about using open source products in general in the business world. Even if they lose, things are still going to get a bit more tense, as you may have to prove the code's purebred pedigree before you can use it to run your IT department.
Wrong. Branching is done properly with each release, at least on all of the products that I have worked with. But some patches have side effects. For example, if some SQL function can be used to do something bad to the database but can be run by an unprivileged user, the fix might be to change the privileges on that function. But what if one of your applications depended on that function being available at the former privilege level? Also, the patches happen at the file level, which means that if file XXX.dll has had 15 patches since release, if you want patch #15, you also get patches #1-14. It is hard to avoid all situations like these, so regression testing is a necessary part of patching "high availability" systems on any platform, not just Windows.
Updating hourly doesn't help if they still blindly open attachments. Changing to a "safer" email client doesn't help either, unless it is a VB Script virus (this one isn't).
So how does running Mozilla prevent you from getting this virus? Does Mozilla prohibit attachments or something? Any email program that supports attachments is vulnerable to email viruses. It's that "user hole" that you can't get rid of, no matter what email client you use.
Slashdot Mirror
For all intents and purposes, Longhorn == Cairo.
:)
Many of the features meant for Cairo were not feasible for a desktop OS before. Longhorn will be the first OS with all of the features that were meant to be in Cairo.
Just 10 years late, that's all
As far as I can tell, you described exactly what MS is doing with WinFS. WinFS does not cast aside the directory structure underneath, just supplements it with metadata that can provide an alternate view of the data.
The Register is putting words in Microsoft's mouth. The article makes it sound as though Microsoft failed to make WinFS all they wanted it to be, when the fact is that everybody misunderstood MS's plans for WinFS.
You can get rid of driver letters (mostly) in Win2k and later. WinFS has nothing to do with this.
NTFS is based on attributes. The filename is an attribute of the file. The ACLs are an attribute of the file. The file data is also an attribute. Some attributes are special and are used by the file system itself, but otherwise a file is just a collection of attributes. So NTFS has always been able to act as a database in the way you mention -- the attributes in Win2K are simply stored as NTFS attributes.
The only thing missing has been indexing. NTFS is not designed to index everything the way a database does. And it doesn't have a query engine. This is what WinFS will add.
What's wrong with NTFS? I think it is a pretty darn good and clean file system, and I haven't heard of any good reasons for Microsoft to drop it. It isn't aging in any way that I know of.
NTFS doesn't have all of the nifty features of WinFS, but lack of features doesn't mean it needs to be replaced.
Yes. Though jpegs don't have standard attributes for artist and type, so you might have to add those attributes manually.
You have to create a new partition. Existing partitions are set to a particular format. If the existing partition is NTFS, you have to delete it and create a new partition if you want FAT32. If the existing partition is FAT16, you won't be able to format more than 2 GB.
I would be willing to be that this is because the PARTITION was created as FAT16. If you delete the partition and recreate it as a FAT32 partition, you can then format it up to 32 GB.
I probably ought to qualify this by saying that this is my current understanding of WinFS, and the way it works in the leaked editions of Longhorn. Things may change between now and release.
I think you miss the point of WinFS. It is actually a layer abover NTFS, so the actual files will still be stored the same way they are presently (and NTFS is pretty good about reliability). NTFS is already a lot like ReiserFS even without WinFS.
What WinFS adds is more powerful indexing, not a new storage system. Whenever you add or modify a file, WinFS adds the file's attributes to its indexes. The attributes stored are customizable, and vary depending on file type (MP3s have their ID3 info indexed, etc.). For example: somerwhere on my 120 GB disk I have a file named "code.txt" but it will take 10 minutes to find it by scanning the directory structure. Instead, I do a "SELECT Path FROM Files WHERE Filename='code.txt'" and WinFS comes up with the answer right away. If I have full text indexing, I could search for a specific phrase. Even more useful, you don't have to make playlists anymore. Just put all of your MP3s in the same directory, and when you want to hear all of your Bon Jovi, just perform the appropriate query. (Obviously you don't have to know SQL to make this useful.)
Some of this is already present in a more limited form in Unix. For example, I still can't figure out why Windows doesn't have something like the LOCATE database that is set up by default on my FreeBSD box. But WinFS will blow LOCATE away (update is real time, not daily, and it has much more than just the file name).
However, from what I've heard, so far it is a bit of a dog performance-wise. I hope it gets up to speed by ship time... At least it can be turned off if you can't take the perf hit.
Actually, I think the real kicker is the inverse of the problem you describe. It may very well be possible to prove that your C program properly conforms to the Z model. But is your Z model correct?
For many real-world problems, figuring out *exactly* what you want your program to do in all situations (and figuring out what all the situations are in the first place) is the hard part. You can then go implement that in C almost as easily as you can in Z.
I'm not saying this (Z and B) is useless. I just want to focus on the real problem. Using a modeling language just introduces one additional layer of abstraction into the process. While this may make the system easier to discuss and easier to "prove correct", it also introduces another layer at which errors may creep into the system. For some cases, the extra layer introduces fewer errors than it prevents. For other cases, the opposite is true.
I think to some extent it comes down to "how much time are we going to spend making sure this software is darn near perfect." The law of diminishing returns says that the number of flaws fixed per unit of programmer time will go down as more programmer time is applied, providing a "cost to flaw" curve. Customers also have a curve of how much they are willing to pay for additional reliability. The curves meet at some price point/quality level (keeping features constant), and that is where the product will ship. If the customer's need for extra reliability is large enough that the modeling phase can be integrated properly into the product schedule, it becomes worthwhile to spend time with formal models; otherwise, these will only decrease reliability since the modeling phase eats into the time needed for other phases to properly implement the product.
In other words, I think that a formal modeling phase is overkill for most requirements ("doesn't crash too often") since it has less bang for the buck as far as generating features and fixing glaring bugs. But it continues to have at least some bang for the buck long after other processes drop off in effectiveness. So it is worthwhile to add formal modeling when unit testing isn't going to get you to your desired flaw rate.
Well, then. Those are facts and reasons, aren't they? Those are more professional reasons.
I think letting "I hate Microsoft" or "I hate open source" sway your decision is unprofessional (besides -- do people really hate open source? I don't even think Bill Gates *hates* open source, he just wants to keep his market share). Rant and rave one way or the other on Slashdot all you want, but make your business decisions based on facts. There are plenty of pros and cons on both sides.
.Net than open source in general, I'll get to the point.
.Net (C# in particular), and a lot of general development. From this limited perspective, here are my observations:
.Net. Both have roughly similar execution speeds (both have decent JIT engines under the hood). Most performance differences in benchmarks will probably be found to be due to the quality of the benchmark code or the quality of the libraries (such as database drivers) being used. I know that Microsoft has gone to great lengths to optimize their database drivers, and a while ago some benchmarks were posted that showed some significant advantages to their drivers. Perhaps Java has caught up since then -- I don't know.
.Net only has one decent IDE, and some people don't like it, but it gets the job done well. There are side utilities that fill in any gaps left. I don't have as much experience with Java IDEs, but I'm sure they are also decent, but that there is no one single IDE that makes everybody happy. Since most workshops have to pick one IDE for the team to agree on, somebody is going to be unhappy no matter what, just like some people might be unhappy with the Visual Studio IDE.
.Net supports multiple languages, but I suspect that most workshops will only make heavy use of one or maybe two. It just gets too complicated otherwise. The nice thing is that no matter what language you pick, you can access the same support libraries. But the more important question is which language is better for your purpose -- Java or [whichever language you decide to use].
.Net hasn't been around as long. And whi
Variety can definitely erode productivity. At work, I have to keep up on the Win32 API, the Windows CE API, C++ (with ATL, MFC, and STL), C#, Perl, 2 variants of SQL, makefiles, with some VBScript and JavaScript thrown in for good measure. At home, I try to keep up with the FreeBSD API, 2 more variants of SQL, PHP, Java, a different structure for makefiles, etc. And the alphabet soup doesn't seem to be getting any better.
Open source seems to have a tendency to have several projects around a given problem (MySQL, PostgreSQL, FireBird, SAP databases), while businesses tend to lead to bigger, more fully featured (also called bloated -- depends on your point of view) products (SQL Server, Oracle, DB2). Performance varies by application -- for jobs that don't need the extra features, sometimes the simpler products are better. And sometimes, open source results in a real beast (Mozilla). Java is somewhere in between I guess. But since the question was more about Java vs.
I haven't used Java much for web apps, but I have done some general development in Java. I have done some web development with
The performance benchmark you linked to was pretty meaningless. It seems to have been funded by Microsoft, so that just might have biased the methodology a bit. Nevertheless, I think there are some general gut feelings that I think are reasonably accurate regarding the performance of Java and
As far as IDEs go, I'm not sure why "choice" in this matter is really an advantage.
As far as language goes, I guess it is nice that
I personally like C# over Java. Things like ref and out parameters, boxing, and attributes are things that are quite simply missing from Java. They are needed, and they aren't there. Obviously Microsoft took a lot of good ideas from Java, but since they got to start over with it, they got to improve on the parts of Java that drove Java programmers nutty.
On the other hand,
As far as I know (and I have some good sources), the grandparent post is correct: NT4 likely had some BSD code in the TCP/IP stack (since the reference implementation came from Berkely), and they completely rewrote the stack for 2000.
Where did you get the information to the contrary?
I like your idea of tying macros to objects (classes, actually). But they could be more than just inline methods.
Macros might be able to do more than just expand to a method. They could expand to a language construct such as an inner class, a for loop, a return statement, etc.
Obviously, this leads to more complexity for syntax highlighting and compilers. And it leads to constructs that could drive the programmer nutty (ok, who defined "==" as "!="?). Which is why the Java guys don't want them in the language. "Shoot, I can't do that with that set of macros loaded, I need my own personal custom set of macros for this project..."
I won an award for those fjords.
But that's just it: we can't examine their source, so it is harder to prove wrongdoing! :)
My bad. Good point! There are many projects with heavy industry backing, and that helps.
The current record for TPC-C for non-clustered systems is a Windows Server 2003 (64 bit edition) on a 64 processor IA64 system from HP running SQL Server 2000 64 bit edition. It runs 707k TPM in official benchmarks.
The Intel system mentioned was a 32 processor IA64 system running Oracle. It got a score of "near 600k" in Intel's internal benchmarks.
Intel is keeping quiet about the details, and hasn't yet submitted a system for "official" testing. But it sounds like their kernel tweaks and their optimizing compiler have made a huge difference, and Oracle on Linux is a serious contender.
Very true. There is always the possibility that the commercial vendor is also selling something that is not properly licensed.
But in reality, having the lawyers actually makes a difference in this case. All major software companies pay lawyers to check and make sure that everything is legit. If the lawyers miss something (or if the software company gets caught trying to pull a fast one), a commercial software vendor will be the first target for litigation, and will provide at least some kind of shield for the customer. The software vendor is likely to have a legal team to mount a defense, and is also likely to at least try to negotiate some kind of deal with the plaintiff. With open source, there is no company to attract the first pot-shots, so the users are the primary targets.
For many, this risk is well worth taking, which is why open source projects continue to be used. But it is definitely a real consideration that needs to be examined before you bet the company on an open source project.
I sincerely hope that all of this blows over. I'm very suspect of SCO's claims, especially since they won't let the evidence out, which means that they're going to charge royalties for everyone using their code without telling us exactly what we need to remove their code from Linux. Withholding the evidence is making everyone mad, and preventing us from "coming clean" by removing "their" code or even by licensing "their" Linux if we feel so inclined.
However, let's assume that there are right -- they own Unix, and there are segments of code, up to 80 lines in length, that match between Linux and Unix. What does that show? Still nothing in itself. The code could also be in BSD, in which case it would be free and clear from any SCO claims (although if it lacks the appropriate copyright label, the Berkeley regents might have to send their agents over to rough Linus up a bit (grin)). Or something like that. The code might well be public domain stuff (from an academic paper, from some code library, etc.), so nothing to see.
But assume SCO does own the code. We just rewrite those sections and call it good, right? Wrong. The sections are evidence of contamination, and it will be difficult to determine exactly how far the contamination goes. If someone could copy and paste SCO code, he/she was also probably doing other things -- opening the Unix code in one window, and writing a similar Linux routine in another window, referring back to the Unix code for a "how-to". This is also illegal, as such things need to be done via clean room reverse engineering procedures.
SCO will then argue that the contamination is very deep. IBM and the Open Source people in general will argue that the contamination is insignificant. It might be hard to tell in some cases. SCO will argue that the design patterns in use in Linux were stolen from Unix, and that those design patterns are crucial IP. Everything built around that design will have to be rewritten, probably with a different design to prove that we aren't continuing to steal their precious design. And then everything that depends on that design will also have to be rewritten. Etc. Depending on how deep the problem goes (according to what the courts decide), it may or may not be feasible to rewrite the affected portions and send out patches. The problem is that lawyers may have to get involved, certifying that the portions rewritten comply with all necessary laws and no longer intrude on SCO's IP. It may be necessary to abandon portions of Linux entirely, perhaps importing replacement code from BSD or the like.
In the meantime, all of the big fish who have been using Linux will be sued for royalties. I'm sure that many suits will be dismissed, but some will be upheld.
Whether or not SCO wins, this will be a wakeup call. Before accepting GNU tools for use in the business, managers are now going to be asking, "how can we be certain that this code is legit?" It is a very valid question. All source has pedigree -- are there any portions of this code that might be discovered to belong to someone else? If so, what protects us from having that code yanked out from under us? Somebody could sue us for damages, refuse to license the code to us, and shut down our entire operation.
If SCO wins, beyond the damage to Linux itself, a lot of people are going to get very nervous about using open source products in general in the business world. Even if they lose, things are still going to get a bit more tense, as you may have to prove the code's purebred pedigree before you can use it to run your IT department.
I dunno. Slippers come off too easily...
Wrong. Branching is done properly with each release, at least on all of the products that I have worked with. But some patches have side effects. For example, if some SQL function can be used to do something bad to the database but can be run by an unprivileged user, the fix might be to change the privileges on that function. But what if one of your applications depended on that function being available at the former privilege level? Also, the patches happen at the file level, which means that if file XXX.dll has had 15 patches since release, if you want patch #15, you also get patches #1-14. It is hard to avoid all situations like these, so regression testing is a necessary part of patching "high availability" systems on any platform, not just Windows.
Updating hourly doesn't help if they still blindly open attachments. Changing to a "safer" email client doesn't help either, unless it is a VB Script virus (this one isn't).
So how does running Mozilla prevent you from getting this virus? Does Mozilla prohibit attachments or something? Any email program that supports attachments is vulnerable to email viruses. It's that "user hole" that you can't get rid of, no matter what email client you use.