FreeBSD oopses when you 'hotplug' USB devices at the wrong time and thrashes your data if you lose power at the wrong time (oh, that's right, use SCSI), one of NetBSD's founders just came out and said the project is doomed, DragonflyBSD is an effort at a massive rewrite in early stages (certainly unsafe for production) and OpenBSD is driven by a raving loonie.
By contrast, Linux has/real/ technical advantages, is more portable than NetBSD, performs better cross-spectrum than any of the BSDs, and it's all in one convenient package with tons of corporate backing!
Anyone who moves from a superior solution to an inferior one over a pointless licensing debate is nuts.
What makes me angry about this isn't that I won't be able to find movies online; hell, it's usually possible to get them before they're even available from Blockbuster. What's irritating is that I'm an honest customer of the MPAA. I have a huge shelf of DVDs. I'm a DVD collector. The first time I buy a DVD that has been engineered in such a way to not play, I'm going to return it and never buy a DVD again.
Note: This doesn't mean I'm going to stop watching movies. Do the fucking math, MPAA.
So what do you think the judge should have done in this case, given that the defendant gave the court de facto jurisdiction and then failed to make an appearance? If you fail to follow courtroom procedure and get censured for it, that's your own damn fault (in this case Spamhaus). Besides, if the judge does use e-mail, I'm sure the judge also knows what spam is.
Yes, you should absolutely choose as many different platforms as possible; that way, you can keep yourself important as each platform fails in new, different and exciting ways and you scramble around trying to fix them.
This is ridiculous. This has nothing to do with back doors. This is literally saying "you can run arbitrary code in kernel mode by inserting a kernel module!" So what! If you're worried, disable kernel module support or use SELinux to tighten down who may load them even further!
As the first person who replied to this announcement in LKML, I will certify that this "weakness" is pretty silly. Here's what the claim is:
1. You must be root 2. You must be able to load an arbitrary kernel module 3. You write an arbitrary kernel module that calls a kernel function to install yourself as an "binfmt handler" 4. That kernel module is put on the _front_ of the list instead of the _end_ 5. Every program that runs now ends up calling your "binfmt handler" first
Their solution:
1. Put it on the _end_ of the list instead of the _front_ when it registers itself, that way it only runs if the binfmt cannot be identified...
This is literally just as stupid as discovering that you can call fork() and exec() with an argv of "/bin/rm", "-rf", "*". Oh no, everyone must patch their systems! Seriously, anyone who can load an arbitrary kernel module could technically do _anything_, including replace the whole kernel image from the inside out!
It's not really thread ping pong that sucks. The operating system should provide reasonable soft affinity to keep that from sucking. It's really more about how many shared cache lines you have to worry about, because then you have a thread running on each processor that wants to manipulate the same cache line at the same time. That's when you really fall on your face.
Now, I'll admit to knowing nothing about BeOS. They might have been very clever. But many of the multithreading designs I've seen are sadly the kind of things that lose their scalability after a couple of CPUs.
Actually, such an architecture with careless multithreading can be a disaster if misused. When you have lots of threads running on one CPU, there isn't much penalty, especially if the OS is wise enough not to do anything that might flush the TLB in between thread-switching. All the necessary locks and whatnot will be in cache.
The problem with adding cores is that the operating system scheduler (naturally) is going to spread those threads out across all those cores or CPUs. At that point, you better damn well have broken your application down correctly, pipelining work and being careful not to depend too much on centralized locks, or else the resulting cache-line ping-pong is the only thing you are going to be doing with your chip.
To that end, putting every interdependent program component into a thread context of its own sounds like a disaster waiting to happen, because that's not how you make useful use of lots of cores.
I said scale and schedule usefully, not "run". Big, big difference. Last I heard, OS X Tiger only had 6 kernel locks. You expect that to run usefully on 80 cores? Anandtech even said "We definitely had a difficult time stressing 8 cores in the Mac Pro"...
This is hilarious, because if this goes out on the market there's not going to be many operating systems capable of scheduling on that many chips usefully. OS X can't do it, Windows can't do it, and nor can BSD. But Linux has been scheduling on systems with up to 1,024 processors already:)
Still wrong, as the Anonymous Coward is also pointing out.
If you ran into an endianness assumption, that is a bug, plain and simple. Among Linux's excellent portability layer is a set of macros to swap byte order how and when necessary (cpu_to_le32, cpu_to_be32, etc). If you find *any* architecture specific code that is not in either "include/asm-*/" or "arch/*", it is a bug and should be reported. And for the record, PCI drivers don't live under "arch/*".
All of these things are things you would know if you actually LOOKED at the code you so readily criticize. Linux is free and freely available. Get a copy from kernel.org and see for yourself.
Your post is full of 100% false FUD! Linux supports more architectures than NetBSD, and additionally, Linux drivers most certainly are *NOT* tied to one architecture. That is simply not true at all, and I say that as someone who has worked on the kernel before.
There is more to every story than you might think. If Apple is now pretending that their "delayed" release of x86 XNU was due to miscommunication or preparation, that's called "public relations" not "truth".
OK, perhaps so. I'm not a game developer, I've just assumed that the 3D guys would have adopted basic power management techniques by now. If they have not, it's not going to be very long before they do, because of the exact reasons you cite.
DragonFly BSD is a redesign and reimplementation of the FreeBSD kernel and userland libraries from the bottom up, with the main goal being for it to scale very well on multicore and multiprocessor systems.
Redesign and reimplementation seems to imply starting from scratch. This doesn't seem to be the case for DragonflyBSD.
So while FreeBSD, NetBSD and OpenBSD will still be working on getting their kernel sufficiently threaded for many years to come, DragonFly BSD will have had that task completed for a while.
DragonflyBSD has the development resources necessary to redesign and reimplement the FreeBSD kernel, *and* get their kernel "threaded" faster than the other BSD projects already working hard on that task?
Pardon me, but I don't think your description makes much sense, and it doesn't sound like you know anything about operating system scalability. In a monolithic kernel design like Linux, FreeBSD, NetBSD, OpenBSD or DragonflyBSD, "threads" are largely a user-space concept. Sure, you have kernel threads to run specialized tasks, but the bulk of the performance critical code runs "on top of" or "on behalf of" user tasks. This differs from a microkernel implementation where the kernel is really broken down into multiple threads that pass messages (even then, however, certain kernel functions like memory management and process scheduling must be centralized.)
In reality, the real effort of creating better scalability centers on implementation of finer-grained locking and faster data structures, so that the locks aren't as contended as they once were.
Reportedly, it has become better than Irix at many tasks, and is even beginning to rival Solaris. With Irix still trumping Linux in most cases, this goes to show how far ahead DragonFly BSD already is.
DragonflyBSD is interesting, but I don't think you should be making claims like this without providing verifiable data. Do you have any references?
Curious that you blame that hardware companies and not X. Why should hardware companies feel obligated to support GPLed software?
They shouldn't have to; rather, they should just go back to releasing specifications to their customers like they used to. I think there are plenty of people in the BSD community that would agree with me on this, especially Theo.
Documentation of that opinion appears regularly and it take far more than "proof of concept" to make a platform "suitable for the average user".
You've made an attempt to totally dodge my question.
Acutally it proves what's right with it. Apple used BSD code precisely in the manner that BSD people would like.
That does nothing to address my point, which is that forks of this nature are bad. Whether or not the BSD developers themselves intended to allow that is a different issue.
They didn't run off with the code. The WINE project still had the code afterward. As for the developers, perhaps the WINE project wasn't appealing enough to hold on to its team.
Nice try twisting my words. Curious - did you even read what Mr. Hannum had to say about this problem of proprietary forks? I think the more relevant example isn't WINE but NetBSD. Wasabi Systems forked NetBSD and hired away good NetBSD people to work on their fork. Mr. Hannum, a NetBSD founder, said that did damage to NetBSD.
There are multiple BSD projects and they are going how they want them to be.
Apparently not, or we wouldn't have one of the three most prominent projects firing eight core developers after one of the founders decides to go public with his frustrations and analysis of why they have failed!
Sure, but that's not atributable to the GPL.
It absolutely is attributable to the GPL. The GPL creates a level playing field where no one party's contributions can be used unfairly against them. Why do you think that Linux, and GPL code in general, has such a huge level of corporate support, while BSD has virtually none?
you don't know much about linux, do you?
This is exactly what I mean about BSD zealots buring their heads in the sand. Wake up, it's 2006! Linux is faster, more portable and has more features than any BSD. Linux runs on everything from cell phones to supercomputers. Pretending that this is not true is asinine.
If portability, functionality and performance aren't big components of technical superiority, what do you suppose is?
Oh, please. It's a lot less obnoxious than your preaching of the GPL and griping about ATI and nVidia not releasing specs or source code for their drivers. They shouldn't have to release them any more than other companies should be allowed to steal GPL'ed code. (From what I've read, I believe even Linus agrees with that.) Linux wouldn't be a even fraction as popular as it is today if ATI and nVidia hadn't graced it with their "shitty binary drivers", and it's still not very popular among average users.
I'm griping about specs, not source code. There was a time that when you bought something, it came with full schematics. Nowadays the business world seems to want to lock that all away from the end user in the interest of chasing the almighty Dollar. A thriving rate of technical development (and indeed, even competition!) depends on open standards and open specs. When proprietary interests get mixed in beyond the point of healthy balance, the users are the ones who lose.
For some companies, BSD serves their proprietary interests extremely well. For other companies, it is a danger. It gives smaller companies a head-start and helps them compete against more well-established companies, which I do think is a good thing.
Are you saying this because Apple was able to use BSD in the development of a desktop operating system?
What BSD zealots seem to misunderstand is that the GPL doesn't prevent anyone from making money off that code, or using it to build other systems. It merely enforces a collaboration and an equal playing field.
If you think BSD has a monopoly on giving companies a leg up in developing new products, what do you think Novell is doing?
[stuff about X Windows and "3D mode"]
Doing things in 2d is dying off. Microsoft sees this, Apple sees this, X.Org sees this. The fact of the matter is that the cost of including 3d support is going down, and since the 2d stuff can be done with the 3d stuff, the 2d stuff is getting pushed off the chip. Sooner or later we'll have hardware where there is no 2d support at all.
Modern processors don't have a big "On/Off" switch for whole areas of functionality; rather, they can actually swing in and out of various states of activation depending on load. This means that your story about "3D mode", loud fans and power consumption is false. Desktops with minor 3d effects just don't place the kind of load on those chips that 3d games do.
Apple has contributed a lot to open source software. BSD has won in the arrangement.
What exactly has BSD won? Just recently, Apple decided to close up XNU. Granted, I'm now hearing that they have changed their mind again, but doesn't that seem like any possible benefit to BSD is totally at the whims of Apple?
The choice between BSD and GPL reflects what a developer wants. If they want others to help with their software and want rights to all derivatives of their software, they choose GPL. If they just want to share what they make, they choose BSD.
You imply that BSD has a monopoly on sharing. Ironically, the difference between the BSD license and the GPL license is all about sharing, and in exactly the opposite way that supporters of the BSD license love to imply.
The GPL gets torn down by such folks as if it is some kind of false freedom. In truth, the GPL license lets you use the GPL licensed works in any damn way you please; in fact, you don't even have to accept the GPL license to use GPL'ed software!
The difference between the BSD and GPL license, then, is what happens when you want to copy the software. GPL looks out for the actual _users_ of the software by ensuring that the software will always remain free. The BSD license, on the other had, allows proprietary forks that _hurt_ the users. Mr. Hannum even pointed this out when he talked about NetBSD developers getting hired away to work on a proprietary NetBSD fork! He sees this as a big problem, so do I, and so does Stallman, which is why the GPL is designed to prohibit individuals and corporations from taking the freedom away.
I don't think that GPL software will make it to the majority of users' desktops. It is just too hard to make profit from Desktop Linux. Unlike a server, support for a Desktop OS can't be worth enough to make enough money to develop the software, or it won't ever sell.
Good thing the free software properties of the GPL and copyleft that defend the GNU/Linux desktop mean that most of the components are the same exact components as running on all those servers, where paid support is plentiful!
Your big error is in starting with the assumption that there Must Be a business of selling desktop operating systems. Personally I think it is plainly obvious that free software will displace that entire business. That is not the goal of free software, but it will happen anyway.
Desktop users don't buy operating systems -- they buy computers.
...but you may not like it. The replacement is and will continue to be Linux, which is already more portable than NetBSD, has far greater mindshare, performance, scalability and functionality.
Good lord, the meme about X-Windows needing to be replaced is really obnoxious. I honestly thought that when Compiz, XGL and AIGLX startd to appear, fools parroting this tired meme would finally be put to rest.
X-Windows is in many ways archaic, but under the lead of the X.Org project there has been an astounding increase in the rate of development. The project has finally been modularized and the groundwork is in place for direct access to acceleration features. Honestly, the biggest thing holding back X-Windows from even faster modernization right now is the manufacturers of graphics hardware (NVIDIA and ATI) that are ridiculous enough to not even release programming specifications for their chips. Their "support" of the free operating systems is limited to shitty binary drivers, and so when the X-Windows and kernel communities want to introduce new APIs, they are largely at the whims of the moron companies that haven't gotten around to pulling their heads out of their asses yet.
If you believe that UNIX with X-Windows on top of it is not suitable for the average user, you should provide some facts to back up that opinion. Because as every day passes, I've seen all the arguments get displaced by proof of concept and running code.
Finally, what Apple did with OS X indicates just what is wrong with the BSD license. The coders and users that believe in the BSD license have been shown time and time again that the so-called benefits of the license are actually damaging to their projects. Charles Hannum from NetBSD recognized this recently when he talked about NetBSD's stagnation, and aptly characterized part of the problem as the BSD license that allowed companies to fork BSD and hire away all the important developers to work on their proprietary forks. Charles now says that he would have used the LGPL license if he were to do it again, which is exactly what the Wine project did after Transgaming and others ran off with their code and developers.
So this issue of licensing that you describe as making BSD the biggest threat to the proprietary interests is wrong. The BSD license's shortcomings in this area mean that BSD will continue to go nowhere fast. The reason that the BSD lawsuits were more scary was because the free BSDs actually had lineage leading back to the old proprietary (owned) code. The reason the SCO lawsuit is not scary, and rather actually hilarious, is because Linux was (a) developed in a vacuum and (b) is defended by the GPL.
The GPL is very important here, because it creates a safe haven for companies like IBM, SGI, Oracle, Red Hat, Novell, HP, Nortel and others to all cooperate on *one* core. When all of this engineering talent and financial power gets pooled into one project, that one project goes a long ways. And tossing its technical superiority totally aside, you're left with the actual *largest* threat to the proprietary interests - an entire cultural, economic, political and technical shift in thinking from proprietary development to Copyleft.
The BSD project and license followers have been operating with their heads in the sand for a very long time now. Even when the FOUNDER of one of the most significant free BSD efforts came out and said "We fucked up, and here's why," there were still a thousand BSD fans that chose to ignore the majority of the issues he raised, instead babbling on topics like "Theo is finally vindicated!". Given history, I don't expect this to change. There will always be BSD users with their heads buried in the sand, but their numbers are shrinking as they fail to see the train tracks being built directly in their path.
Slashdot Mirror
FreeBSD oopses when you 'hotplug' USB devices at the wrong time and thrashes your data if you lose power at the wrong time (oh, that's right, use SCSI), one of NetBSD's founders just came out and said the project is doomed, DragonflyBSD is an effort at a massive rewrite in early stages (certainly unsafe for production) and OpenBSD is driven by a raving loonie.
/real/ technical advantages, is more portable than NetBSD, performs better cross-spectrum than any of the BSDs, and it's all in one convenient package with tons of corporate backing!
By contrast, Linux has
Anyone who moves from a superior solution to an inferior one over a pointless licensing debate is nuts.
Thanks for your wonderful marketing efforts!
Anyone can implement the xdg standards. This is an API - a protocol - nothing more.
What makes me angry about this isn't that I won't be able to find movies online; hell, it's usually possible to get them before they're even available from Blockbuster. What's irritating is that I'm an honest customer of the MPAA. I have a huge shelf of DVDs. I'm a DVD collector. The first time I buy a DVD that has been engineered in such a way to not play, I'm going to return it and never buy a DVD again.
Note: This doesn't mean I'm going to stop watching movies. Do the fucking math, MPAA.
So what do you think the judge should have done in this case, given that the defendant gave the court de facto jurisdiction and then failed to make an appearance? If you fail to follow courtroom procedure and get censured for it, that's your own damn fault (in this case Spamhaus). Besides, if the judge does use e-mail, I'm sure the judge also knows what spam is.
But keep raging against the machine.
...except for the fact that Reiser 4 is a good deal faster than ZFS.
Thank you for that. First time I laughed reading this whole thread.
Oh, did you mean to say that Mr. Reiser's arrest proves his guilt then?
I don't see lots of people 'making excuses' or 'justifications', I see a lot of pissants cracking jokes, and I also smell some trolls.
So the real question is, WHY DON'T YOU SHOWER, SMELLY TROLL?
Yes, you should absolutely choose as many different platforms as possible; that way, you can keep yourself important as each platform fails in new, different and exciting ways and you scramble around trying to fix them.
This is ridiculous. This has nothing to do with back doors. This is literally saying "you can run arbitrary code in kernel mode by inserting a kernel module!" So what! If you're worried, disable kernel module support or use SELinux to tighten down who may load them even further!
Linux gives you choices!
As the first person who replied to this announcement in LKML, I will certify that this "weakness" is pretty silly. Here's what the claim is:
1. You must be root
2. You must be able to load an arbitrary kernel module
3. You write an arbitrary kernel module that calls a kernel function to install yourself as an "binfmt handler"
4. That kernel module is put on the _front_ of the list instead of the _end_
5. Every program that runs now ends up calling your "binfmt handler" first
Their solution:
1. Put it on the _end_ of the list instead of the _front_ when it registers itself, that way it only runs if the binfmt cannot be identified...
This is literally just as stupid as discovering that you can call fork() and exec() with an argv of "/bin/rm", "-rf", "*". Oh no, everyone must patch their systems! Seriously, anyone who can load an arbitrary kernel module could technically do _anything_, including replace the whole kernel image from the inside out!
It's not really thread ping pong that sucks. The operating system should provide reasonable soft affinity to keep that from sucking. It's really more about how many shared cache lines you have to worry about, because then you have a thread running on each processor that wants to manipulate the same cache line at the same time. That's when you really fall on your face.
Now, I'll admit to knowing nothing about BeOS. They might have been very clever. But many of the multithreading designs I've seen are sadly the kind of things that lose their scalability after a couple of CPUs.
Actually, such an architecture with careless multithreading can be a disaster if misused. When you have lots of threads running on one CPU, there isn't much penalty, especially if the OS is wise enough not to do anything that might flush the TLB in between thread-switching. All the necessary locks and whatnot will be in cache.
The problem with adding cores is that the operating system scheduler (naturally) is going to spread those threads out across all those cores or CPUs. At that point, you better damn well have broken your application down correctly, pipelining work and being careful not to depend too much on centralized locks, or else the resulting cache-line ping-pong is the only thing you are going to be doing with your chip.
To that end, putting every interdependent program component into a thread context of its own sounds like a disaster waiting to happen, because that's not how you make useful use of lots of cores.
I said scale and schedule usefully, not "run". Big, big difference. Last I heard, OS X Tiger only had 6 kernel locks. You expect that to run usefully on 80 cores? Anandtech even said "We definitely had a difficult time stressing 8 cores in the Mac Pro"...
This is hilarious, because if this goes out on the market there's not going to be many operating systems capable of scheduling on that many chips usefully. OS X can't do it, Windows can't do it, and nor can BSD. But Linux has been scheduling on systems with up to 1,024 processors already :)
Still wrong, as the Anonymous Coward is also pointing out.
If you ran into an endianness assumption, that is a bug, plain and simple. Among Linux's excellent portability layer is a set of macros to swap byte order how and when necessary (cpu_to_le32, cpu_to_be32, etc). If you find *any* architecture specific code that is not in either "include/asm-*/" or "arch/*", it is a bug and should be reported. And for the record, PCI drivers don't live under "arch/*".
All of these things are things you would know if you actually LOOKED at the code you so readily criticize. Linux is free and freely available. Get a copy from kernel.org and see for yourself.
Your post is full of 100% false FUD! Linux supports more architectures than NetBSD, and additionally, Linux drivers most certainly are *NOT* tied to one architecture. That is simply not true at all, and I say that as someone who has worked on the kernel before.
There is more to every story than you might think. If Apple is now pretending that their "delayed" release of x86 XNU was due to miscommunication or preparation, that's called "public relations" not "truth".
OK, perhaps so. I'm not a game developer, I've just assumed that the 3D guys would have adopted basic power management techniques by now. If they have not, it's not going to be very long before they do, because of the exact reasons you cite.
DragonFly BSD is a redesign and reimplementation of the FreeBSD kernel and userland libraries from the bottom up, with the main goal being for it to scale very well on multicore and multiprocessor systems.
Redesign and reimplementation seems to imply starting from scratch. This doesn't seem to be the case for DragonflyBSD.
So while FreeBSD, NetBSD and OpenBSD will still be working on getting their kernel sufficiently threaded for many years to come, DragonFly BSD will have had that task completed for a while.
DragonflyBSD has the development resources necessary to redesign and reimplement the FreeBSD kernel, *and* get their kernel "threaded" faster than the other BSD projects already working hard on that task?
Pardon me, but I don't think your description makes much sense, and it doesn't sound like you know anything about operating system scalability. In a monolithic kernel design like Linux, FreeBSD, NetBSD, OpenBSD or DragonflyBSD, "threads" are largely a user-space concept. Sure, you have kernel threads to run specialized tasks, but the bulk of the performance critical code runs "on top of" or "on behalf of" user tasks. This differs from a microkernel implementation where the kernel is really broken down into multiple threads that pass messages (even then, however, certain kernel functions like memory management and process scheduling must be centralized.)
In reality, the real effort of creating better scalability centers on implementation of finer-grained locking and faster data structures, so that the locks aren't as contended as they once were.
Reportedly, it has become better than Irix at many tasks, and is even beginning to rival Solaris. With Irix still trumping Linux in most cases, this goes to show how far ahead DragonFly BSD already is.
DragonflyBSD is interesting, but I don't think you should be making claims like this without providing verifiable data. Do you have any references?
Curious that you blame that hardware companies and not X. Why should hardware companies feel obligated to support GPLed software?
They shouldn't have to; rather, they should just go back to releasing specifications to their customers like they used to. I think there are plenty of people in the BSD community that would agree with me on this, especially Theo.
Documentation of that opinion appears regularly and it take far more than "proof of concept" to make a platform "suitable for the average user".
You've made an attempt to totally dodge my question.
Acutally it proves what's right with it. Apple used BSD code precisely in the manner that BSD people would like.
That does nothing to address my point, which is that forks of this nature are bad. Whether or not the BSD developers themselves intended to allow that is a different issue.
They didn't run off with the code. The WINE project still had the code afterward. As for the developers, perhaps the WINE project wasn't appealing enough to hold on to its team.
Nice try twisting my words. Curious - did you even read what Mr. Hannum had to say about this problem of proprietary forks? I think the more relevant example isn't WINE but NetBSD. Wasabi Systems forked NetBSD and hired away good NetBSD people to work on their fork. Mr. Hannum, a NetBSD founder, said that did damage to NetBSD.
There are multiple BSD projects and they are going how they want them to be.
Apparently not, or we wouldn't have one of the three most prominent projects firing eight core developers after one of the founders decides to go public with his frustrations and analysis of why they have failed!
Sure, but that's not atributable to the GPL.
It absolutely is attributable to the GPL. The GPL creates a level playing field where no one party's contributions can be used unfairly against them. Why do you think that Linux, and GPL code in general, has such a huge level of corporate support, while BSD has virtually none?
you don't know much about linux, do you?
This is exactly what I mean about BSD zealots buring their heads in the sand. Wake up, it's 2006! Linux is faster, more portable and has more features than any BSD. Linux runs on everything from cell phones to supercomputers. Pretending that this is not true is asinine.
If portability, functionality and performance aren't big components of technical superiority, what do you suppose is?
Oh, please. It's a lot less obnoxious than your preaching of the GPL and griping about ATI and nVidia not releasing specs or source code for their drivers. They shouldn't have to release them any more than other companies should be allowed to steal GPL'ed code. (From what I've read, I believe even Linus agrees with that.) Linux wouldn't be a even fraction as popular as it is today if ATI and nVidia hadn't graced it with their "shitty binary drivers", and it's still not very popular among average users.
I'm griping about specs, not source code. There was a time that when you bought something, it came with full schematics. Nowadays the business world seems to want to lock that all away from the end user in the interest of chasing the almighty Dollar. A thriving rate of technical development (and indeed, even competition!) depends on open standards and open specs. When proprietary interests get mixed in beyond the point of healthy balance, the users are the ones who lose.
For some companies, BSD serves their proprietary interests extremely well. For other companies, it is a danger. It gives smaller companies a head-start and helps them compete against more well-established companies, which I do think is a good thing.
Are you saying this because Apple was able to use BSD in the development of a desktop operating system?
What BSD zealots seem to misunderstand is that the GPL doesn't prevent anyone from making money off that code, or using it to build other systems. It merely enforces a collaboration and an equal playing field.
If you think BSD has a monopoly on giving companies a leg up in developing new products, what do you think Novell is doing?
[stuff about X Windows and "3D mode"]
Doing things in 2d is dying off. Microsoft sees this, Apple sees this, X.Org sees this. The fact of the matter is that the cost of including 3d support is going down, and since the 2d stuff can be done with the 3d stuff, the 2d stuff is getting pushed off the chip. Sooner or later we'll have hardware where there is no 2d support at all.
Modern processors don't have a big "On/Off" switch for whole areas of functionality; rather, they can actually swing in and out of various states of activation depending on load. This means that your story about "3D mode", loud fans and power consumption is false. Desktops with minor 3d effects just don't place the kind of load on those chips that 3d games do.
Apple has contributed a lot to open source software. BSD has won in the arrangement.
What exactly has BSD won? Just recently, Apple decided to close up XNU. Granted, I'm now hearing that they have changed their mind again, but doesn't that seem like any possible benefit to BSD is totally at the whims of Apple?
The choice between BSD and GPL reflects what a developer wants. If they want others to help with their software and want rights to all derivatives of their software, they choose GPL. If they just want to share what they make, they choose BSD.
You imply that BSD has a monopoly on sharing. Ironically, the difference between the BSD license and the GPL license is all about sharing, and in exactly the opposite way that supporters of the BSD license love to imply.
The GPL gets torn down by such folks as if it is some kind of false freedom. In truth, the GPL license lets you use the GPL licensed works in any damn way you please; in fact, you don't even have to accept the GPL license to use GPL'ed software!
The difference between the BSD and GPL license, then, is what happens when you want to copy the software. GPL looks out for the actual _users_ of the software by ensuring that the software will always remain free. The BSD license, on the other had, allows proprietary forks that _hurt_ the users. Mr. Hannum even pointed this out when he talked about NetBSD developers getting hired away to work on a proprietary NetBSD fork! He sees this as a big problem, so do I, and so does Stallman, which is why the GPL is designed to prohibit individuals and corporations from taking the freedom away.
I don't think that GPL software will make it to the majority of users' desktops. It is just too hard to make profit from Desktop Linux. Unlike a server, support for a Desktop OS can't be worth enough to make enough money to develop the software, or it won't ever sell.
Good thing the free software properties of the GPL and copyleft that defend the GNU/Linux desktop mean that most of the components are the same exact components as running on all those servers, where paid support is plentiful!
Your big error is in starting with the assumption that there Must Be a business of selling desktop operating systems. Personally I think it is plainly obvious that free software will displace that entire business. That is not the goal of free software, but it will happen anyway.
Desktop users don't buy operating systems -- they buy computers.
...but you may not like it. The replacement is and will continue to be Linux, which is already more portable than NetBSD, has far greater mindshare, performance, scalability and functionality.
Good lord, the meme about X-Windows needing to be replaced is really obnoxious. I honestly thought that when Compiz, XGL and AIGLX startd to appear, fools parroting this tired meme would finally be put to rest.
X-Windows is in many ways archaic, but under the lead of the X.Org project there has been an astounding increase in the rate of development. The project has finally been modularized and the groundwork is in place for direct access to acceleration features. Honestly, the biggest thing holding back X-Windows from even faster modernization right now is the manufacturers of graphics hardware (NVIDIA and ATI) that are ridiculous enough to not even release programming specifications for their chips. Their "support" of the free operating systems is limited to shitty binary drivers, and so when the X-Windows and kernel communities want to introduce new APIs, they are largely at the whims of the moron companies that haven't gotten around to pulling their heads out of their asses yet.
If you believe that UNIX with X-Windows on top of it is not suitable for the average user, you should provide some facts to back up that opinion. Because as every day passes, I've seen all the arguments get displaced by proof of concept and running code.
Finally, what Apple did with OS X indicates just what is wrong with the BSD license. The coders and users that believe in the BSD license have been shown time and time again that the so-called benefits of the license are actually damaging to their projects. Charles Hannum from NetBSD recognized this recently when he talked about NetBSD's stagnation, and aptly characterized part of the problem as the BSD license that allowed companies to fork BSD and hire away all the important developers to work on their proprietary forks. Charles now says that he would have used the LGPL license if he were to do it again, which is exactly what the Wine project did after Transgaming and others ran off with their code and developers.
So this issue of licensing that you describe as making BSD the biggest threat to the proprietary interests is wrong. The BSD license's shortcomings in this area mean that BSD will continue to go nowhere fast. The reason that the BSD lawsuits were more scary was because the free BSDs actually had lineage leading back to the old proprietary (owned) code. The reason the SCO lawsuit is not scary, and rather actually hilarious, is because Linux was (a) developed in a vacuum and (b) is defended by the GPL.
The GPL is very important here, because it creates a safe haven for companies like IBM, SGI, Oracle, Red Hat, Novell, HP, Nortel and others to all cooperate on *one* core. When all of this engineering talent and financial power gets pooled into one project, that one project goes a long ways. And tossing its technical superiority totally aside, you're left with the actual *largest* threat to the proprietary interests - an entire cultural, economic, political and technical shift in thinking from proprietary development to Copyleft.
The BSD project and license followers have been operating with their heads in the sand for a very long time now. Even when the FOUNDER of one of the most significant free BSD efforts came out and said "We fucked up, and here's why," there were still a thousand BSD fans that chose to ignore the majority of the issues he raised, instead babbling on topics like "Theo is finally vindicated!". Given history, I don't expect this to change. There will always be BSD users with their heads buried in the sand, but their numbers are shrinking as they fail to see the train tracks being built directly in their path.