Why is Linux more popular than BSD?
serverfault.com
serverfault.com
First encounter: I wanted to try BSD, but it would only work with its own partition format. You could not have a disk partitioned for both DOS/Win and BSD. The BSD folks didn't think that was important--if you really wanted to dual boot, get a second disk.
Linux could dual boot with DOS/Win on one disk, so I used Linux.
Second encounter: BSD did not support IDE CD-ROMs. When asked when they would be supported, BSD folks said IDE was not good enough for workstations and servers--get a SCSI CD-ROM.
The problem with this was that SCSI CD-ROM drives were around $400. IDE CD-ROM drives were under $100. If you were going to make heavy use of the drive, that $300 difference might be justified. Most people were NOT going to make heavy use of the drive--it would be used to install the OS and then sit unused until it was time to install the next version of the OS.
Linux would install from my IDE CD-ROM drive, so I used Linux.
By the time BSD got to the point that it could coexist well with DOS/Win, and didn't have ridiculous hardware requirements, Linux was sufficiently mature and established that there just wasn't much point.
As to the question at hand: Linux was more accessible and this was back in the pre-1.0 days (my first distro was ~30 5.25" disks of SLS downloaded over a 2400 baud modem). It happened to support hardware I happened to have.
Honestly at the time it ever even occurred to me to use BSD or even that I could.
And yes, the whole "not a good fit for the site / not constructive" is hotly debated, with many high-profile members of the community having left over it already. Personally, I don't see how you can have meaningful discussions about soft topics while maintaining the "supported by facts" rule. And unfortunately (for the site), most of the more interesting topics are "not a good fit".
The network is supposed to be a focused, solution-centred set of sites - as evinced by this from ServerFault's FAQ:
"You should only ask practical, answerable questions based on actual problems that you face. Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page."
They may have made some bad decisions but closing this thread ain't one of them.
And not infrequently, "those who were there" hold a diversity of opinions. Having access to these provides the reader with context.
I much prefer to have a few opinions on the table and form my own from them.
Also I don't have the ability to downvote crappy answers because I'm not special enough or something, which really irritates me to no end...
You need to accumulate 500 karma points, after which you can downvote. This is to prevent people opening throwaway accounts and instantly downvoting something they don't like.
Occasionally they do. But they take a lot of effort to moderate and generate negligible ad revenue, so they usually do not last long.
There's no other word for it.
1. They locked it when it got attention. So most people thought it was fine until some pedantic, overzealous admin noticed it.
2. Where else am I supposed to ask a question like this? These are actually really important question in understanding the history and context of why people make decisions.
3. There are plenty of problems which programmers face every day that have no definitive answer. Should I start a new namespace or not in scenario a? Should I use framework x or framework y? What are the long-term downsides to approach z?
These fit the SO model fine, it's just that there are a bunch of pedants out there locking these extremely valuable questions.
Also fracturing the community with all these different exchange sites is actually getting really irritating. programmers.stackexchange.com, for example, is filled with very poor advice to lots of programming questions that get upvoted as it seems to attract architect astronauts.
Actually, there are plenty of other words. Perhaps you should go and ask at english.stackexchange.com.
nailed it.
I originally installed NetBSD off QIC tape that was mailed to me by a friend at a university which had a decent connection :) It was plugged in via a large SCSI cable that only worked if you bent it in half and put a cable tie around it (it's innards were shredded).
Memories.
Just to add: StackExchange is a horrible pit of elitism. I'd rather deal with Usenet SPAM than use it.
Does anyone subscribe to a for-pay usenet provider that they like? Does it offer old school text-based client access?
It's free but they have a 25Gb cap which is fine if you're not leeching binaries (I'm not!).
I think SO should have a sister "discussion" site, and just move these interesting questions across instead of closing them.
386BSD was extremely buggy, and Bill Jolitz was dismissive about the community effort to improve it. He appeared from his Usenet posts to be in some kind of emotional pain. Without a natural leader, the community fragmented. One group made a "patchkit" to collect fixes to the official distribution. Another group cut ties, making their own distribution (NetBSD). Eventually the patchkit group also got fed up with Bill Jolitz lack of cooperation, and released the patchkit version as FreeBSD.
Meanwhile, the Linux people seemed to have fun. Linux was even more buggy and far less featureful, but was improving fast from the collective effort of the community. Sometimes they made (for an old Unix person) atrocities like "color-ls". And their willingness to diverge from old Unix paradigms did make their software more convenient. color-ls is actually kind of useful.
The Linux developers seemed to consist of college kids being enthusiastic about a hobby they all loved. The BSD developers seemed to be hard working software professionals, making great personal sacrifices for a BSD cause. The first group was simply more fun to be around, so the community grew faster, especially among college students.
When the college students graduated, they took Linux with them to their new jobs.
...
Come to think of it, it actually mirrors the early BSD vs SysV UNIX cultural divide. Or even early Unix vs pre-Unix OS's.
Must be, I don't remember ever hearing of Bill Jolitz. And I've used (Open)BSD to build firewalls back in the day.
Also Linux has the GNU utilities (GNU grep etc), which were somewhat more featureful than the BSD equivalents. I know they can be installed on *BSD though the ports system but as I was new to unixy OSes, having a lot of packages installed by default was great.
I have no idea how it is these days, Linux just stuck.
By that point the BSDs supported most common hardware and didn't suffer from fire and forget IDE drivers which corrupted my Linux servers at least once per year. Although they were slower they just seemed to work. Combine that with a rational layout of /etc /usr/local/etc and all the other places that UNIX's squirrel away files and BSD just stuck for me. I haven't looked back as far as servers go.
The desktop is another kettle of fish though. Ubuntu is still far better than PCBSD but both are still lightyears away from the polish that windows/mac desktops have.
Back in the 90s there was a major push to market Linux by a wide number of vendors from Red Hat to IBM if I recall correctly. In the dot.com 1.0 era you couldn't leave a tradeshow without being given a t-shirt or stuffed toy of the tux mascot. You could also go into a bookstore, but a book on a book on Linux and get a free CD with an installer. You could also go into a computer store of that era and buy a boxed copy of Linux. This made Linux really popular with the first generation of web geeks.
Now, the standard narrative here is that BSD was under a legal cloud in the early 1990s due to the USL v. BSDi lawsuit, but BSDs still existed in 1993, when the lawsuit was settled. Was the Linux marketing machine that dominant in 1993? Even before the kernel had hit version 1.0?
(Note: I'm currently investigating a "cheapest to maintain" solution, and by this I mean man-hours, not upfront costs, so I could choose Windows Server just as well - not that I would do that - for both my personal server and the servers of a bunch of NGOs that I help with sysadmin stuff for free... and was wondering if something like FreeBSD was better than Ubuntu Server LTS ...I want something that I could just "drop it there and leave it running for 5 years", but at the same time there will be some packages - like webserver and related that I will want to keep to the latest stable versions, like upgrading every few months or so; and yes, I do care about security, so being of to date on all security fixes and at the same time not having to keep fixing an recompiling stuff...)
Disclaimer: I am an OpenBSD fanboy because it opened my eyes. OpenBSD's base system already solves 90% of my problems with exactly one, perfectly maintained and documented solution. You want a firewall? Choose between pf, netfilter or something else on FreeBSD. On OpenBSD the answer is "use pf" (which is btw by far the best paket filter I every experienced). The port system just works, is up-to-date and has good default configurations (and I never missed a package). Maintenance is very easy. It is not as easy as apt-get update && upgrade but the release upgrade (every 6 months) never broke anything on my systems (and takes just 10 minutes). Besides that, there is nearly nothing to do. Here is the bug/update list of the current release (5 months old): http://openbsd.org/errata51.html The last thing I want to mention now is the consistency in all tools. For network configuration there is ifconfig which can just handle everything (e.g. on linux you have to use special tools for wlan). You have great manual pages. The manual pages are real manual pages with introductions to the systems, various high level topics down to device nodes etc. They are completely up-to-date and the best source for all informations.
I think that sums it up. Why should I use Linux?
BSD definitely can't do everything that Linux can do, but it can do most things, normally the most important things, and it can do some interesting things that Linux cannot.
For programs that only are available on Linux, BSD kernels can run Linux applications.
It's a little painful using Linux after you become accustomed to BSD. Linux is really fast, but it's too random, sometimes even chaotic, and it seems disorganized by comparison.
But for people who are used to Linux there seems no reason to switch. Linux has lots of resources behind it to keep up with new hardware. BSD will never be as quick to produce drivers.
I'd love a stackexchange site on history, for example. but there's no single question on history that wouldn't get moderated away with moderators like this.
Except "Does the majority of expert believe that <question>?", of course. And yeah, that'll help.
If you count OSX as BSD than far more people use BSD desktops than Linux desktops. But if you count iOS and Android then it starts to become a toss up.
Either way, I assumed we were talking about things that are more commonly held as BSD and Linux. In which case the question doesn't even specify desktops - linux is the dominant OS in the server and embedded markets.
I know OSX is a valid and real UNIX, and the kernel is a mach/BSD hybrid, I'm just not sure I'd count it as a BSD when the question is 'Why is linux more popular than BSD?'. IMHO the question implies Open/Net/Free/Whatever BSD, not OSX. What makes OSX popular is a whole variety of things, many quite separate to the things people find appealing (or not) about the BSDs. IMHO, YMMV, etc etc
Debian/FreeBSD isn't linux because it doesn't use the Linux kernel. I think there is more question as to wether most Linux distributions are Linux or GNU/Linux than whether Debian/FreeBSD is Linux.
Hopefully RMS doesn't read this comment.
I don't disagree with any of what you're saying there, I just think it's a very grey area where you have multiple kernels and userlands, some of which are fairly easily interchangeable. And yes, most linux distro's are GNU/Linux (or at least something/linux) where Android/Linux is quite distinct.
I think it's not really the same thing as "worse is better" when you are comparing a implementation effort started from scratch competing with a legacy code base. Of course it will have less features at first. The (more) open development from the start, friendlier community and BSD fragmentation then won people over.
I'm a long BSD fan, worked professionally on FreeBSD kernel and used OpenBSD a lot (and still do!).
However you can find BSD in many appliances and if you have a Mac, you use FreeBSD!
I think one reason could be that they follow different philosophies: as end user you're going to use a Linux distribution, that includes a kernel, userland tools, applications, etc; whilst in BSD the kernel is very integrated with the userland tools and the base system includes a lot of functionality that can be completed with the ports (package system), so you're using the BSD system + some packages.
I enjoyed FreeBSD from 4.1 to 4.10 as desktop OS, and OpenBSD from 2.8 to 3.8 (web/mail servers, but firewalling mostly), and upgrading was a difficult task. I must thank to these operating systems I have the sysadmin skills I have now ;) Back then (I don't know if things have changed) you had to upgrade the system, while in Linux you could download the latest version from kernel.org, compile and install (ABI/API didn't change frequently, at least).
This different philosophy has pros and cons, and I believe one of the consequences is that Linux is more popular than BSD.
Linux has always been better at supporting a wider array of consumer hardware than *BSD. That combined with the Unix(TM) lawsuit lead to the quick early commercial success of Linux on 32-bit Intel hardware. The rise of the internet did the rest.
Judging from the tenor of some of the responses, I'd say it still is... oO;
The free/net/open/dragonfly forks may all be interesting, but they fragmented the community. I'd blame the lack of a single strong leadership.
The BSD Benevolent Dictator For Life? Nobody. The BSD world has been fragmented since the 1980s at least; even before the proliferation of Open Source BSDs, there was a little tribe of closed-source BSDs being sold by workstation manufacturers and going up against the similarly closed-source System V OSes to be King of All Unix.
I suppose my point is the BSD universe long predates the modern concept of Open Source and, therefore, a lot of the current practices surrounding Open Source software.
A proper package management system and binary packages might have saved FreeBSD in the data centre; maybe it could still do, though it's a very long shot now. It's a shame really...
Linus was a 386BSD user, or hoped to be. A lawsuit stopped people like him from getting their hands on the BSD code to play with, so he wrote a UNIX clone himself using MINIX as a model. Eventually the legal situation with BSD was cleared, and BSD became free and available to everyone, but that wasn't until 1993 or so. And even after the lawsuit some people still wanted to make money selling BSD for the PC. (They failed.^1) By that time, lots of people had already shifted to Linux as the "free" available UNIX as it was readily available. Why pay for CD-ROMs of BSD when you could freely download Linux via FTP?
1. But just look at Apple. BSD is in lots of commercial products, though you might not always realize it.
Torvalds himself said that he couldn't use 386BSD because it required the 80387, which he didn't have.
http://www.linuxbsdos.com/2010/02/18/freebsd-and-the-gpl/
Apparently this is wrong because I misquoted. Damn.
The gist of what I was trying to say, poorly perhaps, is that in 1993 Linux was available, it was free and it worked on previously DOS-controlled, home PC's. BSD wasn't as available nor as ready for use on the home PC. At least not as I remember it. It certainly is now. But it wasn't then.
There's lawyers that "take action". Then there's lawyers who advise. Senior management gets advice from a few sources and then makes a decision. If that decision involves lawsuits, patents or any other type of legal action you can be sure the idea originated with lawyers.
http://serverfault.com/questions/5095/historical-question-wh...
Yes, but a runner-up would be operating systems that can use each other's code, as is often the case with *nix-like operating systems. Given the natural tendency to fork operating systems, at least there's a way to cross-port code that works in most cases.
Oh -- I just realized you're asking this from an individual perspective. The answer is still yes -- you're better off focusing your attention on one OS. If you don't, you'll be competing with people who do, and they'll be more productive.
It usually has non-working vi (beeping at the sight of arrow keys), ancient shell, colourless ls and other commands lacking about every other key I throw into them.
I understand that BSD has traditions to do exactly that that you will now defend, but those traditions are not unlike muslim africa that tell them to circumcise young girls or kill for blasphemy. Traditions are baaad, mkay? Not gonna get any new users with traditions. Admit that getting new users is not any of your priority and you lost because of that.
Technically BSDs were always interesting, but you can't bring yourself to use this awkward tool.
Not exactly classy, arguable, but not out of the line either.
Coloured "ls" is one of those things that is absolutely entirely useless if you actually know how to use ls.
I find all BSD derivatives to be professionally documented, extremely reliable and with very few hidden surprises.
Compared to digging through GNU info and the utter bloat that most of the GNU toolchain has become[1] and favourite system tool dependency hell replacement of the hour (upstart, udev, dbus etc) it's absolute bliss.
[1] *BSD distributions are all slowly phasing out GNU toolchain due to these problems.
You're lucky, vi didn't work for me. Perhaps my terminal is to blame, but it works with Linux.
Knowing how to use non-colored ls is way down my priority list now that colored ls is widely available, much the same way learning more about ed is not a high priority for me.
> GNU info
GNU info is much more useful than man pages, which are, at best, memory aides for people who already know the software and, at worst, confusing masses of trivia that beg to be broken up into multiple pages.
> bloat
In my experience, 'bloat' can be defined as "any feature I'm not using at the moment" or, if I'm feeling cranky, "any feature that I feel allows people stupider than me to be productive using my favorite tool". It is a snarl term of the first water, with no value except to express a negative emotion.
Knowing how to use non-colored ls is way down my
priority list now that colored ls is widely available
GNU info is much more useful than man pages, which are,
at best, memory aides for people who already know the
software and, at worst, confusing masses of trivia that
beg to be broken up into multiple pages.
A clear advantages to BSD is that tooling man pages are produced by a single team. They're more consistent and generally of a higher quality than on linux. In addition, tools tend to do one and only one thing, which promotes use of pipes and scripts rather than obscure tool features.
This has precisely nothing to do with whether ls colors its output or not.
> A clear advantages to BSD is that tooling man pages are produced by a single team.
They're still too short to really introduce any tool complex enough to need documentation.
> In addition, tools tend to do one and only one thing, which promotes use of pipes and scripts rather than obscure tool features.
BSD has find. I know it does.
I can read the output of "ls" just fine without color. I use systems without colored "ls" daily. But... I find color in "ls" invaluable.
Color conveys information in a very unobtrusive way (if it isn't excessive). Much better to see blue text and knowing immediately that it's a directory, than looking at the permissions column or warts ("ls -F").
Actually, colorless "ls" makes the system feel old. It's the feeling I get every day when using AIX, for example. I just feel like changing the color scheme to green-on-black or amber-on-black just to feel like the old days.
I've never experienced any of these problems.
vi always works for me and has done since about 1997.
[Although I've tested this on openbsd this morning, and even that seems to be supported now - a shame, it promotes bad habits.]
I'd guess that (like me) guard of tera came to unix via a redhat derivative, and developed all sorts of bad habits there which makes the transition to other unixes more difficult.
For me, this is a major reason for the success of linux with young developers - it makes some things easy and friendly, but in doing so locks you in to expectations that stymie your development. Not unlike Microsoft Word.
Coloured "ls" is one of those things that is
absolutely entirely useless if you actually know
how to use ls.
I use hjkl for navigation in vi as it's the lowest common denominator. It's always there. I use vim these days (with syntax highlighting!), but I barely get past the basic "classic vi" command set.
I came from a VMS, RISCiX, SunOS and Solaris background and I generally tend not to use conveniences that often. I'm mindful with respect to portability having had to move code from HPUX en-masse which wasn't fun. The plus side is scripts that I wrote in 1994 still work fine :-)
I'm not a fan of easy - only a fan of simple, elegant and right.
And I'm not getting off our lawn.
I've never really considered the socket API in terms of whether it's good or bad - it's just part of reality. But I'm interested to know more.
But I do think they're way too overexposed. It's a very low-level system, with lots of related system calls, ioctls etc., requiring the user to do all the error checking, setup and boilerplate. All error-prone, too many L3 addresses passed around and altogether a mixture of several decades of network programming.
Assuming that's all really necessary on the lower levels (don't want to get into that, not my area of expertise), it's still not something a common systems programmer should face. You might know about the details, just like you know about TCP/IP packets, network layers etc, but more 80+ percent of your day job you shouldn't need to care about that. It's like constructing output piece by piece, with print_number(12); print_string(" / 2 = "); print_number(12/2); print_newline(); etc. Nobody but the most ardent DJB fans would want to do that. But for sockets it's basically expected. Network programming would've needed a printf-style interface from the early days, now it's too late to wrap the basic, the proliferation of incompatible high-perf syscalls didn't help.
I don't want to appear like one of those smug Plan 9 purists, but they did something right. Apart from treating network communication and file systems the same way, they also had some nice wrappers for the lower level stuff, e.g. http://swtch.com/plan9port/man/man3/dial.html
But yes, I'm mainly joking about "bad karma". Getting something right in the first place is hard, and often you don't get second chances.
I tried FreeBSD & OpenBSD repeatedly over the years, even running a key company server on OpenBSD for awhile in the late 90s / early 2000s - security was compelling - but I noticed two things:
1. BSD users treated updates like going to the dentist and put them off until forced - not without cause, as ports frequently either broke things or simply spent hours rebuilding the world - whereas Linux users generally spent time working on their actual job rather than impromptu sysadmin. "apt-get update && apt-get upgrade" had by then an established track record of Just Working and fresh install time for a complex system was measured in minutes for Debian (iops-limited) and, even as late as 2004 or so when we ditched the platform, days for FreeBSD even when performed by our resident FreeBSD advocate. I'm sure there are ways to automate it but while routine in the Linux world, I've never met a BSD user in person who actually did this.
2. The BSD systems were simply less stable, often dramatically so, because the parts were never tested together: you had the kernel which is stable and deserves significant respect but everything else was a random hodgepodge of whatever versions happened to be installed the last time someone ran ports. Unlike, say, Debian or Red Hat there was no culture of testing complete systems so a few months after a new release you'd often encounter the kind of "foo needs libbar 1.2.3 but baaz needs 1.1.9" dependency mess which required you to spend time troubleshooting and tinkering – a class of problem which simply did not exist at the system level for most of the Linux world. It wasn't as bad as Solaris but the overall impression was more similar than I'd like.
One other observation: during years of using Linux, FreeBSD, OpenBSD, Solaris / Nexenta / etc. on a number of systems (the most I've managed personally at any point in time was around ~100) there were almost no times where the actual kernel mattered significantly in a positive direction. Performing benchmarks on our servers or cluster compute nodes showed no significant difference, so we went with easier management. On the desktop, again no significant performance difference so we went with easier management and better video driver support (eventually why many desktop users moved to OS X - no more GL wars). There was a period where more stable NFS might have been compelling but the BSD and Linux NFS clients both sucked in similar ways (deadlocking most times a packet dropped) and the Linux client got better faster and we ended up automating dead mount detection with lazy-unmounts to reduce the user-visible damage.
Not typical of any BSD sysadmin I've known, ever. OTOH if your "BSD users" were not sysadmins that would explain it.
install time ... days for FreeBSD even when performed by our resident FreeBSD advocate
Clearly your "FreeBSD advocate" did not know what he/she was doing. Without provisioning a FreeBSD install should not differ from an Ubuntu or RH install by more than a few minutes (in either direction).
But in a datacenter provisioning is critical, and FreeBSD ceeded that space to RH's kickstart long ago. BSD also tied a ball and chain deprecating multi-partition default root volumes (when 1G drives became commonplace.
But more than anything else FreeBSD lost this race by not developing user-friendly installation software (GUI or CLI).
But for those who do know how to install BSD and the difference between things as fundmental as portinstall vs makeworld the ongoing time spent updating and upgrading will pay that back may times over. This is because: A) the ports system works across _all_ versions and architectures i.e., you don't have to upgrade the entire OS simply to upgrade say mysql to 5.5, B) OS upgrades break far fewer apps in BSD than any version of Linux, C) kernel vulnerabilities average once every few years in BSD vs ever few weeks (sometimes days) in Linux, and D) backwards compatibility is far better (recall when RH tried to "deprecate" nslookup for example).
The BSD systems were simply less stable
This would be due to your user-sysadmin's skillset as everyone else's experience is the opposite (as noted in the OP).
Professional sysadmins - but obviously more conservative than ones you know. That was the base install, a ton of ports and mucking around getting video drivers, etc. installed. This is for a fully-configured scientific workstation, not just a bare OS install, so there were a couple hundred packages installed by the time you include all of the various dependencies.
I'm certain that binary packages would have shaved a lot of time off of this (that's what I used to use on OpenBSD a decade ago) but that wasn't exactly strongly recommended at the time, which is why I mentioned culture — I'm certain you can manage FreeBSD better but in practice I have yet to meet anyone in person who actually does this. Small sample size and all but this is untrue of any Linux user I've met other than the Gentoo fanatics who consider tweaking CFLAGS a source of entertainment.
> A) the ports system works across _all_ versions and architectures i.e., you don't have to upgrade the entire OS simply to upgrade say mysql to 5.5, B) OS upgrades break far fewer apps in BSD than any version of Linux,
A) is comically untrue: not only can you easily compile newer packages but extensive backports repositories exist to make it easy and safe to install a new version of something important while keeping the rest of the system stable. For many distributions this exists as a vendor-provided service and there are others (e.g. IUSCommunity.org) which serve particular markets and a fair number of OSS projects maintain repos for the Debian & Red Hat worlds.
B) may be true in your experience but it's radically unlike mine. I've run many versions of Linux on many systems over the years and upgrades have been quite smooth - the Debian / Ubuntu world is the most stable but Red Hat isn't far behind. The key again is binary packages - moving from a known set of packages to a known set of newer packages makes it a lot easier to test an upgrade.
> C) kernel vulnerabilities average once every few years in BSD vs ever few weeks (sometimes days) in Linux
Highly debatable but Linux or BSD kernel vulnerabilities are rare enough not to be worth arguing over: most of the threat is in userland, which is a large part of why package management is so important. Far more systems are compromised by lax updates rather than zero-days.