Slashdot Mirror
Why Was Linux the Kernel That Succeeded?
jones_supa writes: "One of the most puzzling questions about the history of free and open source software is this: Why did Linux succeed so spectacularly, whereas similar attempts to build a free or open source, Unix-like operating system kernel met with considerably less success?" Christopher Tozzi has rounded up some theories, focusing specifically on kernels, not complete operating systems. These theories take a detailed look at the decentralized development structure, pragmatic approach to things, and the rich developer community, all of which worked in favor of Linux.
Amazed that neither the GPL nor the legal uncertainties surrounding BSD at the time (hey, remember those days!) were really focused on, but meh. I think like everything else that became wildly popular in spite of plenty of seemingly equivalent or better alternatives, it just came down to dumb luck and momentum.
Somehow Linux got the ball rolling, people gathered around it, it gained steam, and here we are.
FTFY
| wonder what finally made the c-levels unafraid of linux?
time and nobody important being sued
When I was a kid, i read a book called Stone Soup. It was about these guys that wanted to eat, had nothing but a pot. They put in some stones... called it stone soup.
Eventually people got curious, and added things.. the soup became real. Going from water and rocks, to where real ingredients went in, and the stones just fell away. A seed, but then dropped when something real came.
I always thought of Linus as a guy who managed the Stone Soup well. It wasn't specially good in .01 version. But he made people want to add to it. The GPL helped some. Linus chose that license, not as a "hey Im a zealot and you need to give me everything you write" but he thought "if people do cool things they need to let me see their cool things"
That, and FreeBSD had a few handicaps. The biggest one was the AT&T lawsuit. Linus himself once said he'd probably not have bothered with Linux if BSD was clean. The second, BSD had a slower model of improvement. You needed to have the commit bit to do anything constructive. Meanwhile Linus (later Cox) took code from pretty much anyone that made sense. Third, BSD5 had a radical new kernel design that added a lot of complication for threading with little gain. DragonFlyBSD was forked because of this.
So, IMHO, there were a few things... all of them dented (Free)BSD, and there really wasn't another competitor out there.
Linux is not a copy of Minix, the code is quite different.
It's not a big mystery. Linus released a primitive kernel that worked, at the right time, with the right license, and then diligently kept rolling up contributions and releasing the result.
Expanding a bit:
While the first release of Linux was primitive, it worked. People hungry for a free *NIX were able to grab it and run it. At the same time, HURD was a big research project; if you just wanted to run *NIX on your own computer, HURD was not at all ready.
Linus released it at the right time. It was just becoming possible for large numbers of people to get the kernel from him, and to send contributions back to him. Something like Linux might not have worked at all before the Internet and/or BBSs; it would have been too difficult to send releases out and collect contributions of code.
Linus used the right license. He has said that the choice of releasing under GPLv2 was the best decision he ever made. Arguably a BSD license could have worked as well, but many people have a fear that if they contribute to BSD projects, that evil companies might benefit from their work; with GPL they are comfortable contributing. Also, IBM contributed some code that uses IBM patents; because of the GPL, IBM knew that commercial entities wanting to use the patents would still need to license the patents from IBM. So Linux got the largest possible pool of contributors.
And then there is the fact that Linus worked hard managing Linux. He collected patches sent by people and rolled them in. These days he writes very little code himself; almost all he does is manage patches. I'm not sure how much code he wrote in the early days, but I think his diligent application of patches sent to him helped Linux to become stable and useful.
Given all of the above, Linux was a success, and success bred more success (the "Snowball effect"). People who just wanted something that worked could grab Linux as it worked better and better all the time; people who wanted to join an active project joined it as it was the most active project.
If Linus hadn't released when he did, another project might have gotten the snowball momentum thing going and become the big popular project. But he did, and he worked hard to keep it going, and the result is the kernel that changed the world.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Not sure I see your point. While the phrasing is perhaps a bit uncommon, there's nothing grammatically wrong with the headline.
BSD did not in any sense fail or fizzle, it is ubiquitous in printers, network gear and other appliances. Funny Apple could take the Mach that GNU HURD mishandled and make a working core for their BSD variant. Stallman really does suck at leadership/management/implementation, idea man only.
cut them some slack. they're just doing the needful!
--
"It is now safe to switch off your computer."
386BSD wasn't available until 1992. Since Linus was making an OS to run on the 80386, he started his own in 1991.
Slackware distribution. Drop the mic.
While working at Intel, we had a large Linux conference with Linus and a few other noteworthy OSS dudes. Afterwards, while we were all millng around, I found myself next to Linus Himself and asked this very question. My belief was that it was the GPL vs BSD license which forced all changes to at least be available for inclusion in the next version. Linux felt that it was more of a timing thing where Linux just kind of hit at the right time. Who really knows?
I had been trying to afford a Unix installation at home as a CS student. All I knew was the Unix vendors. I was not aware of the social structure of the Unix world, various distributions, etc. I was crawling university surplus lots and calling Sun and DEC on the phone to try to find a complete package that I could afford (hardware + license and media). Nothing was affordable.
I was also a heavy BBS and UUCP user at the time over a dial-up line. One day, I found an upload from someone described as "free Unix." It was Linux.
I downloaded it, installed it on the 80386 hardware I was already using, and the rest is history. This was 1993.
So in my case at least, Linux became the OS of choice becuase it had traveled in ways that the other free Unices didn't. It was simply available somewhere where I was.
This isn't an explanation for why Linux ended up there instead of some other free *nix, of course, but by way of explaining the social diffusion of the actual files, I saw Linux distros as floppy disks around on BBSs and newsgroups for several years, with no hint of the others.
For someone with limited network access (by today's standards), this meant that Linux was the obvious choice.
As to why Linux was there and not the others—perhaps packaging and ease of installation had something to do with it? Without much effort, I recognized that the disks were floppy images and wrote out a floppy set. Booted from the first one, and followed my nose. There was no documentation required, and it Just Worked, at least as much as any bare-bones, home-grown CLI *nix clone could be said to Just Work.
I had supported hardware, as it turned out, but then Linux did tend to support the most common commodity hardware at the time.
My hunch is that Linux succeeded because it happened to have the right drivers (developed for what people had in their home PCs, rather than what a university lab might happen to have), and the right packaging (an end-user-oriented install that made it a simple, step-by-step, floppy-by-floppy process to get it up) while the other free *nix systems were less able to go from nothing to system without help and without additional hardware for most home and tiny lab users.
For comparison, I tried Minix around the same time (I can't remember if it was before or after) and struggled mightily just to get it installed, before questions of its capabilities were even at issue. I remember my first Linux install having taken an hour or two, and I was able to get X up and running the same day. It took me much longer to get the disks downloaded and written. Minix, by comparison, took about a week of evenings, and at the end, I was disappointed with the result.
STOP . AMERICA . NOW
It was because Linux more or less worked, and people could use it and add to it because of the GPL. The competitors all had problems:
* Minix was cheap but not free, and couldn't be redistributed with modifications. People worked around that by maintaining patch sets, but that was even more painful then than it is now (we have better tools now).
* The BSDs were in a quagmire of legal uncertainty and competing claims. Nobody knew for sure if BSD was free or not, so everyone assumed it wasn't.
* Xenix: Not free.
* Microsoft: Are you kidding me?
* SYSV: Not free
* HURD: Didn't work, and had such an elegant architecture that it wasn't clear if it could ever work.
That was the space when Linus Torvalds started hacking around (except HURD didn't even exist yet). If he'd been able to hack on Minix, he would have. But the license prevented it, so he took the opportunity to start his own. Lots of other people saw exactly the same situation and joined him in hacking on something that (a) worked, more or less and (b) they could hack on.
It's not that Linux lucked out and the rest of the competition failed. There was no other competition that satisfied the requirements of being free and hackable. It was also important that Linus was an excellent Benevolent Dictator that gave people few reasons to fork. Actually, on that last point it's rather impressive that Linus is still in charge, even after it's become an incredibly valuable property, used and contributed to by lots of megacorps.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Darl McBride has mod points, who knew?
Why was this modded a Troll? Tanenbaum? Is that you?
Fundamentally the BSDs and Linux were on par with one another in the mid 1990s. BSD386 was getting sued and that cost a year but it started ahead. Where Linux thrived though was it recruited from Unix users and Windows powerusers. Linux focused on the ability of Unix users the ability to run Unix at home, and focused on the ability for not particularly good system admins to setup servers. It aimed for ease of use. The BSDs conversely aimed to offer a Unix like environment for Intel/Western Digital Hardware; a free version of SCO.
Then of course came the licensing issue. Linux was already ahead by 1997. But GPL allowed companies whose primary goal was not to sell software (or at least the software in question) to cooperate safely. It turned out those companies were larger supporters of free software than companies who were making extensions to base packages.
I think the reason the Linux kernel was successful was that
a) It was very good on par with the BDS kernels originally
b) It was tied to the Linux culture.
c) The GPL
Linux culture beat the BSD culture. The GPL beat the BSD license. The kernel just went along for the ride originally, though of course it had to be good enough to not hamper Linux-OS. After the initial ride the commercial interest led to greater development for the Linux kernel than other kernels which led to it fitting more uses better and more commercial development and interest.... A self feeding cycle that does make the kernel a winning point for Linux-OS.
We would probably be using FreeBSD by now.
I know because I remember BSD and BSDi back in the 1990s in highschool for running BBSes. MkLinux I kind of heard of but didn't know exactly what it was until the late 1990s when Linux was the only OS.
FreeBSD was the new myspace and momentum was on GNU/Linux at this stage. In tech you need to be at the right place at the right time. Linux was there when the world wide web became available to the public and BSD unix came out during hte exact same time.
http://saveie6.com/
Why was Sanders the Colonel that succeeded?
The reason why Linux eclipsed Minix is obvious, since Minix was never more than an educational tool. But why did Linux triumph over BSD? In the early 1990s, FreeBSD was considerably better, more stable, and had a more liberal license. Here are my theories:
1. FreeBSD required a hardware FPU, at a time when many computers didn't have them.
2. The AT&T lawsuit put a lot of uncertainty over BSD.
3. The user communities were very different. Linux users were very open and helpful to newbies. BSD forums were hostile to anyone that didn't already know everything.
3. The user communities were very different. Linux users were very open and helpful to newbies. BSD forums were hostile to anyone that didn't already know everything.
I will go with this. When I reported a bug in the Amiga version of bsd that was causing issues in machines with 4mb of memory. The response from the bsd admins was "well get more memory." I'm intoning it politer here than they responded with too. I interpreted it as "fuck off", which I did.
On the other hand the lead developer of the Amiga 68K kernel, I can't find his name, was very friendly in his emails to me.
Supporting World Peace Through Nuclear Pacification
The "more liberal" license might be the problem. While the license for the actual code you get is quite liberal, it doesn't propagate. The GPL ensures that there is always more GPLed code, once you start out from a GPL base. The BSD license is in some way an evolutionary dead end, because it is so liberal that it does not guarantee its own propagation. If I want to contribute to a project and want a guarantee that in turn, I have access to the contributions of people who are using my code, I can't rely on the BSD license. A BSD license means that the only development you are guaranteed to get is your own development. Anything else is just by chance. Your code might be useful for lots of other people, but you stand empty. There is no ROI for your development work if you publish something under BSD license. If you publish the same code under GPL, and even a single other developer shows some interest and adds something to your work, you are guaranteed to get rewarded by additional functionality.
Systemd is a collection of small executables each with a precise goal, in line with the UNIX philosophy. /lib/systemd/systemd-* /usr/bin/systemd-*" if you want to verify this fact.
Do a "ls -alSrh
Due to latitudinal issues, everything that happens in Finland is cool. For instance, our babies eat your marines for breakfast.
Escher was the first MC and Giger invented the HR department.
For me, with a '386 at the time that I first heard of Linux, and with no fpu coprocessor, that was a key factor... although not the defining one, because I was soon going to be getting a '387 anyways. For myself, the deciding factor at the time was that FreeBSD did not support any sort of multiple OS system, where with Linux, I could boot from floppy which would then transfer control over to the hard drive after the kernel was loaded (or after lilo came out, even load the kernel directly from the hard drive), and leave my DOS partitions and the hard drive boot sector completely unaltered.
File under 'M' for 'Manic ranting'
Linux is not a copy of Minix, the code is quite different.
Yes. Linux and MINIX are both *NIX-style kernels. But MINIX uses a microkernel design while Linux is a monokernel.
Professor Tanenbaum famously told Linus "Be thankful you are not my student. You would not get a high grade for such a design :-)"
https://groups.google.com/forum/?fromgroups=#!topic/comp.os.minix/wlhw16QWltI%5B1-25%5D
So anyone who claims that Linux is a "copy" of MINIX really doesn't know what they are talking about.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Systemd is a collection of small executables each with a precise goal, in line with the UNIX philosophy. /lib/systemd/systemd-* /usr/bin/systemd-*" if you want to verify this fact.
Do a "ls -alSrh
And how many of them are dependent on other systemd-* or multiple other systemd-* for functionality or require the systemd PID 1?
At the heart of it, kernel development seems to always have been very YAGNI and agile, while all others were thinking about great concepts and not producing any real-life results.
Well, no it isn't. Those "small executables" can not function outside the systemd infrastructure. Moreover, systemd people keep trying to expand the range of software that will not build on non-systemd platforms. Please stop your shilling.
Try "all of them"
He built a teaching OS, a cool ass distributed OS (Amoeba), a good WAN solution on top of it (Globe), and much later the self-healing UNIX-comcompatible Minix 3. That was all while he taught thousands of students how to build shit right. Andy is anything but lazy.
If you read the Linux Kernel Mailing List http://lkml.org/ for a while, you will see why Linux was successful. Over and over again, Linus Torvalds over-rides the antics of his minions and explains to them (again) that the changes they made must be backed out because they break something that users actually need. Linux is elegant and beautiful, but not just because it's a work of art. Linux is the most functional piece of code in existence. It is the beauty of function.
"He took a duck in the face at 250 knots." -- William Gibson, Pattern Recognition
I think the AC was just confused as Linux's origins are related to MINIX, even if it isn't a clone or shares any code.
From memory, Linux was Torvald's response to the fact MINIX remained a 16 bit operating system. Impatient, Torvald's created the Linux kernel presumably in part because he wanted to create a kernel, but in part to solve the missing 386 Minix issue.
The two were related, but no code from MINIX was present in Linux. As an example, the original Linux file system was a re-implementation of the MINIX file system. Linux's ext family of file systems came later. Early Linux based systems ran the MINIX userland, but this was replaced early on with GNU. It was the replacement with GNU that meant Linux could legally leave the MINIX community and become the kernel of a standalone operating system.
IIRC Linus's original announcement was on the MINIX mailing lists too.
You are not alone. This is not normal. None of this is normal.
I would add two more to that list.
Distro size. Distros at the time fit on 3-5 high density floppies less if you stripped out some niceties. BSD took 20 and splitting it apart was not obvious.
Download that over a 2400 baud modem. I did. Linux was done in a few hours. BSD took longer.
Secondly XFree86 catapulted it to the top of the pile. A mostly working x11 stack? Yes please.
Tozzi overthinks it in the article. The kernel succeeded by being in the right place in the right time and then continuously being good enough that there was insufficient reason for change.
Linux, the OS not the kernel, was the first mostly complete Unix available on a college student's budget that would install on hardware the college student mostly already had. Right place, right time. Hurd didn't exist in any usable form, Minix and Solaris were $$ and the *BSD's didn't start to release for a year or two later.
Fast forward four years and when those graduating college students met the Internet bubble, Linux was the server OS they knew. Right place, right time.
Byeond that it was a game of, "don't eff it up." That's where Torvalds' pragmatism came in to play.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Aaand that is simply false. Why systemd shills won't just stop lying, I wonder?
You are changing the subject. "The whole initscripts mess" may or may not work outside the init infrastructure. But each individual script will, which is precisely the point. On the other hand, none of systemd components will work outside systemd. So please stop your shilling.
The only difference that results in (resulted in, it's getting better lately) is that BSD-licensed code gets used, while GPL'ed code doesn't get used, for commercial purposes. Furthermore, getting upstream to add your changes is cheaper since you no longer need to maintain them yourself, so companies still have good reasons to contribute back.
The OpenBSD people's take on the matter is:
People sometimes ask if it bothers us that our free work is put into commercial products. The answer is, we would prefer that our good code be widely used rather than have commercial software vendors reimplement and create badly coded or incompatible alternative solutions to already solved problems. For example, it is likely that SSH is a widely used protocol due to this freedom, much more widely used than if restrictions had been placed on how people used the OpenSSH code. If a free SSH solution was not available for vendors to use (in their multitude of rapidly developed products), they would have written or purchased some crummy off-the shelf version instead.
Now, about
If you publish the same code under GPL, and even a single other developer shows some interest and adds something to your work, and in turn decides to distribute that to others, you may get rewarded by additional functionality.
FTFY. It's kind of important to note that as long as you don't plan on distributing your modified version (and in many cases, why would you?) , you're not required to, well, distribute your modified sources.
Then, many modifications will just be horrible hacks to scratch some immediate itch, which you wouldn't at all want in your source base, so GPLing stuff is far from providing a guaranteed enhancement return, even if there is interest.
CLI paste? paste.pr0.tips!
And what is precisely the point to have a initscript running outside sysv-rc + sysvinit? To have a simple script running? Whoow! Such a great feature.... Seriously, did you think that a machine running systemd is not able to run a simple script? The reality is that initscripts need sysv-rc to boot the machine.
By the way, systemd is compatible with sysv-rc so what are you complaining about ?
Did you even know that almost all of the SysV init scripts call out to system-wide scripts? Try running SysV init scripts just by themselves, without having the monolithic SysV init directories in your path. You can't. Ever. Does one thing without dependencies my ass!
For example on Fedora:
# grep -r '.
210
This shows how little you understand the arguments you're making, and the commonly proposed solution of using SysV actually achieves it.
The funny part, of course, is that with systemd the start/stop scripts/programs are indeed standalone in many cases, and the best practices will lead to that naturally. Most of the ones that require systemd only require it because they're using a compatibility layer that calls out to the old script.
No it wasn't that. Andrew Tannenbaum had no intention of using Minux as a general purpose OS kernel like people wanted it to be. He wanted it to be a teaching kernel and thats all. He didn't accept patches for the most part because he wanted it to remain simple enough for an undergrad student to completely understand (I know that because my WANG hard drive patch couldnt be accepted because of that very reason). Even patches to add networking where rejected.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
The paranoia around the license might be something; the effects your describe is a misconception on your part, but it is a shared misconception, so it does affect people's behavior.
However, what I think is most important was initial hardware support.
FreeBSD and Linux got a different amount of users in the early times, when Linux had more low-end hardware support (IDE disks, missing FPU, low end network drivers by Donald Becker), and gained a lot of marketshare when the ATT lawsuit was happening.
After that, Linux and FreeBSD grew at the same exponential rate for many years, with FreeBSD having the same marketshare. This changed around Linux 2.6. There are several things that happened around then which may account for the loss of FreeBSD marketshare. For example, Matt Dillon (FreeBSD VM system maintainer) helped Linux implement a VM system that worked about as well as FreeBSDs. This had been one of the major selling points of BSD vs Linux. There are also network effects that started being really significant for Linux, as Linux became bigger than all the other Unixes combined. And FreeBSD kept the port system very similar to how it had originally been developed in the mid 1990s, while open source became more intertwined. This made FreeBSD harder to update compared to many Linux distributions, and became seriously annoying around that time.
Since many things happened around the same time, it's hard to pinpoint the exact reason for the divergence.
His point is that 'init scripts' are only scripts......you don't need 'system V' or anything to run them; all you need is bash. Even systemd can run init scripts, or you can run them from the command line.
However, init can't start the system without the scripts, so in that way systemV depends on the scripts, not the other way around. The point is trivial like splitting hairs, but technically true.
"First they came for the slanderers and i said nothing."
Back in '94/'95 when Linux was new I asked Alan Cox a couple questions via email, which he replied. Made some changes to the driver to the ethernet chip we were using, he took those and thanked me. No experience with BSD so I can't contrast/compare.
According to this by a near super majority the most popular license type on Github is MIT. Combining the BSD2 and 3 licenses makes the super majority of licenses extremely liberal.
Man blir trött av att gå och göra ingenting.
The argument is 'splitting hairs' because it's getting at the wrong point. The problem with systemd isn't that the init scripts (or unit files) depend on systemd......it doesn't matter if sys5 init scripts can't run without sys5 scripts or whatever. No one cares about that.
The point is that cron or apache or qmail can all be started with any init system. Systemd utils can't be started without a specific init system, which means logind (and by implication Gnome) can't be started without systemd. That is definitely against the unix way.
"First they came for the slanderers and i said nothing."
So on Fedora, there are (at most (*)) 210 occurances of init script sourcing one particular system V helper script which, judging by the name, defines common shell functions used by multiple init scripts. What exactly is your point here? The content of /etc/init.d/functions should be replicated 210 times in each of the respective scripts rather than being sourced? With that idea of good design, it doesn't surprise me you're a systemd proponent.
Why do i have the feeling that your real intention was to make a casual reader believe that there were 210 "system-wide" scripts (whatever the fuck thats supposed to mean in this context, what is /not/ system wide at init time?) littered all over the place that the init scripts would depend on. Nice try.
And after failing that hard...
This shows how little you understand the arguments you're making
which leaves me thinking about pots and kettles.
(*) of course the actual command is a failure too, since that period is a wildcard and no boundary is given either. So even a comment somewhere in a script reading "# by the way, we would never source /etc/init.d/functions" would mistakenly be included in your already pointless measurement. For the record, a competent AC would have used
(note the -l) rather than
Not that the result is anything meaningful.
CLI paste? paste.pr0.tips!
The point is that you compare a simple script with a systemd-* binary, complaining that you can't run any systemd-* binaries without the systemd infrastructure.
What you fails to understand is that the equivalent of init scripts in systemd is not the systemd-* binary but a unit configuration file. If you want to compare a systemd-* binary, take a binary that provide the same kind of service. What you will find is that the usual code (or libraries) in the traditional service application is replaced by a more standardized API in the systemd-* application. For example, instead of depending on libdaemon, the application will depend on libsystemd. See https://github.com/systemd/sys...
At the end systemd will reduce the number of dependencies required by the applications that use his API compared to an application that will try to provides the same features without the libsystemd API. From the architectural point of view this is a good move.
To put Lennart's name on things that have not had his name on it before :)
Apart from a tiny portion of the project devoted to starting things in parallel instead of sequentially (and done by people who didn't not seem to take race conditions seriously hence their shiny new binary logs getting corrupted into unreadability), it's a "solution" to a non-problem.
I've had a machine this week not boot and lock up hard for hours because systemd hung the entire system trying to work out what a wireless mouse dongle was - it's nowhere near ready for serious use.
Yeah. I was there at the time, writing patches for the Minix kernel... Linus specifically wanted support for 386 protected memory and virtual memory. AST wouldn't do it, because it would mean Minix wouldn't run on 68000-based systems like my Atari ST. So Linus went away and hacked together his own 386-only replacement kernel over a weekend.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Please tell me how did BSD win from OS X using it as a code base. They don't give back, and attempts at cooperation ended up wasting some time of BSD developers.
BSD got its automatic live self-defragmenting code from OS X. Then there's libdispatch/GCD, LLVM, and so on.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
And all of that existed with upstart, daemontools, many worked with inetd, and in general many other systems solved the same problem. Systemd's danger is its insistence on doing _everything_, including replacing logging, DHCP, NTP, and numerous other already working and well understood components. Its proponents have made clear that they intend to replace all of /etc.
Discussing systemd as if it were only an init script replacement is missing out on why people are upset about it.
Mainly because Javascript and code on demand execution model. Javascript libraries with GPL are a non starter.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
I'm a bit surprised that anybody is puzzled about this because I thought it was obvious too. I guess it just goes to show that I'm getting old. For those who weren't around at the time, my recollection is pretty much exactly as you have it, but I suppose I can elaborate a little bit.
1. The FPU issue was definitely important, but to be honest by the time the 486 became popular I don't think the Linux camp was tremendously bigger than the FreeBSD camp. I know that when I got a 486 I was torn between the two and actually was leaning towards FreeBSD because I used BSD at work. But I chose Linux because...
2. The lawsuit is probably the most important issue. It was just enough of a swing to give momentum to Linux. I remember when the MCC distribution came out, it was more convenient to go with Linux than FreeBSD and I pretty much stayed there after that. My impression was that Linux was many people's second choice and that a lot of people were waiting to see how the lawsuit turned out. By the time it was over, Linux had such a good infrastructure that it was hard to think about switching. I think the first time I started thinking about switching again when when FreeBSD ports came out (which Wikipedia says happened in 94).
3. The user communities issue is probably the most overlooked, but I think it is important. Personally, I don't think that there was *that* much to choose from between the Linux and FreeBSD people -- at that time if you were used to using some kind of Posix system you were already fairly hard core. You had to build the kernel yourself to support whatever hardware you had. I did that for years.
Where you see the differences in approach is between Linux/BSD and HURD. I wanted to work on the HURD because I had done a project on Mach in university. My memory is hazy about the details, but when I approached the maintainer I was told in no uncertain terms that help from someone as unaccomplished as me was not welcomed. I really believe that Linux was so successful mainly because Linus just accepted patches (and even thanked people!). It was very, very, very easy to work on. That low barrier to entry attracted some really good people and things took off.
It is something I that I have taken with me throughout my whole career, even when working on non-free software. It's easy to have an elitist attitude and to think that you must protect the software from the unwashed masses. You feel that you must restrict development to a few blessed people who you know won't screw everything up. Having a more optimistic strategy where you assume people are good actors until they prove themselves to be the opposite is much more successful -- especially for free software.
Having said that, there are of course times when certain people exhaust even Linus's patience and I am impressed with how he chooses to draw the line. It is definitely something I wish I could get away with in my day job. Alas, those kinds of decisions are often not possible for me.
I was a CS student at UC Berkeley when Linux was first announced on Usenet... I also think that the ease of sharing a hard-disk with existing Windows installs, the initial focus on x86, and the familiarity of the basic DOS partitioning scheme were hugely important. The relative homogeneity of the PC platform also allowed a friendly community to bootstrap very quickly. By comparison, the "home team" BSD variants were already fragmented across many different CPU and system architectures, with much more specific hardware requirements or much more do-it-yourself work to bootstrap a new system.
Even at Berkeley, it was easier to self-help via the Internet to install Linux, than to get local BSD zealots to help you bootstrap a personal BSD machine. So, a large number of my Berkeley classmates adopted Linux to actually do our class work on personal machines, while only the most masochistic of my peers were still using or trying to use *BSD. We used a wide variety of Unix flavors on the servers and workstations in school labs, but when we went home we often found that our little Linux boxes were just as fast or faster for doing our actual school work. It being Berkeley, the BSD users certainly supported each other and liked to deride Linux, but they were better at turning away new users than they were at BSD advocacy.
The Linux community was already growing rapidly by the time we started seeing Linux getting ported to other CPU and system architectures. I had both a 486 PC and a DEC Alpha running Linux on my own LAN and connected to the Internet via SLIP before I graduated. Within a couple more years, people like me were now out advocating its use in companies, universities, and national labs. The truth behind the "Beowulf" cluster meme was also significant, as some small fraction of government funding was going into improving Linux by leaps and bounds instead of all going into the extravagant margins of SGI, Cray, Sun, etc. We quickly improved networking, commodity SMP support, and GPU acceleration that made Linux relevant in many high-performance tasks.
Ironically, think about how the Android platform is now fragmented for many different phone chips and models with very different sub-communities, tools, and download sites. This is how the BSD variants felt back in those early days, while Linux was much more standardized and approachable! This is also the reason that I hope mobile platforms do not kill off the PC, as this seems a huge step backwards for future students.
His statement seemed quite generalized with OpenSSH/SSL cited as an example.
I personally don't partake in the license wars, but I don't think the success of any particular piece of software was tied to the license choice.
OpenSSH is an excellent piece of software with lots of excellent people working on it, as is Linux. As to why Linux succeeded more than BSD? I couldn't say. I've worked in both of the kernels, and they're equally heinous (as kernels are usually wont to be)
They've got their own lists of idiosyncrasies, and both do most things pretty damn well, and a few things each pretty damn excellently. I think it mostly comes down to the position of Linux grabbing the niche of Unix on commodity hardware before BSD had a solid offering, thus getting most of the developer mindshare. That kind of momentum is hard to compete against- because it's not easy working in multiple kernels. You get in a mindset that set of working knowledge that is highly tailored to the one you're working on.
Switching back and forth has always been a pain to me from the coding aspect, and I've never paid a second of time thinking about the license. I'm fine with both license models, really.
Disclaimer: I professionally work in the Linux kernel, as well as amateur kernel-level and below firmware hacking for embedded devices running many kernels. I've also done amateur work in BSD kernels.