Linux came after the BSDs, so you would think the BSDs would have won.
There are many reasons Linux-based systems are generally much more popular than the BSDs in the server and workstation spaces. Here's why I think that happened:
* GPL vs. BSD license. Repeatedly someone in the BSD community had the bright idea of creating a proprietary OS based on a BSD. All their work was then not shared with the OSS BSD community, and the hires removed expertise from the OSS BSD community. In contrast, the GPL forced the Linux kernel and GNU tool improvements to stay in the community, so every company that participated improved the Linux kernel and GNU tools instead of making their development stagnate. This enabled the Linux kernel in particular to rocket past the BSDs in terms of capabilities.
* Bazaar vs. Cathedral. The BSDs had a small group who tried to build things elegantly (cathedral), mostly in "one big tree". GNU + Linux were far more decentralized (bazaar), leading to faster development. That especially applies to the Linux kernel; many GNU tools are more cathedral-like in their development (though not to the extent of the BSDs), and they've paid a price in slower development because of it.
* Multi-boot Installation ease. For many years Linux was much easier to install than the BSDs on standard x86 hardware. Linux used the standard MBR partitioning scheme, while the BSDs required their own scheme that made it extremely difficult to run a BSD multi-boot setup. For many people computers (including storage) were very expensive - it was much easier to try out Linux (where you could dual-boot) than BSDs. The BSDs required an "all-in" commitment that immediately caused many people to ignore them. I think this factor is underappreciated.
* GNU and Linux emphasis on functionality and ease-of-use instead of tiny-ness. GNU tools revel in all sorts of options (case in point: cat has numerous options) and long-name options (which are much easier to read). The BSDs are often excited about how small their code is and how few flags their command lines have... but it turns out many users want functionality. If tiny-ness is truly your goal, then busybox was generally better once that became available circa 1996 (because it focused specifically on tiny-ness instead of trying to be a compromise between functionality and tiny-ness).
Some claim that the AT&T lawsuit hurt the BSDs, but there was lawsuit-rattling for Linux and GNU as well, so while others will point to that I don't think that was serious factor.
An excellent summary. I think by the late 90s BSD could operate cleanly alongside Windows but by then Linux had become the default "free" *nix choice.
For me, I ran FreeBSD for about a year around 1999. I lasted about a week before breaking down and installing a GNU userspace. Excellent CLI ergonomics for the day.
Linux had quite a few "easy to install" distros where, if your critical hardware was fully supported, you had something that was easier to get up and running than Windows 95/98. X configurations and sound drivers were a sticking points back then though. BSD had no such "easy mode" gateway drugs.
No, by the late 90s BSD had dominated the hosting world because the TCP/IP stack allowed better scaling on the same hardware. Tons of ISPs ran nothing but FreeBSD.
> Some claim that the AT&T lawsuit hurt the BSDs, but there was lawsuit-rattling for Linux and GNU as well, so while others will point to that I don't think that was serious factor.
The SCO lawsuit was a joke and everyone knew it. A bare shell of a company, a mere coat rack they could hang a lawsuit on, was going up against IBM with evidence it wouldn't even release for an embarrassingly long period of time, and when it did, it was laughed out of Slashdot and Groklaw. Microsoft really didn't get its money's worth out of that little venture.
As for lawsuits against GNU, I don't know of any off the top of my head. Can you name one?
By the time things like the SCO lawsuit happened, Linux already had the momentum and corporate financial backing so it could weather it. Had that lawsuit happened in the early days, history would have likely played out differently. (i.e. imagine you were in college getting sued by AT&T over a project that barely anyone had heard about... I suspect most would decide to find a different hobby project)
When the AT&T lawsuit happened it had the direct effect of steering people from *BSD to Linux at a critical time for both, so I'd say that it was definitely a factor.
Some claim that the AT&T lawsuit hurt the BSDs, but there was lawsuit-rattling for Linux and GNU as well
Do you mean the SCO lawsuit against IBM? Because I would argue that 1) that happened long enough after Linux had established itself that people were too invested to be immediately scared off and 2) people put a lot of faith in IBM and there legal team to defend Linux. I think the community around Linux was able to basically laugh the whole thing off once SCO started presenting their actual "evidence".
Without a large company to defend it and the fact that no one had really started using it for anything serious yet made the AT&T lawsuit against the BSD's look a lot scarier at the time.
All good points by the way, but I do think AT&T rattling their sword did have a pretty chilling effect on BSD adoption as well.
I meant the USL vs. BSDi case. That case was, of course, focused on the BSDs. While GNU and Linux were independently implemented, I recall there being some claims at the time that the USL vs. BSDi case also implicated GNU and Linux.
The SCO vs. Linux/IBM/the universe travesty that attacked Linux came a little later; that started in 2003 and seems to never really end. There were also legal accusations around that time (circa 2004) about Linux raised by Kenneth Brown (from the Alexis de Tocqueville Institution). Both were focused on Linux and not on BSD, and both failed to slow down Linux.
Reasonable people can definitely disagree on whether or not the USL vs. BSDi legal case seriously impacted BSD adoption as compared to Linux. I don't think it was a key factor in the long run. The USL vs. BSDi case was raised in 1992, and resolved in 1994, so the legal issues didn't stick around very long. In addition, the BSDs had a head start and plenty of time to recover after the legal issues were resolved... if legal issues were the only problem. But again, reasonable people can disagree. We'll need two universes, where it did and did not occur, to really answer the question :-).
I meant the part where he mentioned but there was lawsuit-rattling for Linux and GNU as well.
I don’t remember anything before SCO so I was curious if there was something before that I missed.
I must admit I was downright obsessed with that case and Groklaw’s coverage at the time so I guess it’s not surprising that it was the first thing I thought of...
That's the first time I've ever heard GNU associated with the bazaar. The original thesis of the book (CatB) is the observation that GNU is a cathedral (with saint rms at its head) and Linux (the kernel) is a bazaar.
Yes, that's what I meant. It's true that many GNU projects were (and are) cathedrals, but their cathedrals were more like a bazaar compared to the BSDs. GNU projects tend to be run mostly-independently, but the BSDs were (and are) maintained as entire monoliths... kind of the ultimate cathedral approach. And while cathedrals are beautiful, they take hundreds of years to build, and that's a problem in the software development world.
It is if you know where to look or who to talk to.
That is the exact same question I was asked ~20 years ago regarding Linux vs Windows.
The barrier to entry is higher on *BSD then it is on Linux. But with the appropriate skills/time/energy it is very much worth the effort.
ALL of my edge devices run OpenBSD(since 2011). Most of my Internal servers run FreeBSD (90+%), with the remainder on OpenBSD. I made the decision to migrate away from Linux when SystemD was made default in Debian. In my mind they make more sense. I can grok the config files and Init process. MAN pages are much easier to understand. Network config is brain-dead simple and powerful; that's a combination that shouldn't be overlooked.
I freely admit that I'm an old-fart. My manager thinks I'm a hippy, and my co-workers think I'm a Unix-greybeard. In reality it's just this simple:
It does what I want, and gets out of the way.
This is pretty much my experience, too, almost word-for-word. I also run OpenBSD on my edge nodes and FreeBSD for most app servers. After using FreeBSD on servers for about two years, I felt more comfortable with it than I do with Linux after 20 years. A large part of that is FreeBSD's simplicity, consistency, and documentation. It means I can pull on a thread and follow it myself, often without resorting to mailing lists. On Linux, I often feel like I'm trying to piece together information from a variety of sources, sometimes outdated or not applicable to the distro I'm running. BSD feels more cohesive to me, and I think that makes me more self-reliant.
At a time when the commercial BSD companies were fighting among themselves and allowing their technology to become stale and remain expensive, Linux came along with RedHat and SuSE.
Those two made an effort to meet directly with business leaders, attend all the trade shows, and gave their product away for free. Their model was at least as shocking as their license; hitherto, hardly any business software was free and paired with consulting services. It caused a storm, and gave birth to a whole industry that wasn't possible under the expensive BSD model.
Even prior to RedHat and SuSE for some reason System V-based systems were deemed more suitable to business, at least by Sun Microsystems. I stand corrected based on beef's comment below: they migrated from BSD to Sys V as part of Solaris aka SunOS V. I was misremembering their adding streams support to SunOS 4 as the big switch but I was wrong about that.
SunOS 4 was still BSD-based. You can find the source code for SunOS 4.1.4 on TUHS's code comparison site[1], but for some reason, you can't browse the tree.
Solaris was when Sun made the jump to System V. AFAIK part of that was because Sun had financial difficulties at the time and AT&T offered to help them -- in exchange for Sun to rebase on System V.
A number of good replies in this thread, and I usually reach for the USL lawsuit as the go-to explanation, but another explanation I've heard probably has some merit as well: Linux came up from the PC world, whereas BSD came from academia and, later, techie companies.
Therefore, bedroom hackers would be more likely to be able to install Linux on the hardware they had, not the hardware they wished they had, so they'd reach for Linux when their employer wanted some kind of backroom system that didn't cost an arm and a leg.
Therefore, there was more Linux out there beyond the explicitly techie companies, the ones who'd have already bought Solaris or IRIX or HP-UX, and the current userbase drives both features and future userbase.
Because you can get the same technical outcome with using off the shelf Linux and setting it up to be conservative just like OpenBSD. (Or simply run sensitive workloads on separated/isolated machines.) The dreaded TCO is likely lower with Linux, because it's easier to work with, better drivers, better performance, more software available natively, and so on. (The whole Linux ecosystem seems more efficient for business, even if OpenBSD/FreeBSD is simply better in a lot of particular stuff.)
Without trying to sound facetious: "marketing". By that I mean the BSDs aren't trying to capture $$$ but seem to be focusing on good craft and sound engineering first etc and service markets where that matters more than other concerns. Turns out that market isn't as big as others.
Linux had more bleeding edge development, and that's what developers wanted, so that's what they wrote their apps for, and so that's what people used for workstations, so that's what got all the newest hardware drivers, and new kernel features, and new desktop work, etc etc.
Linux just had "more stuff". Without any other particular reason to pick one over the other, most people picked the one with "more stuff". Nobody wanted to install an OS for a server just to find out it couldn't run the latest software, or didn't have the latest drivers. In addition, the userland of the BSDs was different from GNU tools; if you were already installing GNU tools on every other OS you adminned, you might as well run the OS that's based on it. Finally, if you wanted Enterprise support, Linux was the only Open Source choice, afaik.
Some at the timed claimed performance benefits from one or the other, but various benchmarks showed Linux and BSDs each had their respective performance strengths that could generally be overcome by tweaking.
The BSD troubles rather than wars: it wasn't a spat between BSD distros, it was BSDi and UC (Berkeley) getting sued by USL.
It cast a long shadow over the viability of Berkeley at the height of the UNIX wars, and just as Linux was appearing as a completely independent and unencumbered UNIX supported by the maturation & advocacy of GNU and the FSF.
In retrospect, it's probably a good thing. BSD splinters have largely become incompatible with each other, whereas Linux distro splinters have (largely) remained compatible due to licensing and cultural differences.
We probably would have had BSD wars for real not long after, if it had become popular. To some extent, this is by design, as there's no culture or ethos that pushes people back together.
> whereas Linux distro splinters have (largely) remained compatible due to licensing and cultural differences.
Seems to me this had nothing to do with licensing or culture, but rather that if you wanted your distribution you'd use the upstream kernel and build your own userland with blackjack and hookers and whatever direction you were interested in, so there's some measure of strong relatedness in the kernel everyone shares. You might add a few modules or patches, but few people bother (or need) to fork the kernel itself.
Since BSDs are systems, if you want to go your own way you fork the entire system (that's literally the genesis of both OpenBSD and Dragonfly).
On the other hand, if BSDs had been more popular, one of these splinters might have dominated the market as much as Linux does, due to the many positive feedback effects of being the most successful free OS.
If you dont understand that you need to automate and manage your own packages (including containers) for Linux, which meet your requirements, then no framework will help you.
You also need to do this for any pipeline for any OS.
Not just for the core OS, but also in ports and also drivers (Intel, Chelsio, Mellonox).
FreeBSD in particular has always been persnickety about acknowledging work done on behalf of others. Something that would have prevented the IBM-SCO lawsuit if Linux had used commit/patch tracking from the beggining.
I have been using FreeBSD since 1999, a great OS and i love it, at work i am a Linux system administrator.
One of the huge reasons people use FreeBSD is simply licensing. If you dont want to release any source code simply build your custom app on FreeBSD and only include BSD licensed software. Makes being proprietary simple.
Note, this does not mean any companies that do this do not give back to the project, they do in the way of code commits and sometimes donations.
Companies that do not give back non-secret sauce patches will find they will contribute to their own pain (unless they're big enough to fork and not care about going back).
Isilon did not contribute back for a while, and then the FreeBSD project kept moving forward, and so the patches they kept in-house kept getting bigger and bigger, which was overhead in their development.
Because the large companies that deploy hundreds of thousands of servers need to hire lots and lots of people to make or maintain local enhancements, at all levels from the OS to libraries and utilities. In that environment it's not hard to make a local change that saves a million dollars in running-hardware costs, and it's also not hard to find Linux developers to make those changes. OpenBSD developers? Not so much. Then smaller companies do what the big ones are doing even when the potential for million-dollar enhancements isn't there, often because their founders and/or most of their personnel came from those big companies. It's the "rich get richer" effect familiar from social networks, but for software platforms.
The kernel teams at most large companies, even large tech companies, are not that big.
Sure, the pool of currently experienced Linux kernel developers is large compared to the BSDs, but if you hire a smart person (like a Linux kernel developer), and provide them with means, opportunity, and motive you'll have a BSD kernel developer soon enough.
Commercial support and network effects and costs of running multiple operating systems are more likely to be a deciding factor than developer availability. If you need to run someone else's software, it probably runs on Linux or Windows. If you run a BSD for your stuff, and Linux for theirs, that means you'll probably need more people to understand both.
If you're going to run on other people's hardware, Linux is almost always supported, although there's been some movement on BSD in clouds. Like with other niche platforms, if it's not currently supported and you want to do it, you might need to do the work -- there's a lot less community to rely on to magically make things work.
>The kernel teams at most large companies, even large tech > companies, are not that big.
It's not just about the kernel. You're talking about entire ecosystems of core utilities, filesystems, network stacks, security mechanisms, virtualization and resource-control subsystems (e.g. cgroups), performance profiling and tuning, etc. They're different systems from top to bottom, just like when I switched from 4.3 to V.2 thirty years ago.
> Commercial support
Stop right there. FAANG companies aren't going to buy support contracts. They'll hire the maintainers instead (like they did with me and hundreds of others like me at my current company). They're not going to split that effort across multiple platforms. They'll focus on one, then hire thousands of developers who don't even realize the tools and interfaces they use are Linux-specific. Then all of the wannabes will copy them, for the reasons I already mentioned. The network effect has gone way beyond any chance of reversal. Sorry.
In some places they are. For instance, net flix appliances use FreeBSD. One of the deciding factors here is licensing: Linux is gpl, meaning net flix would have to contribute back its changes, whereas by using a BSD-licensed alternative, it can keep those changes in-house for a performance advantage. You can dispute the merits or ethics of this, but that's the choice a good few people make. I believe yahoo used it for similar reasons. Some consoles (Sony Play Station 3, Nintendo Switch, possibly others?) use it internally, again so they don't have to open-source console code. Others use it for appliance-type devices, again for similar reasons.
you miss the other point of Docker: cross-platform dev (and only occasionally cross-platform deployment)...
I can run same set of docker containers that make up an app, including scaling multiple instances of each container, on (1) my macbook, (2) my ubuntu linux laptop, (3) my centos server (4) my windows laptop, (5) my other windows laptop, (6) my client's windows server.
I can do this without bothering to configure my app specifically, or without even knowing or learning what the dependencies of my app are!
BSD's are the "loner children" playing by themselves while everyone expects to have everything running everywhere and expect it by default...
Sorry, but unless effort is made to embrace kuber and docker, the niche will shrink.
One way out of the problem is to have entities like the FreeBSD foundation the OpenBSD devs invest effort into Docker development to make it capable of running BSD containers inside it... but this will never happen because of endless ego :|
... all 6 of which were running a linux vm until recently, and still predominately so (windows containers are hugely niche and have just about as much 'loner children' baggage in the larger commmunity)
writing a gui to spin up the VM flavor du-jour with one hipster command that you can show in an animated terminal in your bloated website doesn't make something cross platform underneath the hood, and that same VM runtime could run just about anything else.
and no, i don't miss the point. you miss the point - you are arguing market share as if it is technical merit. I'll take 1 true school unix hacker over 5 million 'noders' who cant debug their super hip k8s clusters they provisioned 'in the cloud' with wget|sh when they break.
> Because the people who pay folks to work on systems dont like to pay enough money to get that level of talent.
People like Google can't pay enough? Do all the BSD developers work as front-end quants or something? How are they all earning so much that nobody can afford them?
Yahoo! did but they also had BSD developers on the payroll.
Any Silicon Valley company will pay enough but that is why when you leave Silicon Valley or a big tech hub everything is windows. The pay attracts the talent.
You said the reason people don't use BSD was because the people who work on it are were too expensive. I know Google don't use BSD, but your idea that it's because they couldn't afford to pay BSD developers doesn't seem to add up, since Google happily pays Linux kernel developers maybe half a million dollars or more. Are the BSD developers really paid so much that Google can't afford them over the Linux developers? That doesn't seem likely to me. I think the reason they're not using BSD is something other than what you're suggesting.
when I said "Work on the systems" I meant support maintain care and feed.
Linux has become mainstream so there are more people in the talent pool to pay to support it.
Windows ... has more so it is cheaper
BSD simply doesn't have enough people who know the system well enough to support it
Paying 5 developers to build something cool doesn't mean you have the support system to run it.... You actually need people who understand your product to use it as a business system
there's only slightly more learning curve between Linux Distro X vs BSD Y as there is between Linux Distro X and Linux Distro Y.
In some ways & depending on the situation, moreso, since linux distros are often trying to do things drastically different from each other in order to differentiate themselves, whereas BSD's are often sharing code because of the small developer base, sharing-compatible license, and lack of bottom-line oriented corporate sponsorship.
Having worked in the industry for a couple decades and been interviewing people for the last decade I can tell you the number of people who understand low level systems management is not high.
Used to be a system admin could modify a kernel module in linux. These days its getting hard to find one who can use the CLI properly
Ubuntu kicking everyone into a 6 month release cycle pushed Linux, as a kernel and as a software ecosystem, forward a lot. Quality and quantity seem to converge over a long enough view.
I think it again falls into kernel versus whole system. Releasing an update to the whole system is more work than releasing the kernel.
Little orthogonal:
It sort of rhymes with the mono repository versus collection of micro repositories mindset. Does BSD have more code reuse since it is whole system?
In using both BSD and Linux based appliances, the Linux based ones tend to have more features (VyOS, etc.) and cover more hardware (OpenWRT, etc.) but aren't as long-term stable and problem free, as well as the BSD ones.
OpenBSD has much more complete and accurate documentation, which is a plus when you're debugging a problem.
I would opine that Linux won because it was familiar but not ideal - see also people trying to shoehorn Windows into embedded systems where a unix variant would be a more ideal pick.
State actors are now targeting whole populations. It takes less and less time to enumerate the entire IPv4 address space. Knowledge about hacking is becoming more and more accessible to a larger group of people. This problem is not going away - it is growing larger for every year.
If you don't believe me: Just attach an object to the internet and watch the logs.
Yep, but you have to grade it based on likelyhood. Which costs more, a thing that doesn't work right now or a thing that might not work in the future, maybe. If you can make it work now and be secure, good, otherwise people will, quite rationally, prefer that it work.
