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.
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.
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.
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
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'
That's it, it worked, and the license let it pop up on a few CD cover discs with no hassle. At the time, we were a SCO Unix house, solid, worked, no complaints but the cost wasn't trivial. Still, worked and worked well. Messing about we looked at other unix things, one was.. (going off memory now) MKS Unix I think it was. And... can't recall the other, some 99 quid one that was also rough around the edges. Now, Linux was free, no 'get in touch for commercial reasons' and within a couple of weeks, we got an updated version. The other cheapo unixes we looked at had problems and didn't look like they were being fixed quick. Loading up all our code, and doing a make... it worked. It all flippin worked. Was /really/ scary to see that the compiler was very decent, the headers all included, if it DID need any tweaks, they were so inconsequential that we knocked them out in minutes. Bosses were impressed, but worried about support, and that's why as a company we didn't go official, but all of us said "this is going to dominate one day, it works and works well".
But overall... availability/cost was the thing that got us looking at it. Plus, compared to other unix versions, it felt very similar to SCO in it's layout at the time (at least Slakware did, Yggdrasil had better gfx support for the cards I had at the time (Trident...? maybe?) but Slackware was very familiar.
Though I'd not have ever expected that one day I'd be lugging a phone around with me that ran Linux at it's core.
Waiting for an amusing sig.
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.
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
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!
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.
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.