Why Was Linux the Kernel That Succeeded? 469
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.
Meh (Score:5, Interesting)
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.
Re:Meh (Score:5, Interesting)
about 10 or 15 yrs ago, at least in the bay area, people WERE afraid of the linux gpl. I worked at many places that avoided using linux code in their products and we used any form of bsd we could.
now, I never see bsd mentioned anymore in job ads. its ALL about linux.
wonder what finally made the c-levels unafraid of linux? the gpl is still the same and we did have gplv2 and v3 back in the old days when bsd was 'the thing to use' for networking boxes.
why no longer afraid of Linux? (Score:5, Insightful)
time and nobody important being sued
Re:why no longer afraid of Linux? (Score:5, Insightful)
HP and IBM acceptance and putting hundreds of millions into Linux R&D research so it could run on their x86-64 servers, midrange (e.g. ibm power systems and HP integrity mid range) and big iron (ibm mainframe and HP superdome)
Re: (Score:2, Interesting)
time and nobody important being sued
Until CISCO at least. When that happened, the suits went nuts. Where I worked there was a huge initiative to make sure we weren't at any kind of risk of the same thing happening. Every bit of open source we were using was reviewed, a database was created, and a whole process for approving and tracking use of anything we didn't pay for was implemented.
They became really paranoid about it. For awhile you'd have better luck asking for a piece of software that costs $10k than asking for a BSD licensed tool to d
Re:Meh (Score:4, Interesting)
about 10 or 15 yrs ago, at least in the bay area, people WERE afraid of the linux gpl. I worked at many places that avoided using linux code in their products and we used any form of bsd we could.
The success of Linux isn't because of it's users 10 or 15 years ago. It's because of its contributors 10 or 15 years ago (and today). And GPL attracts contributors while BSD push them into forking and keeping their local changes for themselves.
Re: (Score:3)
That is refuted by the fact that BSD still works fine, and all the modern *nix software runs just fine on either.
I've been using one or the other since before "10-15 years ago" and that was the case already then, and continues to be the case now.
What people don't understand about BSD, and most open source, is that nobody actually benefits from users except the users themselves, and people selling services. Contributors mostly contribute for their own reasons, and *nix versions with low numbers of contributo
Re:Meh (Score:4, Informative)
Re:Meh (Score:4, Interesting)
Plenty of users of the BSDs contribute their changes back. Yahoo and Apple are both rather giving in this respect. Part of the reasoning is that once you make your change proprietary you then have to effectively fork the code and continue all maintenance yourself. For infrastructure changes its simply easier to contribute the change back. If someone keeps one bit proprietary and submits ten other bits back as a result of keeping that bit proprietary I still consider that a win.
Re:Meh (Score:5, Interesting)
The GPL and BSD legal uncertainties may have been a part of it, but that still leaves us with the question, Why Linux and not HURD?
HURD was also GPL and free of the BSD uncertainties.
Re: (Score:3)
There was no HURD at the time, and people got tired of waiting.
Re: (Score:3)
Wait a second, HURD is done?
Re:Meh (Score:5, Funny)
Not sure. Try sticking a fork() in it.
Re: (Score:2)
Well my keyboard needed washing anyway.
Re: (Score:2)
Re: (Score:2)
ha!
the only comment I have to yours is:
"well done"
Re:Meh (Score:5, Informative)
As opposed to today, when... We still have no HURD, and people stopped waiting a decade ago?
Re: (Score:2, Interesting)
Hurd was never a viable kernel. It never did much. Moreover micro-kernel design didn't work very well. QNX is really the operating system that got micro-kernels working well and they took it in non-desktop directions. On the XNU (OSX kernel) the kernel has moved more and more monolithic for performance, speed matters. Citrix is doing some interesting work on microkernels so we'll see.
Ultimately though, it is just too expensive to add even a few extra simple operations to most kernel functions. And
Re: (Score:3)
That's pretty much how XNU (OSX) evolved. Microkernel with monolithic for some stuff. Though once in it gets harder to pull it out again so the movement has been mostly one way. My point was Hurd never made those compromises, so it wasn't a viable kernel.
Re:Meh (Score:4, Informative)
I think the main reason Linux grew like it did is Linus Torvalds himself. His attitude as a benevolent tyrant seems to have worked pretty well.
Re: (Score:3)
We both had 486s. He found that he had better hardware support in Linux than BSD, so he switched to Linux.
The early kernel compliation process (at least as far back as 2.0.0) was relatively friendly. One could use a text-based menu system that worked similarly to how the text-driven installation process for Debian works now, to pick the hardware to support, to pick if the kernel was to be modular or mon
An entire troll article. (Score:2)
I'm surprised he didn't include a "BSD IS DYING, NETCRAFT CONFIRMS IT" in the article.
Stone soup (Score:5, Interesting)
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.
Re: (Score:3)
wow, thanks anonymous person... and I like Danny Kaye...
Snowball effect (Score:5, Insightful)
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.
Re: (Score:2)
No one outside of RMS shares this extreme ideology. Most of the 1990s usenet groups for software were warez.
What got Linux to work was AT&T sueing Berkley for those net/2 tapes and directives like FreeBSD off. FreeBSD was already there and working and light years ahead of Linux for a full decade.
Re: (Score:3)
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.
The race is not to the swift, nor the battle to the strong, neither yet bread to the wise, nor yet riches to men of understanding, nor yet favour to men of skill; but time and chance happeneth to them all.
Then again, once time and chance happeneth, being wise, understanding, and skillful don't hurt.
Re:Snowball effect (Score:5, Informative)
A few more comments to expand on the above.
A project like Linux would not have been possible without the GNU project, most particularly the GCC C compiler. Commercial UNIX releases charged something like $2000 for a C compiler, but thanks to Richard Stallman there was a free C compiler for Linus to use, and Bash and everything else.
Before Linux was released, MINIX was a popular choice for a free *NIX. But licensing issues tangled up MINIX: to build MINIX you needed to buy Tanenbaum's book, get the source code that came with it, and then apply all the community patches (which had to be kept separate purely for licensing reasons). If Professor Tanenbaum could have released the source to MINIX under GPLv2, and he or someone else had worked as hard as Linus did to collect and apply patches to improve it, maybe MINIX could have gotten the snowball effect going. (Note that MINIX was what Linus was running when he wrote Linux!)
As others have noted, there was at least one BSD available around the time Linux got going, but there was the dark shadow of a lawsuit and the future of BSD looked uncertain. Linux had the advantage of being all-new code with no legal uncertainty. Absent the lawsuit, maybe BSD could have gotten the snowball going.
Re: (Score:2)
Also incredibly important on top of that, lots of people had a personal interest it succeeding:
- Red Hat, Novell etc on the software front.
- Also companies like HP needed a *nix and BSD was currently engulfed in FUD.
If you want your product to succeed you're far more likely to be successful when other people can profit as well from your project's success. "What's in it for me?" is the rally cry of any potential investor of time or money. In the case of Linux there was a lot in it for a l
Re:Snowball effect (Score:4, Informative)
Backwards. Linux wasn't successful because Red Hat and Novell got behind it. Red Hat and Novell got behind Linux because it was successful. Red Hat was founded *after* the Linux kernel was first written and didn't become a big corporation until 8-10 years after Linux's first release. Linux grew Red Hat, not the other way around. Novell got seriously involved in pushing Linux even later.
Re:Snowball effect (Score:5, Interesting)
Re:Snowball effect (Score:5, Insightful)
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.
This is all true and important, but I think it's leaves out the really important part. Linus has good judgement in two critical areas; policy and people.
You and many others are correct about the timing, license and Linus's willingness to accept contributions without preconditions, and that part of it accounts for the early days. But it could have gone so wrong later and it didn't.
Had RMS been the shot caller Linux would be a curiosity today. People like him, while well intentioned, can't help but strangle babies in cradles in the name of their agenda. The kernel would be on GPL4 or 5 by now and about the only thing you might be able to use it for is a non-profit operation. The RMS mentality would have precluded set-tops, portables (binary blobs, DRM, etc.) the cloud and many other use cases. The best case would have been "for-profit" forks and then decline.
Also, Linus doesn't suffer fools. Over the years there have been contributors that, while possessing some talent, were destructive to the process. Linus has reliably kicked them to the curb and kept them from ruining Linux development. It's a simple, unfortunate truth; some people don't play well with others and if they get a foothold in something they ruin it.
These two aspects of Linus, good and firm judgement about policy and people, have ultimately been the most important because failure of either would have killed Linux long ago regardless of the early enthusiasm. That one person embodies the drive, talent and judgement to take Linux this far while protecting it from the bad ideas and fools that prevail is a small miracle.
Author makes ignorant statement (Score:3, Insightful)
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.
Re: (Score:3, Informative)
There, FTFY.
Easy (Score:3)
Slackware distribution. Drop the mic.
I once asked Linus about this (Score:5, Interesting)
Single case anecdote. (Score:5, Interesting)
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.
Re:Single case anecdote. (Score:4, Funny)
and now, sun and DEC are both long gone and one of them, nearly entirely forgotton. (sad, I worked at both of those fine companies and was lucky to have had the chance to work at such places).
linux is here, but vax and vms and alpha (and ultrix; I ran ultrix for a while) are all pretty much unknowns today.
wonder how long linux still remain relevant? I don't see it going away, but then again, I said the same of sun and DEC (and SGI, lets throw them in there, too. yeah, I was there, too, lol.).
Licensing, mostly (Score:5, Interesting)
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.
Re: (Score:2)
As with any big success, it seems that the success of Linux must be attributed to multiple factors, of which you make a very good case for some of the most important.
That said, in "The Cathedral and the Bazaar", a lot of credit is also given to Linus for inventing the Bazaar model of software development.
I've watched Python carefully over the years, and I think the success of Python can be most strongly attributed to technical factors, that is, the design of Python itself. However, it's also clear that the
Re: (Score:3)
Other than Xenix what do you mean by Microsoft
Er, nothing actually. TFA mentioned "Microsoft's take on Unix", which I took to mean NT's stab at POSIX support, or maybe something else equally ridiculous. Looking at the article again, it actually says "Xenix, Microsoft's take on Unix". Not being more than vaguely aware of Xenix, I didn't realize it was bought by Microsoft and I took that text as two separate items in the list (should have paid closer attention to commas vs semi-colons).
Also you forgot SCO if you are including commercial Unixes for 386
Indeed. There I claim selective memory, driven by the massive stain o
The kernel was tied to the culture (Score:4, Interesting)
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.
Re:The kernel was tied to the culture (Score:5, Insightful)
Around 1994 or 1995 I was starting an applied research project that needed an oddball sort of network widget. I e-mailed Alan Cox, whose group was handling most of the Linux network staff at the time, describing what I was trying to do. I got an e-mail back the next day that was basically: "Sounds cool! Ethernet sockets might be able to do the job (draft documentation attached). If not, let me know and we can discuss the best place for you to add a hook to the IP stack." Ethernet sockets were sufficient; I had a basic version of the widget up and running after a couple of long weeks; it was impressive enough that mgmt let me run with.
No way any of the other kernel projects were going to treat me that well.
Thank AT&T lawsuit (Score:4, Informative)
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.
Re: (Score:3)
If I would have Mod points.
FreeBSD was/is a good alternative to Linux. It was more mature... However AT&T legal stuff made it a little more risky to go in the direction of Unix. But Linux wasn't Unix, but it was enough like Unix to get the advantage.
which begs the question.... (Score:3)
Re: (Score:2)
Linux was Easy and Worked! (Score:2)
Linux took some thought, a
mascots (Score:2)
My completely unbiased opinion (Score:3)
How quickly everyone forgets (Score:2)
Microsoft and IBM ended up in a spat over OS|2 and parted ways. That left IBM very angry at Microsoft and without an x86 operating system. IBM spent $1B on Linux in the early 1990's and made a major marketing campaign out of doing it. They even ported Linux onto their sacred mainframe - the Z-series. This IBM support legitimized Linux and propelled it into becoming what it is today.
Comment removed (Score:3)
Re:Why Was Linux the Kernel That Succeeded? (Score:5, Funny)
FTFY
Re:Cuz Minix Dude Was A Old Guy (Score:5, Informative)
Linux is not a copy of Minix, the code is quite different.
Re: (Score:3)
Darl McBride has mod points, who knew?
Re: (Score:2)
Re:Cuz Minix Dude Was A Old Guy (Score:5, Informative)
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 [google.com]
So anyone who claims that Linux is a "copy" of MINIX really doesn't know what they are talking about.
Comment removed (Score:5, Informative)
Re:Cuz Minix Dude Was A Old Guy (Score:5, Informative)
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.
Re: (Score:3)
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.
Re:Cuz Minix Dude Was A Old Guy (Score:5, Insightful)
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.
Re:Cuz Minix Dude Was A Old Guy (Score:5, Informative)
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.
Re:Cuz Minix Dude Was A Old Guy (Score:5, Interesting)
Re:Cuz Minix Dude Was A Old Guy (Score:5, Insightful)
Re:Cuz Minix Dude Was A Old Guy (Score:5, Interesting)
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 [openbsd.org] 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.
Re: (Score:3)
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 [freebsd.org], LLVM, and so on.
Re: (Score:3)
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
Re:Cuz Minix Dude Was A Old Guy (Score:5, Informative)
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.
Re: (Score:3)
Re: (Score:3)
Mainly because Javascript and code on demand execution model. Javascript libraries with GPL are a non starter.
Re:Cuz Minix Dude Was A Old Guy (Score:5, Interesting)
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.
Re: (Score:2)
I think that the reasons Linus started the project in the first place are what really brought in most of the early users (I know I shared a lot of them).
Certainly #1 on your list was the decider for me, since I was a struggling college student and couldn't afford anything better than a 386SX, and desperately wanted to be able to run something Unixy at home.
Re: (Score:3, Interesting)
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 tw
Right place, right time. (Score:5, Insightful)
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.
Re: Cuz Minix Dude Was A Old Guy (Score:5, Insightful)
Don't break user space! (Score:5, Interesting)
If you read the Linux Kernel Mailing List http://lkml.org/ [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.
Re:Don't break user space! (Score:5, Interesting)
Don't forget Mac's were at least as unreliable as Windows back when Linux was catching on. Mac OS X only beat Windows XP by a few months.
Re:Don't break user space! (Score:5, Interesting)
Monolithic kernel. You have a somewhat valid argument there. There are modules that I just don''t use, that are routinely compiled into the kernel. Simple solution: Compile it yourself, without the modules. Strip the kernel down to exactly what you need, and compile it native to get rid of all the 32-bit support. You're left with a monolithic kernel, of course, but the monolith is much smaller.
Re: (Score:3)
Monolithic kernel. You have a somewhat valid argument there. There are modules that I just don''t use, that are routinely compiled into the kernel. Simple solution: Compile it yourself, without the modules. Strip the kernel down to exactly what you need, and compile it native to get rid of all the 32-bit support. You're left with a monolithic kernel, of course, but the monolith is much smaller.
But, but, but, then I have to compile it myself, do it myself? See, that is the root of my complains about monolithic kernels. Where is that damned violin when I need it :P
Re: (Score:3)
Drinks kool-aid?
Linux is a monolithic system. Not so great, read efficient in a distributed space.
Reason Linux was successful:
Timing: Everyone was fed up on FOSS OSes.
blah, blah, piss, piss, diss, diss.
Linux worked, Linux still works. You can and could submit changes and they would either be accepted or rejected. They are the reasons Linux is successful. Sure the piss on the furniture posters can point to obscure kernels that theoretically are "better" - but, ironically, they miss the point - it is the most widely used kernel. So all the reasons other kernels are "better", are wrong.
Pointing to timing is like claiming that Google, eBay, Ffffacebook, and Amazon all succee
Re:WTF? (Score:5, Insightful)
Not sure I see your point. While the phrasing is perhaps a bit uncommon, there's nothing grammatically wrong with the headline.
Re:WTF? (Score:5, Funny)
cut them some slack. they're just doing the needful!
Re: (Score:2, Insightful)
Overallocations, OoM Killer, hangs and freezes all because the kernel can't be bothered to keep track of every last bit of it's memory make the Linux kernel a piss-poor substitute for a real UNIX kernel.
There are other problems in the memory subsystem as well. For example, if you are not using swap and the system begins to run out of memory, it starts throwing out pages of active programs from memory. Very soon they are loaded again from disk when those parts are needed. This causes a disk-grinding circus that feels like swapping.
Re: (Score:2)
People who really know how to troll mostly grew up and either stopped or found ways to make money doing it. We now have what's left.
Re:Not heard of BSD (Score:4, Interesting)
Re: (Score:2)
BSD worked. Linux did not in 1991. You needed to load Minux 1st.
Re: (Score:2)
Re: (Score:2, Troll)
Your years are off. Around the time of the 386SX I had 20megs of RAM in my 386. Hard drives were hundreds of megs. $1000k 20mb drive is like 1985 or so. 1990 you are at like $10 / meg for storage and 1995 around $2 / meg.
Re:The GPL (Score:4, Interesting)
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
Re:The GPL (Score:5, Informative)
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?
Re:The GPL (Score:4, Interesting)
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.
Re: (Score:3, Interesting)
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
Re: (Score:3, Informative)
Try "all of them"
Re: (Score:3)
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.
Re: (Score:3)
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 de
Re:The GPL (Score:4, Interesting)
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.
Re: (Score:3)
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 ?
Re:The GPL (Score:4, Interesting)
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... [github.com]
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.
Re: (Score:3)
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.
Re: (Score:3)
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 hu