As some have pointed out, turning off password protection is generally not considered the best way to handle security. However, 1) it is not my computer and 2) physical access to the machine should be considered adequate authentication. After all, we aren't going to store anything sensitive and if a cat burglar comes in and wants our files, nothing short of encrypting everything on the drive is going to get in the way. The root password is irrelevant.
Perhaps this is one reason Linux is having difficulty penetrating the home users: they think of the computer more like an appliance rather than a connection to a vast network. ("onramp to the information superhighway"... thank you al gore...) Without a nice Internet connection or LAN, though, a home computer really is just an appliance. Hackers and experienced professionals don't think that way, so the software they write often doesn't quite fit home users.
That's an analysis of the present state of Linux. Given the current momentum, the gaps will close and we will be able to write off Windows as a "decade-long fad of the 90's"!
I set up Linux on my family's computer. The problem is that it doesn't make much sense that people should have to type passwords just to turn on the computer. But they should not have the ability to access it remotely, either. How do I set up Linux in such a way that local-only users, who don't need a password, can't log in remotely, while people like myself (with an ugly password) can?
Linux is to Windows NT as the Enterprise (NCC-1701D) is to the Umoto.
How many of you remember the episode of ST:TNG in which the Enterprise contracted a virus from a probe and nearly blew apart? The name of the Enterprise's sister ship, which they revealed in that episode, was the Umoto. Remember what happened to the Umoto?;-) The Enterprise survived because of the skill and resourcefulness of the people maintaining it.
Yeah, the analogy isn't perfect but remember that contracting a virus from an alien probe isn't perfect storytelling either.
Of course you have to remember that Commander Data also contracted the virus. He dealt with it better than the other computers--although it spread much faster and nearly killed him, his internal workings solved the problem for him. What operating system would he represent? Hmmm...
The double-slash was originally intended to work with C++ only, not C. People liked the idea so they started using it in C as well. Then it finally became a standard.
However, not all compilers have not caught up. I don't know of specific examples, but some Unix variants still do not understand it. Therefore you should not use it if you intend to make your source code widely available. And if you think your source code will never, ever be widely available or maintained by someone else, think again.
Incidentally, in C and C++ another way to comment out source code is like this:
Since "0" is always false, s = "World, hello!" will not be compiled.
That way the commenting can be nested and you can be sure compilers will recognize it. A drawback is that colorized editors will not recognize it as a comment. Another drawback is that there is no equivalent in Java and you have to fall back to regular comments.
a) After another day of befuddled users and broken Windows, the slashdotter comes to the conclusion that the best way to bring down Microsoft is from the INSIDE... BWAHAHAHA!!
b) Evil spirits summon his keyboard and his cyberspace travels take a wrong turn. In a frantic attempt to return to the true reality, the slashdotter pleas with the spirits to allow him to post on slashdot. Seeing no harm in this, they allow it, thinking Rob will *never* let such a comment get through. CmdrTaco saves the day... and you know the rest of the story.
c) The slashdotter's nephew, a BSBA, discovers the slashdotter's bookmark that automatically logs him in and thinks he has outhacked the slashdotter. He reports of the job opening, which he intends to take for himself, as a way to further glorify himself. He gets the job and spends the rest of his life writing fearfully uncertain and doubtful material. Microsoft OWNS him.
Thank you for providing this insight. It's important for us as computer professionals to remember the human impact of the things we do, especially when our egos are being threatened.
The brainstorming sessions on/. are extraordinary, aren't they?:) I confess, I'm an addict.
/.'ers interested in panoramic images ought to visit the 1999 Cougar QTVR site (requires QuickTime). The second image on the page is a "double-spin" image: on the first turn the back seat of the Cougar is folded down, and on the second turn it is up. Pretty cool IMHO.
There are plenty of near-future applications that an in-depth study of Mars will help. Perhaps we'll find a way to better predict earthquakes... or even marsquakes:)... maybe by learning more about the formation of planets on a macroscopic scale, we can gain a better understanding of objects at the microscopic level as well.
However, the most important things we learn by studying Mars and other planets are things we cannot yet foresee. Mars exploration can be characterized, for the most part, as purely scientific research right now. The practical applications will manifest themselves later on.
The first thing I did when I saw these pictures is I searched for a rectangular topological map that could be applied as a texture to a sphere. I found one here. Then I cropped it down to only the map itself and put it into Extreme 3D and a simple spinning animation is being rendered as I type. Once it's finished you'll be able to look at it here.
Of course, real-time fly-bys and ultra-high resolution images would be much better. Anyone have any ideas?
Not that I doubt this statement, I just wanted to elaborate on the quote above:
some people reckon the object allocation (on the 'heap') is as fast as C++'s on the stack! (in C++, allocating to the stack is much faster than the heap)
Stack allocation in C++ is faster than you might imagine. Take the following code snippet:
main() { int a; int b = 3; a = b; }
Allocating the variables a and b involves only changing the stack pointer. Probably something like this:
add sp, 8
That's ALL! Now if Hotspot can achieve, through sophisticated algorithms, speed that rivals such simple allocation, I think Sun deserves some CREDIT!!
I like ST's metaphoric dealing with a whole bunch of contemporary issues MUCH better than SW's black-and-white, good vs. evil and that's that type of storyline.
Insightful! Star Trek does indeed use a lot of metaphors. They even hinted at that fact in the episode where the Captain Picard was forced to learn to communicate with a race that spoke in a purely metaphorical language.
Another distinction that only Star Trek has is that they confront human issues that apply not only to the fictional universe but also can be applied to the real world.
One of the best examples is the ST:TNG episode where Riker is offered the power of Q. At first we all hoped he would have the restraint to not allow the powers to affect his judgment or personality. But instead, through very good acting IMHO, he changed in a way that made him exhibit less respect for authority. We all got to see an enactment of the quote "power corrupts, and absolute power corrupts absolutely" in an entertaining, educational, and harmless way. And we learned more about the character of Will Riker. We learned one of his weaknesses.
I think it's not hard to see something of ourselves--or someone we know--in each of the characters in Star Trek. That's what makes me like the characters so much.
BTW did you folks know Brent Spiner (Data) is a very good singer and has produced a CD? It's called "Old Yellows Eyes is Back" or something like that. I highly recommend it.
Java 1, Sun 0. A year ago, it was difficult to see the difference between Sun and Java. But now a ruling has been made that's good for Java and bad for Sun, thus making a clear distinction. Anyone interested in this topic should visit the JavaLobby.
I'm sure most of you know by now that you can donate to specific projects/authors at LinuxMall. However, when I last made a purchase there I did not include a donation because a measly $5 or even $50 seems ungrateful.
Returning to the main topic of this thread, I see myself as being in two positions at once. I am writing a piece of software that I wish to open-source, and getting paid for it would be nice but it's not my motivation. I also wish to help compensate the people who have written my OS, but unless I can be sure my little donation is being combined with thousands of others' donations, these people are receiving "tokens" rather than what they deserve.
We need organizations like SourceXchange to help change the economics of software development.
You know, you're right. There is a distinction between software engineering and computer science and I often blur the two.
Research in pure computer science might get you a name in the computer science history books, but software engineering seems like a lot more fun.:) Go Linus!
I believe he has made a significant contribution to computer science. To my knowledge he has not released any new theories or programming models, but he has helped us to apply a practical perspective to existing theories.
For example, he explicitly chose to build a monolithic kernel as opposed to a microkernel. Conventional theory dictates that a microkernel is more flexible and expandable, but Linus believes it is better to put core system functions together in one large piece of memory. Now that Linux is available to everyone, we can all evaluate that choice and more aptly decide for ourselves whether abstraction is the right choice for our needs.
If that doesn't earn him a doctorate, I don't know what does.
Consider the expansion of the telephone system. Over time we have added more digits. Yes, there have been glitches (sometimes you just can't call your aunt in Africa because of some kind of "busy" signal) but we have solved problem after problem and I think we can take it for granted that even if we run out of area codes, we'll find a way to squeeze in more digits. Same goes for IP. Of course, solutions like IP masquerading work very, very well IMHO and not every computer really needs its own instant global access point.
In my experience, where FTP breaks down most often is that the users don't know how to find the correct directory on the server. For a long time, the Web server I worked on required the users to know the following:
server: sol.wlcc.edu user name: w password: directory:/usr/ns-home/docs/
All of this, especially the last line, was too much to handle. And they didn't use FTP often enough to remember that all the info was already stored in a WS_FTP profile. Why, it was too much for them to remember what "FTP" and "WS_" were!
We solved the problem with a special FTP client that automatically transfers files. It downloads the appropriate section of the site onto the user's HD and queues files for transfer when it sees changes on either the HD or the server. It has actually worked quite well, in combination with Dreamweaver (highly recommended).
(Please e-mail me if you're interested in the FTP client. Remove the "spammenot".)
I would argue that certain types of projects demand safety-oriented software engineering, such as computer control for anti-lock brakes, air traffic control, and missile launch mechanisms. I know I would feel better when I fly if I knew that it was absolutely impossible for the air traffic monitoring software to throw a null pointer exception.
(Oops, I posted this already but the formatting was destroyed. Sorry.)
I am optimistic about the future of user interface development on Linux/Unix because there is a lot of motivation to get it done and because the overall architecture is now defined. Let me elaborate.
Raph's outstanding comment explains some the motivation for UI development. I am in the position he described and am constantly struggling to make it possible for end users to do the things they're supposed to be able to do with their expensive hardware and software. It's a great frustration when big office suites crash the workstation for no apparent reason, and the cause of the problem turns out to be something obscure such as a misconfigured SCSI card. The UI is there but it's built on an unstable foundation.
Those who provide support for end users demand a higher level of quality and are often willing to sacrifice their personal time to provide that quality, if only one small project at a time. Some innovative companies actually pay their highly-skilled employees to improve the overall quality of software, which in theory will reap benefits in the long run. Netscape (AOL) is probably the best example.
Netscape/AOL's Mozilla project is also a good example of an application being built with the entire UI known beforehand. Developers today have a lot of advantage over those who tried to create UI's a decade ago because there are now lots of good examples of previous efforts. For example, text-based menus were a bad idea, but they seemed like a good idea until graphical menus became commonly available.
So, basically, we now have a good idea of what a UI should look like and how it should behave. We have a reasonably well-defined target platform: both pointing device and keyboard inputs, pixel-mapped video, pop-up menus, resizable windows, icons, etc. An immeasurable amount of work has been put into modern GUI design.
UI's built on a stable foundation will continue to evolve because there are knowledgeable people who are motivated to do it and because the work is not as difficult as it was in past years. I am trying to do my part with a UI-enabled project I intend to license as open source.
I am optimistic about the future of user interface development on Linux/Unix because there is a lot of motivation to get it done and because the overall architecture is now defined. Let me elaborate. Raph's outstanding comment explains some the motivation for UI development. I am in the position he described and am constantly struggling to make it possible for end users to do the things they're supposed to be able to do with their expensive hardware and software. It's a great frustration when big office suites crash the workstation for no apparent reason, and the cause of the problem turns out to be something obscure such as a misconfigured SCSI card. The UI is there but it's built on an unstable foundation. Those who provide support for end users demand a higher level of quality and are often willing to sacrifice their personal time to provide that quality, if only one small project at a time. Some innovative companies actually pay their highly-skilled employees to improve the overall quality of software, which in theory will reap benefits in the long run. Netscape (AOL) is probably the best example. Netscape/AOL's Mozilla project is also a good example of an application being built with the entire UI known beforehand. Developers today have a lot of advantage over those who tried to create UI's a decade ago because there are now lots of good examples of previous efforts. For example, text-based menus were a bad idea, but they seemed like a good idea until graphical menus became commonly available. So, basically, we now have a good idea of what a UI should look like and how it should behave. We have a reasonably well-defined target platform: both pointing device and keyboard inputs, pixel-mapped video, pop-up menus, resizable windows, icons, etc. An immeasurable amount of work has been put into modern GUI design. UI's built on a stable foundation will continue to evolve because there are knowledgeable people who are motivated to do it and because the work is not as difficult as it was in past years. I am trying to do my part with a UI-enabled project I intend to license as open source.
One reason Windows is so unstable is because it is built on the assumption that device drivers are flawless. Microsoft always had the intention of "certifying" every device driver that makes it into a Windows setup. Unfortunately that kind of quality assurance is very near impossible, even for Unix experts / software geniuses.
The difference with Unix/Linux is that any process can be killed and restarted, and there is always some kind of escape that allows the user to execute a kill. Even buggy filesystems and video drivers (X servers) can be killed. For example, I run KDE and there appears to be some kind of bug in KDE that causes it to lose the ability to launch new processes after running for days--it won't even let me log out. But I can always use the ctrl-alt-backspace keystroke.
So anyone who's interested in building a GUI Linux should take into consideration the fact that the drivers and apps written for it *will* be bug-ridden. Always provide the most graceful exit possible.
In support of your view, here's a more plausible theory based on real-world experience.
I am a software developer who also has to maintain some lab computers and help a number of non-tech users. Where I work there is an excessive amount of support for Mac, Windows, and Unix environments.
We often have to transfer files between environments. Those of you who may have tried to allow their users to transfer files between these different environments know how incompatible they are. When we learned that a Linux box could be set up as a router supporting the native network protocols for each environment, we got excited. Windows NT, Mac servers, and even our Solaris boxes did not provide this kind of capability.
Along the way I discovered a bug in Samba, found the problem in the source, fixed it, and sent a patch back to samba.org.
Now, my point is this: the people who provide support for users often have the skill to make corrections in the operating system. Not only does that make those people more valuable, thus paying them indirectly through salary increases, but it makes the software more valuable. The "no cost" feature is irrelevant in this context.
Their are many other arguments similar to this one that support OSS.
Starting nmap V. 2.08 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) Interesting ports on www.2600.com (207.99.30.230): Port State Protocol Service 21 open tcp ftp 22 open tcp ssh 80 open tcp http 111 open tcp sunrpc
Slashdot Mirror
Thank you for that advice.
As some have pointed out, turning off password protection is generally not considered the best way to handle security. However, 1) it is not my computer and 2) physical access to the machine should be considered adequate authentication. After all, we aren't going to store anything sensitive and if a cat burglar comes in and wants our files, nothing short of encrypting everything on the drive is going to get in the way. The root password is irrelevant.
Perhaps this is one reason Linux is having difficulty penetrating the home users: they think of the computer more like an appliance rather than a connection to a vast network. ("onramp to the information superhighway"... thank you al gore...) Without a nice Internet connection or LAN, though, a home computer really is just an appliance. Hackers and experienced professionals don't think that way, so the software they write often doesn't quite fit home users.
That's an analysis of the present state of Linux. Given the current momentum, the gaps will close and we will be able to write off Windows as a "decade-long fad of the 90's"!
I set up Linux on my family's computer. The problem is that it doesn't make much sense that people should have to type passwords just to turn on the computer. But they should not have the ability to access it remotely, either. How do I set up Linux in such a way that local-only users, who don't need a password, can't log in remotely, while people like myself (with an ugly password) can?
Linux is to Windows NT as the Enterprise (NCC-1701D) is to the Umoto.
;-) The Enterprise survived because of the skill and resourcefulness of the people maintaining it.
How many of you remember the episode of ST:TNG in which the Enterprise contracted a virus from a probe and nearly blew apart? The name of the Enterprise's sister ship, which they revealed in that episode, was the Umoto. Remember what happened to the Umoto?
Yeah, the analogy isn't perfect but remember that contracting a virus from an alien probe isn't perfect storytelling either.
Of course you have to remember that Commander Data also contracted the virus. He dealt with it better than the other computers--although it spread much faster and nearly killed him, his internal workings solved the problem for him. What operating system would he represent? Hmmm...
The double-slash was originally intended to work with C++ only, not C. People liked the idea so they started using it in C as well. Then it finally became a standard.
However, not all compilers have not caught up. I don't know of specific examples, but some Unix variants still do not understand it. Therefore you should not use it if you intend to make your source code widely available. And if you think your source code will never, ever be widely available or maintained by someone else, think again.
Incidentally, in C and C++ another way to comment out source code is like this:
main() {
char *s = "Hello world!";
#if 0
s = "World, hello!";
#endif
puts(s);
}
Since "0" is always false, s = "World, hello!" will not be compiled.
That way the commenting can be nested and you can be sure compilers will recognize it. A drawback is that colorized editors will not recognize it as a comment. Another drawback is that there is no equivalent in Java and you have to fall back to regular comments.
a) After another day of befuddled users and broken Windows, the slashdotter comes to the conclusion that the best way to bring down Microsoft is from the INSIDE... BWAHAHAHA!!
b) Evil spirits summon his keyboard and his cyberspace travels take a wrong turn. In a frantic attempt to return to the true reality, the slashdotter pleas with the spirits to allow him to post on slashdot. Seeing no harm in this, they allow it, thinking Rob will *never* let such a comment get through. CmdrTaco saves the day... and you know the rest of the story.
c) The slashdotter's nephew, a BSBA, discovers the slashdotter's bookmark that automatically logs him in and thinks he has outhacked the slashdotter. He reports of the job opening, which he intends to take for himself, as a way to further glorify himself. He gets the job and spends the rest of his life writing fearfully uncertain and doubtful material. Microsoft OWNS him.
Thank you for providing this insight. It's important for us as computer professionals to remember the human impact of the things we do, especially when our egos are being threatened.
/. are extraordinary, aren't they? :) I confess, I'm an addict.
The brainstorming sessions on
/.'ers interested in panoramic images ought to visit the 1999 Cougar QTVR site (requires QuickTime). The second image on the page is a "double-spin" image: on the first turn the back seat of the Cougar is folded down, and on the second turn it is up. Pretty cool IMHO.
However, the most important things we learn by studying Mars and other planets are things we cannot yet foresee. Mars exploration can be characterized, for the most part, as purely scientific research right now. The practical applications will manifest themselves later on.
Of course, real-time fly-bys and ultra-high resolution images would be much better. Anyone have any ideas?
some people reckon the object allocation (on the 'heap') is as fast as C++'s on the stack! (in C++, allocating to the stack is much faster than the heap)
Stack allocation in C++ is faster than you might imagine. Take the following code snippet:
main()
{
int a;
int b = 3;
a = b;
}
Allocating the variables a and b involves only changing the stack pointer. Probably something like this:
add sp, 8
That's ALL! Now if Hotspot can achieve, through sophisticated algorithms, speed that rivals such simple allocation, I think Sun deserves some CREDIT!!
Insightful! Star Trek does indeed use a lot of metaphors. They even hinted at that fact in the episode where the Captain Picard was forced to learn to communicate with a race that spoke in a purely metaphorical language.
One of the best examples is the ST:TNG episode where Riker is offered the power of Q. At first we all hoped he would have the restraint to not allow the powers to affect his judgment or personality. But instead, through very good acting IMHO, he changed in a way that made him exhibit less respect for authority. We all got to see an enactment of the quote "power corrupts, and absolute power corrupts absolutely" in an entertaining, educational, and harmless way. And we learned more about the character of Will Riker. We learned one of his weaknesses.
I think it's not hard to see something of ourselves--or someone we know--in each of the characters in Star Trek. That's what makes me like the characters so much.
BTW did you folks know Brent Spiner (Data) is a very good singer and has produced a CD? It's called "Old Yellows Eyes is Back" or something like that. I highly recommend it.
Java 1, Sun 0. A year ago, it was difficult to see the difference between Sun and Java. But now a ruling has been made that's good for Java and bad for Sun, thus making a clear distinction. Anyone interested in this topic should visit the JavaLobby.
Returning to the main topic of this thread, I see myself as being in two positions at once. I am writing a piece of software that I wish to open-source, and getting paid for it would be nice but it's not my motivation. I also wish to help compensate the people who have written my OS, but unless I can be sure my little donation is being combined with thousands of others' donations, these people are receiving "tokens" rather than what they deserve.
We need organizations like SourceXchange to help change the economics of software development.
You know, you're right. There is a distinction between software engineering and computer science and I often blur the two.
:) Go Linus!
Research in pure computer science might get you a name in the computer science history books, but software engineering seems like a lot more fun.
For example, he explicitly chose to build a monolithic kernel as opposed to a microkernel. Conventional theory dictates that a microkernel is more flexible and expandable, but Linus believes it is better to put core system functions together in one large piece of memory. Now that Linux is available to everyone, we can all evaluate that choice and more aptly decide for ourselves whether abstraction is the right choice for our needs.
If that doesn't earn him a doctorate, I don't know what does.
Consider the expansion of the telephone system. Over time we have added more digits. Yes, there have been glitches (sometimes you just can't call your aunt in Africa because of some kind of "busy" signal) but we have solved problem after problem and I think we can take it for granted that even if we run out of area codes, we'll find a way to squeeze in more digits. Same goes for IP. Of course, solutions like IP masquerading work very, very well IMHO and not every computer really needs its own instant global access point.
In my experience, where FTP breaks down most often is that the users don't know how to find the correct directory on the server. For a long time, the Web server I worked on required the users to know the following:
/usr/ns-home/docs/
server: sol.wlcc.edu
user name: w
password:
directory:
All of this, especially the last line, was too much to handle. And they didn't use FTP often enough to remember that all the info was already stored in a WS_FTP profile. Why, it was too much for them to remember what "FTP" and "WS_" were!
We solved the problem with a special FTP client that automatically transfers files. It downloads the appropriate section of the site onto the user's HD and queues files for transfer when it sees changes on either the HD or the server. It has actually worked quite well, in combination with Dreamweaver (highly recommended).
(Please e-mail me if you're interested in the FTP client. Remove the "spammenot".)
I would argue that certain types of projects demand safety-oriented software engineering, such as computer control for anti-lock brakes, air traffic control, and missile launch mechanisms. I know I would feel better when I fly if I knew that it was absolutely impossible for the air traffic monitoring software to throw a null pointer exception.
(Oops, I posted this already but the formatting was destroyed. Sorry.)
I am optimistic about the future of user interface development on Linux/Unix because there is a lot of motivation to get it done and because the overall architecture is now defined. Let me elaborate.
Raph's outstanding comment explains some the motivation for UI development. I am in the position he described and am constantly struggling to make it possible for end users to do the things they're supposed to be able to do with their expensive hardware and software. It's a great frustration when big office suites crash the workstation for no apparent reason, and the cause of the problem turns out to be something obscure such as a misconfigured SCSI card. The UI is there but it's built on an unstable foundation.
Those who provide support for end users demand a higher level of quality and are often willing to sacrifice their personal time to provide that quality, if only one small project at a time. Some innovative companies actually pay their highly-skilled employees to improve the overall quality of software, which in theory will reap benefits in the long run. Netscape (AOL) is probably the best example.
Netscape/AOL's Mozilla project is also a good example of an application being built with the entire UI known beforehand. Developers today have a lot of advantage over those who tried to create UI's a decade ago because there are now lots of good examples of previous efforts. For example, text-based menus were a bad idea, but they seemed like a good idea until graphical menus became commonly available.
So, basically, we now have a good idea of what a UI should look like and how it should behave. We have a reasonably well-defined target platform: both pointing device and keyboard inputs, pixel-mapped video, pop-up menus, resizable windows, icons, etc. An immeasurable amount of work has been put into modern GUI design.
UI's built on a stable foundation will continue to evolve because there are knowledgeable people who are motivated to do it and because the work is not as difficult as it was in past years. I am trying to do my part with a UI-enabled project I intend to license as open source.
I am optimistic about the future of user interface development on Linux/Unix because there is a lot of motivation to get it done and because the overall architecture is now defined. Let me elaborate. Raph's outstanding comment explains some the motivation for UI development. I am in the position he described and am constantly struggling to make it possible for end users to do the things they're supposed to be able to do with their expensive hardware and software. It's a great frustration when big office suites crash the workstation for no apparent reason, and the cause of the problem turns out to be something obscure such as a misconfigured SCSI card. The UI is there but it's built on an unstable foundation. Those who provide support for end users demand a higher level of quality and are often willing to sacrifice their personal time to provide that quality, if only one small project at a time. Some innovative companies actually pay their highly-skilled employees to improve the overall quality of software, which in theory will reap benefits in the long run. Netscape (AOL) is probably the best example. Netscape/AOL's Mozilla project is also a good example of an application being built with the entire UI known beforehand. Developers today have a lot of advantage over those who tried to create UI's a decade ago because there are now lots of good examples of previous efforts. For example, text-based menus were a bad idea, but they seemed like a good idea until graphical menus became commonly available. So, basically, we now have a good idea of what a UI should look like and how it should behave. We have a reasonably well-defined target platform: both pointing device and keyboard inputs, pixel-mapped video, pop-up menus, resizable windows, icons, etc. An immeasurable amount of work has been put into modern GUI design. UI's built on a stable foundation will continue to evolve because there are knowledgeable people who are motivated to do it and because the work is not as difficult as it was in past years. I am trying to do my part with a UI-enabled project I intend to license as open source.
One reason Windows is so unstable is because it is built on the assumption that device drivers are flawless. Microsoft always had the intention of "certifying" every device driver that makes it into a Windows setup. Unfortunately that kind of quality assurance is very near impossible, even for Unix experts / software geniuses.
The difference with Unix/Linux is that any process can be killed and restarted, and there is always some kind of escape that allows the user to execute a kill. Even buggy filesystems and video drivers (X servers) can be killed. For example, I run KDE and there appears to be some kind of bug in KDE that causes it to lose the ability to launch new processes after running for days--it won't even let me log out. But I can always use the ctrl-alt-backspace keystroke.
So anyone who's interested in building a GUI Linux should take into consideration the fact that the drivers and apps written for it *will* be bug-ridden. Always provide the most graceful exit possible.
In support of your view, here's a more plausible theory based on real-world experience.
I am a software developer who also has to maintain some lab computers and help a number of non-tech users. Where I work there is an excessive amount of support for Mac, Windows, and Unix environments.
We often have to transfer files between environments. Those of you who may have tried to allow their users to transfer files between these different environments know how incompatible they are. When we learned that a Linux box could be set up as a router supporting the native network protocols for each environment, we got excited. Windows NT, Mac servers, and even our Solaris boxes did not provide this kind of capability.
Along the way I discovered a bug in Samba, found the problem in the source, fixed it, and sent a patch back to samba.org.
Now, my point is this: the people who provide support for users often have the skill to make corrections in the operating system. Not only does that make those people more valuable, thus paying them indirectly through salary increases, but it makes the software more valuable. The "no cost" feature is irrelevant in this context.
Their are many other arguments similar to this one that support OSS.
Starting nmap V. 2.08 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on www.2600.com (207.99.30.230):
Port State Protocol Service
21 open tcp ftp
22 open tcp ssh
80 open tcp http
111 open tcp sunrpc
TCP Sequence Prediction: Class=random positive increments
Difficulty=134983 (Good luck!)
Remote operating system guess: FreeBSD 2.2.1 - 3.0
Nmap run completed -- 1 IP address (1 host up) scanned in 78 seconds
I think the changes you've been making to Slashdot are great but please be sure the front page doesn't come out in all bold. It's harder to read.