What if I write a program that uses gtk+ and decide to sell it to a corporation or my employer?
That's fine, gtk+ is LGPL so you can do that... much like libc.
Maybe you were thinking, "what if I take source for random app. X that's GPL'd... and want to sell the improvments". At which point I'd retort with "what if I want to take the source for internet explorer and sell the improvments"... same difference, the person who wrote the code gets to decide... if you don't like it don't use it.
Finally, I think the criticism of "Jedi" as a religion is that ultimately it is based on a movie.
But that was made from a script written on paper, like, you know... the bible. Or to quote someone else:
I contend that we are both atheists. I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours. ~Stephen Roberts
Look, get out. Unix is popular, but so is Windows on the server. Really, really popular. [...] if you look around at Netcraft, you'll see that 30-40% of sites use IIS
That depends, if you look at the front end web servers and the non-critical DB apps.... sure run whatever is the easy short term solution. So both Windows and Linux look good in terms of unit volume. But look behind those, and it's all s390s and "Traditional Unix" on the backend... no sane person is running their main DB accounting servers on anything else (excepting, possibly, Red Hat and Microsoft).
Sure, this could just be my opinion... but I work for a Linux company, and I'm not saying Linux has taken over in this space... and as a personal observation every single large company I've walked into has had a couple of "large" (think 64 CPUs) Unix boxes that ran whatever was the "core" part of their business, mainly because it's been that way for the last 10 years and noone is stupid enough to want to change anything.
Copyrights do NOT apply to programs, Copyrights apply to the source code that a compiler uses to generate the program
Oh, really? So there's nothing stopping me from giving all my friends a copy of the binaries then?
Alas. back in reality, you are wrong. It's also sad then even if the copyright ever expires on windows-3.1, noone will actually have the source code anyway... so it's more of a trade secret than anything.
it feels like a protocol violation to me and I am not sure if what it buys you outweighs
The client side can't see a difference (everything is SYN+ACKed, just that the info. isn't passed onto the user space app.), and the server side obviously knows it's happening so shouldn't be doing it on a protocol where the server is expected to respond with a banner first.
On the other hand, it's probably not as big of a win as TCP_CORK and it's trivial to work around if it doesn't exist (you just don't call setsockopt()).
TCP_CORK support integrated into Nevada build 12 so should be in Solaris Express and probably a Solaris 10 update.
Very cool, while I'm on a roll... what about TCP_DEFER_ACCEPT too ?:)
Was the client not using Nagle?
The client was using Nagle, in fact they hadn't even heard of TCP_NODELAY when I told them they could work around their problem on Linux (assuming a perfect network) in the short term by enabling that (thus disabling Nagle).
I only heard about FireEngine today, I'm somewhat surprised that Sun haven't marketed it. The documentation I've seen for FireEngine suggests that they've basically rewritten large bits of it, esp. with regard to BSD APIs, nodoubt to catch up with OSS. I haven't seen any benchmarks yet though, and given (as I said before) S10 doesn't support TCP_CORK/TCP_DEFER_ACCEPT I have a hard time believing it's as good.
And your write() message annecdote just shows how little you know about tcp.
You didn't understand what I wrote then. I have advised a client who have had "working" Solaris code that called write() where the data was in the 1-9 bytes range and the clients abortted if the read() didn't get all or nothing. This apparently "worked" in Solaris because the TCP stack didn't merge data into packets optimally, instead it would leave a few bytes of the end of the current packet so it could put the "whole message" into a TCP packet.
This was default behaviour, and their request was that Linux also "honour the message boundries". I had to explain to them that the Solaris was considered a bug, and they should just fix their client applications.
Obviously hacks in the TCP stack like this don't come for free, so I'd be interested if the new "super" FireEngine stack still does this.
So, tell me exactly which features are in Linux/FreeBSD/etc that I don't have or can't get for Solaris?
The obvious point is that the Solaris network stack isn't as good as either, one of the problems being that it makes a lot of tradeoffs for it's traditional large customers. Sure, they might well appreciate their specific hack (like a recent Solris to Linux user I spoke to who was unhappy because Solaris "respected" the write() message bounderies down to the TCP packet level, and Linux didn't)... but they also like things that go fast in the general case.
Solaris carries around a lot of baggage like, STREAMS and doors. Not having this kind of crap is a feature, and also helps the above point of doing the right thing in the cases people care about -- I've seen benchmarks that on Uni-proccessor machines Linux process creation is faster than Solaris thread creation.
From a user POV, Solaris isn't what the majority are using... and the userspace is crap compared to Linux. Yes, you can manually install more or less a complete Linux userspace to get the usable tools... but, as you said, why wouldn't you just go with the one that works by default?
From a managemant POV, Linux can be got, as the default OS, from multiple HW vendors and you can choose from multiple software vendors who've been around for a significant amount of time. There are also thriving "communities" around Linux so that even if your vendors dies, you are pretty much guanteed not to be completely screwed. Solaris has Sun.
From a developer POV, then off the top of my head you have TCP_CORK, TCP_DEFER_ACCEPT, mount binds (and namespaces) and SELinux (trusted Solaris doesn't count, as that still isn't available as source... and AIUI has no recent release of any kind, and noone is using it)... and of course you have the users and all the other developers. Oh, yeh, and you have years of open communication and the ability to participate in the direction of the OS... which if you're lucky you might have most of the former, and half the later in Solaris "any day now".
If you think Sun's OSS strategy is to get joe hacker to run his OS, of course you're going to be disappointed, because you just don't get it yourself.
Ahh I see Solaris isn't there for the "joe hacker", just for the data center... funny thing is though, the people working in the data center's aren't grown in huge vats at MIT. And of course, I am kind of wondering, if "joe hacker" doesn't want it who the hell is going to write the code for it? Or are you still under the impression that in the battle Sun vs. the rest of the world they are, or will somehow start, winning?
To be fair, I'm not sure that some of Sun doesn't want Solaris to be a "joe hacker" OS... what I do know is that if it isn't, it'll fail horribly. And unless they succeed spectacularly, I'll hardly have to care at all.
You seem to be under the impression that Solaris contains all the features that are found in Linux/FreeBSD/etc. This is not true, in fact your arguement is the main one you'd use to stay with one of the other 5 free unixen. Solaris has very little to offer, esp. if you are a normal person and DTrace means nothing to you.
Daniel, you mean it is better for you... right? I can understand that, and while there are a few things I've liked about using the FreeBSD or gentoo "system" I wouldn't think say it's better for most people... you being far from most people.
Solaris has fault tollerance features that aren't found in Linux. Solaris has support for isolating failing hardware and hotswaping everything includeing cpu boards. Big IBM, and SGI/Cray iron support this as well.
And what can you run on an IBM zSeries, oh yeh... Linux.
His approach was technically superior to the other distros in its fundamental approach, and funding could have cured any detail problems. It was the right approach.
Right, gentoo was better and all the people that thought dumping real package management in favor of "make" was a huge step back are obviously just jelous.
I can't imagine why anyone listen to them.
Probably like reiserfs, it's just plain better than ext3... hell noone really needs stability and recovery anyway. It's just amazing that people are listening to those jelous naysayers.
Re:Hyperthreading is not easier than multicore.
on
AMD Quad Cores, Oh My
·
· Score: 1
Wrong. The communication latency with SMT and CMPs is much much lower than that of SMPs
Yes, you are. If you care that much about communicating between threads you've already lost. Many good multi-tasked applications run communicating as little as possible (all communication is a serialization point), here multiple cores means you can run two real tasks, while "hyperthreading" means you can run two tasks at a little over 50%.
Consider Apache-httpd, it gets basically nothing from "hyperthreading" but goes almost twice as fast (mostly limited by OS level scheduling) with multiple cores.
I'm curious: how exactly would you suggest, in a purely capitalist system, that the creator of a thing which can be copied (and thus re-sold without any money going to the creator) protect his product?
I'm curious: how exactly would you suggest, in the world as of today, I do interstellar travel and live on another planet? You see I desperatly need to do this to make money, even though it's obvious to everyone else that it can't be done, much like your problem... I promise to try very hard to solve your problem when you send me the answer to mine, thanks.
Overall the arguement is mostly bogus. For example many linux developers have trouble writing code that even compiles under any of the *bsds. That is just sloppy coding.
Here's a better idea, why don't the people who want it to run on *BSD... do the porting.
If everyone got in the habbit of at least writing code that doesn't use system specific includes (linux developers seem the worst at this) and compiled with gcc -strict -Wall or something similar it wouldn't be much of any issue.
If I wanted none of the advantages of Linux, I'd have installed FreeBSD in the first place... but given that I do kind of like TCP_CORK, prctl(), TCP_DEFERR_ACCEPT, binding mounts, etc. and know that -strict often does the wrong thing without -ansi (and good luck using that). And of course I just remembered I don't work for you. Feel free to start paying me if you want me to support your legacy OS, or you could just pick up an editor and send patches instead of insults and/. crack infested rants.
The main program should not care whether it is using BSD or Linux, should not care if you are calling over IPv4, IPv6, IPX or Streams! If it does, it is a flaw in the design.
You are on crack. For instance, poll() isn't everywhere, dito TCP_DEFER_ACCEPT/TCP_CORK/LFS/posix_fadvise/bind mounts/socket filters, sendfile() is not only not everywhere but was implemented differently (and worse) on *BSD. As for sockets you need to know what you are dealing with if you have ACLs you need to specifically parse IPv4/IPv6 etc.... also if you are calling connect() in a non-blocking model you can't just rely on the blocking getnameinfo(), so you again have to do everything yourself.
Sure, I don't agree with all of Ulrich's comments... but I'm certainly not going to rewrite all my code so it's portable to win32, or even SCO Unix from 10 years ago.
I could go on for hours and hours with the flaws of unions and liberal philosophies, but it's really not worth the effort. Let me just say that they both had a place and a time when they were useful and needed, but that time has passed.
Wow... "liberal philosophies" are no longer needed. If only someone had sent me an email. I assume your point was that unions aren't "needed" anymore, but yet I also assume you'd think that large multi-national companies are a wonderful thing?
If not, they yeh I'll agree we'd probably be better off without either large companies or unions... but we'd also be better off if we could fly like Peter Pan, and have about as much chance.
Linux is what Linus Torvalds makes, and that is available on kernel.org.
That is one meaning of the word, if you feel that is the only meaning you are a moron. The other obvious meaning used is that Linux is a distribution using a kernel based on the "Linux kernel". In fact when talking about "disk dump" this is the only sane meaning, because it assumes an entire OS... not just a kernel.
RedHat is not a synonym for Linux. RedHat is a commercial company that uses Linux, RedHat does not control Linux, RedHat does not own Linux. Linux and RedHat are not the same thing.
That's Red Hat btw.... you should learn to spell companies you are trolling
But I'll mostly agree with the above, Linux being a generic term.
If RedHat does something, that doesn't mean Linux does it. What is so hard to understand about that?
So you are arguing that there are no "Linux distributions" and nothing is ever "available in Linux" until it is shipped in the vanilla kernel.org Linus Linux kernel. That's fine, it's a worthless definition and no sane person will understand you but sure... you are free to argue that Linux doesn't have an installer, support for http/smtp, etc.
If I make a Linux program that burps when then kernel oopses or crashes, does that then mean that it can be said that "Linux" burps when it crashes. No it doesn't, and since RedHat is not the same thing as Linux, neither does it dump to disk on crash.
So in your world there aren't any "Linux" distributions, because noone ships exactly what is on kernel.org? It's hard to say if you're just trolling, or are genuinely confused.
No Red Hat isn't the only form of Linux... but it's sure as hell a popular distribution. So saying "Linux doesn't do XYZ", when in fact Red Hat ships and supports a Linux distribution that in fact does do XYZ is at best wrong, if not purposefully misleading.
I'm not saying that Linux doesn't have a review process, but it seems to be more focused on "does it (mostly) work?" rather than "does it work correctly in all situations AND is it easy to maintain?"
I think you are somewhat confused, maybe blinded is a better term.
Firstly it depends on which part of the kernel you are talking about. I would certainly expect drivers, or new features to have a development model along those lines... and dito in FreeBSD, AFAICS. However the review process for core network stack, VM, scheduler, etc. changes is significant. Also the Linux model has basically always worked in a two step fashion, with "upstream" Linux being somewhat loser and "distributions" being much more conservative towards change.
FreeBSD just accepts the slower development cycle of their choice.
This is the traditional PR, but FreeBSD 5 looks like Linux development IMO... indeed the whole lets have huge amounts of complexity due to possible advantages of KSEs, is something the Linux people rejected as too expensive (in terms of bugs and maintenance).
Then there's things like TCP_CORK/sendfile on Linux (beautiful complementary interfaces)... and the hack job that is FreeBSD sendfile, which was implemented only a couple of weeks after the Linux version, after they discussed the Linux API and they still made something incompatible and worse.
That's not saying there aren't bits of FreeBSD-4.x that seem nicer than the current main distributions of Linux bits, but the whole "Linux is fast development and poor quality" and "FreeBSD is slow development and good quality" is getting old... and Occam's razor suggests that maybe slower development has more to do with having significantly less developers.
Rather ironically the lie to the OSS is always better is provided by the recent Bitkeeper kerfuffle. Linus choose Bitkeeper because for him it was the best tool for the job
And now he can't legally use it, so it's not very useful now is it? In the same way building your house out of twings in the middle of summer might be "easier" and you could argue it's "better"... but come winter, your opinion might change somewhat. But, yes, without the trolling you can say that throwing money at a problem tends to provide a usable solution faster and proprietary software tends to be able to aquire money faster, in the short term at least. But I would certainly bet on the non-proprietary solution in the long term, in just the same way I'd bet on peer reviewed crypto rather than whatever company X wrote with random coder Y.
On the specific point however I'd disagree, a lot of people were forced to use bitkeeper to get a current snapshot of the tree... here rsync would have almost certainly been the best tool for the job, but nothing like that was ever offered "because just using bk was good enough". Also in many people's opinion arch has been very close to usable for over a year... but there was no desire on Linus's part to move to it "because bk was good enough".
The entire episode seems much less about technical quality and more like two people who knew each other pretty well and one offered the other free use of the proprietary code his company made, and free resources to tweak it to his liking.
The problem is that the quality of the code again depends upon the quality of the individual writing it. Good programmer just naturally write better code than poor programmers. But to get *really* good code, you must go the way of the FreeBSD project: i.e. Require code reviews before check-in.
And you think code reviews don't happen in Linux, why now? And you think FreeBSD gets everything correct, always has good design adn good implementation, why now?
But ignoring the stupid FreeBSD troll, I'd agree that good programers are often much better than poor ones. However the problem with proprietary code is that you have much less insight into who is good and who isn't... and you have no ability to change anything.
Slashdot Mirror
That's fine, gtk+ is LGPL so you can do that ... much like libc.
Maybe you were thinking, "what if I take source for random app. X that's GPL'd ... and want to sell the improvments". At which point I'd retort with "what if I want to take the source for internet explorer and sell the improvments" ... same difference, the person who wrote the code gets to decide ... if you don't like it don't use it.
But that was made from a script written on paper, like, you know ... the bible. Or to quote someone else:
That depends, if you look at the front end web servers and the non-critical DB apps. ... sure run whatever is the easy short term solution. So both Windows and Linux look good in terms of unit volume. But look behind those, and it's all s390s and "Traditional Unix" on the backend ... no sane person is running their main DB accounting servers on anything else (excepting, possibly, Red Hat and Microsoft).
Sure, this could just be my opinion ... but I work for a Linux company, and I'm not saying Linux has taken over in this space ... and as a personal observation every single large company I've walked into has had a couple of "large" (think 64 CPUs) Unix boxes that ran whatever was the "core" part of their business, mainly because it's been that way for the last 10 years and noone is stupid enough to want to change anything.
Oh, really? So there's nothing stopping me from giving all my friends a copy of the binaries then?
Alas. back in reality, you are wrong. It's also sad then even if the copyright ever expires on windows-3.1, noone will actually have the source code anyway ... so it's more of a trade secret than anything.
The client side can't see a difference (everything is SYN+ACKed, just that the info. isn't passed onto the user space app.), and the server side obviously knows it's happening so shouldn't be doing it on a protocol where the server is expected to respond with a banner first.
On the other hand, it's probably not as big of a win as TCP_CORK and it's trivial to work around if it doesn't exist (you just don't call setsockopt()).
Very cool, while I'm on a roll ... what about TCP_DEFER_ACCEPT too ?:)
The client was using Nagle, in fact they hadn't even heard of TCP_NODELAY when I told them they could work around their problem on Linux (assuming a perfect network) in the short term by enabling that (thus disabling Nagle).
I only heard about FireEngine today, I'm somewhat surprised that Sun haven't marketed it. The documentation I've seen for FireEngine suggests that they've basically rewritten large bits of it, esp. with regard to BSD APIs, nodoubt to catch up with OSS. I haven't seen any benchmarks yet though, and given (as I said before) S10 doesn't support TCP_CORK/TCP_DEFER_ACCEPT I have a hard time believing it's as good.
You didn't understand what I wrote then. I have advised a client who have had "working" Solaris code that called write() where the data was in the 1-9 bytes range and the clients abortted if the read() didn't get all or nothing. This apparently "worked" in Solaris because the TCP stack didn't merge data into packets optimally, instead it would leave a few bytes of the end of the current packet so it could put the "whole message" into a TCP packet.
This was default behaviour, and their request was that Linux also "honour the message boundries". I had to explain to them that the Solaris was considered a bug, and they should just fix their client applications.
Obviously hacks in the TCP stack like this don't come for free, so I'd be interested if the new "super" FireEngine stack still does this.
From http://www.redhat.com/software/subscriptions.html ...
The obvious point is that the Solaris network stack isn't as good as either, one of the problems being that it makes a lot of tradeoffs for it's traditional large customers. Sure, they might well appreciate their specific hack (like a recent Solris to Linux user I spoke to who was unhappy because Solaris "respected" the write() message bounderies down to the TCP packet level, and Linux didn't) ... but they also like things that go fast in the general case.
Solaris carries around a lot of baggage like, STREAMS and doors. Not having this kind of crap is a feature, and also helps the above point of doing the right thing in the cases people care about -- I've seen benchmarks that on Uni-proccessor machines Linux process creation is faster than Solaris thread creation.
From a user POV, Solaris isn't what the majority are using ... and the userspace is crap compared to Linux. Yes, you can manually install more or less a complete Linux userspace to get the usable tools ... but, as you said, why wouldn't you just go with the one that works by default?
From a managemant POV, Linux can be got, as the default OS, from multiple HW vendors and you can choose from multiple software vendors who've been around for a significant amount of time. There are also thriving "communities" around Linux so that even if your vendors dies, you are pretty much guanteed not to be completely screwed. Solaris has Sun.
From a developer POV, then off the top of my head you have TCP_CORK, TCP_DEFER_ACCEPT, mount binds (and namespaces) and SELinux (trusted Solaris doesn't count, as that still isn't available as source ... and AIUI has no recent release of any kind, and noone is using it) ... and of course you have the users and all the other developers. Oh, yeh, and you have years of open communication and the ability to participate in the direction of the OS ... which if you're lucky you might have most of the former, and half the later in Solaris "any day now".
Ahh I see Solaris isn't there for the "joe hacker", just for the data center ... funny thing is though, the people working in the data center's aren't grown in huge vats at MIT. And of course, I am kind of wondering, if "joe hacker" doesn't want it who the hell is going to write the code for it? Or are you still under the impression that in the battle Sun vs. the rest of the world they are, or will somehow start, winning?
To be fair, I'm not sure that some of Sun doesn't want Solaris to be a "joe hacker" OS ... what I do know is that if it isn't, it'll fail horribly. And unless they succeed spectacularly, I'll hardly have to care at all.
You seem to be under the impression that Solaris contains all the features that are found in Linux/FreeBSD/etc. This is not true, in fact your arguement is the main one you'd use to stay with one of the other 5 free unixen. Solaris has very little to offer, esp. if you are a normal person and DTrace means nothing to you.
Daniel, you mean it is better for you ... right? I can understand that, and while there are a few things I've liked about using the FreeBSD or gentoo "system" I wouldn't think say it's better for most people ... you being far from most people.
And what can you run on an IBM zSeries, oh yeh ... Linux.
Right, gentoo was better and all the people that thought dumping real package management in favor of "make" was a huge step back are obviously just jelous.
I can't imagine why anyone listen to them.
Probably like reiserfs, it's just plain better than ext3 ... hell noone really needs stability and recovery anyway. It's just amazing that people are listening to those jelous naysayers.
Yes, you are. If you care that much about communicating between threads you've already lost. Many good multi-tasked applications run communicating as little as possible (all communication is a serialization point), here multiple cores means you can run two real tasks, while "hyperthreading" means you can run two tasks at a little over 50%.
Consider Apache-httpd, it gets basically nothing from "hyperthreading" but goes almost twice as fast (mostly limited by OS level scheduling) with multiple cores.
Now let's be fair, anyone running a desktop on debian stable is enough of a fan boy that they probably helped produce the release notes.
I'm curious: how exactly would you suggest, in the world as of today, I do interstellar travel and live on another planet? You see I desperatly need to do this to make money, even though it's obvious to everyone else that it can't be done, much like your problem ... I promise to try very hard to solve your problem when you send me the answer to mine, thanks.
Here's a better idea, why don't the people who want it to run on *BSD ... do the porting.
If I wanted none of the advantages of Linux, I'd have installed FreeBSD in the first place ... but given that I do kind of like TCP_CORK, prctl(), TCP_DEFERR_ACCEPT, binding mounts, etc. and know that -strict often does the wrong thing without -ansi (and good luck using that). And of course I just remembered I don't work for you. Feel free to start paying me if you want me to support your legacy OS, or you could just pick up an editor and send patches instead of insults and /. crack infested rants.
You are on crack. For instance, poll() isn't everywhere, dito TCP_DEFER_ACCEPT/TCP_CORK/LFS/posix_fadvise/bind mounts/socket filters, sendfile() is not only not everywhere but was implemented differently (and worse) on *BSD. As for sockets you need to know what you are dealing with if you have ACLs you need to specifically parse IPv4/IPv6 etc. ... also if you are calling connect() in a non-blocking model you can't just rely on the blocking getnameinfo(), so you again have to do everything yourself.
Sure, I don't agree with all of Ulrich's comments ... but I'm certainly not going to rewrite all my code so it's portable to win32, or even SCO Unix from 10 years ago.
Wow ... "liberal philosophies" are no longer needed. If only someone had sent me an email. I assume your point was that unions aren't "needed" anymore, but yet I also assume you'd think that large multi-national companies are a wonderful thing?
If not, they yeh I'll agree we'd probably be better off without either large companies or unions ... but we'd also be better off if we could fly like Peter Pan, and have about as much chance.
That is one meaning of the word, if you feel that is the only meaning you are a moron. The other obvious meaning used is that Linux is a distribution using a kernel based on the "Linux kernel". In fact when talking about "disk dump" this is the only sane meaning, because it assumes an entire OS ... not just a kernel.
That's Red Hat btw. ... you should learn to spell companies you are trolling
But I'll mostly agree with the above, Linux being a generic term.
So you are arguing that there are no "Linux distributions" and nothing is ever "available in Linux" until it is shipped in the vanilla kernel.org Linus Linux kernel. That's fine, it's a worthless definition and no sane person will understand you but sure ... you are free to argue that Linux doesn't have an installer, support for http/smtp, etc.
So in your world there aren't any "Linux" distributions, because noone ships exactly what is on kernel.org? It's hard to say if you're just trolling, or are genuinely confused.
No Red Hat isn't the only form of Linux ... but it's sure as hell a popular distribution. So saying "Linux doesn't do XYZ", when in fact Red Hat ships and supports a Linux distribution that in fact does do XYZ is at best wrong, if not purposefully misleading.
Yes, yes it does: http://people.redhat.com/anderson/crash_whitepaper /
I think you are somewhat confused, maybe blinded is a better term.
Firstly it depends on which part of the kernel you are talking about. I would certainly expect drivers, or new features to have a development model along those lines ... and dito in FreeBSD, AFAICS. However the review process for core network stack, VM, scheduler, etc. changes is significant. Also the Linux model has basically always worked in a two step fashion, with "upstream" Linux being somewhat loser and "distributions" being much more conservative towards change.
This is the traditional PR, but FreeBSD 5 looks like Linux development IMO ... indeed the whole lets have huge amounts of complexity due to possible advantages of KSEs, is something the Linux people rejected as too expensive (in terms of bugs and maintenance).
Then there's things like TCP_CORK/sendfile on Linux (beautiful complementary interfaces) ... and the hack job that is FreeBSD sendfile, which was implemented only a couple of weeks after the Linux version, after they discussed the Linux API and they still made something incompatible and worse.
That's not saying there aren't bits of FreeBSD-4.x that seem nicer than the current main distributions of Linux bits, but the whole "Linux is fast development and poor quality" and "FreeBSD is slow development and good quality" is getting old ... and Occam's razor suggests that maybe slower development has more to do with having significantly less developers.
And now he can't legally use it, so it's not very useful now is it? In the same way building your house out of twings in the middle of summer might be "easier" and you could argue it's "better" ... but come winter, your opinion might change somewhat. But, yes, without the trolling you can say that throwing money at a problem tends to provide a usable solution faster and proprietary software tends to be able to aquire money faster, in the short term at least. But I would certainly bet on the non-proprietary solution in the long term, in just the same way I'd bet on peer reviewed crypto rather than whatever company X wrote with random coder Y.
On the specific point however I'd disagree, a lot of people were forced to use bitkeeper to get a current snapshot of the tree ... here rsync would have almost certainly been the best tool for the job, but nothing like that was ever offered "because just using bk was good enough". Also in many people's opinion arch has been very close to usable for over a year ... but there was no desire on Linus's part to move to it "because bk was good enough".
The entire episode seems much less about technical quality and more like two people who knew each other pretty well and one offered the other free use of the proprietary code his company made, and free resources to tweak it to his liking.
And you think code reviews don't happen in Linux, why now? And you think FreeBSD gets everything correct, always has good design adn good implementation, why now?
But ignoring the stupid FreeBSD troll, I'd agree that good programers are often much better than poor ones. However the problem with proprietary code is that you have much less insight into who is good and who isn't ... and you have no ability to change anything.