This page appears to be positively ancient, referencing FreeBSD 5 and Red Hat 8, and a bunch of the technical differences are incorrect now; the Linux kernel hasn't used stable/unstable versioning in forever and is entirely on git, every GNU/Linux distribution has easy binary package dependency resolution and retrieval, etc.
It's my impression that the discussion about ports, "full range of bits", "assurance that it works" vs. "decentralized" misrepresents Linux distros, or at least Debian - apt provides the full range of dependency tracking, package configuration, etc., and Debian maintains a centralized repository, often with local patches (just like ports), where things are guaranteed to work. The only real difference is the emphasis on source vs binary, which is important but not as fundamental as the article suggests.
Edit: And later on...
The individual releases of a given distribution are much more independent of each other, so it's harder to turn your RedHat 7.3 system into a RedHat 8 system. [...] With a Linux system, however, you tend to find yourself trying to keep a handful of obvious things upgraded, while others get further and further behind, until eventually you just reinstall with the latest version to bring it up to date.
That may be true for RedHat (which I've never used), but Debian has always had good old apt-get update && apt-get dist-upgrade to bring everything up to date.
The article seems to be a little old: "Netscape's browsers, Opera, some office programs, RealPlayer, etc."
Your comment "The only real difference is the emphasis on source vs binary, which is important but not as fundamental as the article suggests" reminds me of a line from someone about compiling kernels: new users use the default kernel because it just works, power users compile their own kernel and are able to eke out a bit more power, and experienced admins use the default kernel because it just works...
Indeed the memories I have of Mandrake and RedHat is a package management nightmare, where not enough things were in the official repos, urpmi had to be installed after the fact, you had to add many third-party repos and/or many standalone rpm packages. Often you'd end up with X.rpm needing Y.rpm v1.1 and Z.rpm needing Y.rpm v1.2, and you had to be really cautious not to screw up your system.
Now the argument that with BSD and ports you have no library problems because you compile everything from source and the ports are all centralized is, well, wrong. Say you install X and Y which depend on libZ; you then upgrade Y, which pulls in a new libZ, which breaks the unchanged X (since it has been built against the earlier libZ). That is, unless you rebuild X to link against the new libZ. Even heard of Gentoo's revdep-rebuild? Hopefully this is mitigated on FreeBSD (and conversely made comparatively worse on Gentoo) because base components do not get bumped like that, so most things link against the seldom moving base and you're done (whereas on Gentoo, you have fun bumping libc or libxml).
I agree, though the extend of that depends on what you put on the machine and it's use.
On a typical server, with less that 100 external ports installed, FreeBSD will rarely need to rebuild libs, because most of the stuff links to the base.
On a typical desktop, with > 1000 ports installed, things get very messy. And the legacy package management of FreeBSD shows its limits. Things are improving, mainly with a move to improved binary tools, but it's been behind linux for a long time.
It _was_ maybe true, kind of, sometimes: config files were not always marked as config files, for example.
It's definitely no longer true now. On Fedora you run preupgrade. For RHEL point releases, yum. For RHEL major releases, you need to run a kickstart upgrade.
FreeBSD is (more or less) moving towards pkgng, which has roughly the same goals. I'm not sure what the OpenBSD guys are doing
And yes, it's only for distribution. But if it works well, it's the only thing end users should care about. Though I'm not exactly sure the BSDs have basic end users in the way linux does.
> FreeBSD is (more or less) moving towards pkgng, which has roughly the same goals.
Yeah, but the BSDs always had pkg_add and other pkg_* tools, pkgin is just a nice alternative that works on more than one system... I don't believe it provides any crucial feature that was missing in the pkg_tools.
> And yes, it's only for distribution. But if it works well, it's the only thing end users should care about.
From OpenBSD's FAQ:
The ports tree is meant for advanced users.
Everyone is encouraged to use the pre-compiled binary packages.
Basically, if you're running unmodified OS (i.e. official release) and don't enable any options disabled by default in the ports then you're just wasting CPU power rebuilding stuff that you could easily grab from the nearest mirror.
As far as I can tell, there is no tool in FreeBSD base that provides a simple way to check and update all ports using binaries. FreeBSD's pkg_add only handles direct installs of new packages. Upgrade management, things like "update everything" or "update this package and its dependencies" is usually done through one of the external tools like portmaster, portupgrade, pkg_upgrade, etc. Which interact with the ports tree and pkg_add behind the scenes, but with additional info on dependencies to keep the whole thing sane. They do the job okay, but they all have their quirks.
From its man page, it seems OpenBSD's pkg_add supports updating (and a lot of other things), so I guess they don't have this problem to start with. That's interesting, I wonder why the feature is lacking on the FreeBSD side.
Yeah, these comparisons suffer from the fact Linux really is just a kernel: There's no single Linux community, no single Linux technical standard, etc. Instead, we have Debian, Red Hat, Slackware, Ubuntu, SuSE, etc., all sharing software but not necessarily sharing culture or methodology.
(And on the Linux side, we have people who apparently believe that the distro you choose determines what desktop environment you have to run. If I hear about one more person dropping Ubuntu because of Unity ... I'll get more confused, I suppose, and wonder why they don't just install Window Maker or Xfce or something else from the package repos and use that, instead.)
It would be more enlightening to pick a specific distro to do your comparing to, as a specific version of a BSD project (OpenBSD, say) is more comparable to a whole Linux distribution than to a specific version of the Linux kernel.
Then you have missed the point of the article. The intro even says that the point is to compare the Linux world with the BSD world, not specific distros. The author highlights - stresses even - that there is no homogenous Linux community, that Linux development is 'chaotic' compared to BSD development, and that that chaos is the source of Linux's strength. That sense of chaos is the core shared culture in Linux.
What you want - distro-to-distro comparison - would suck; and age rapidly.
I used to be an Emacs user and felt rather mediocre about it, and then I tried Vim at the recommendation of a colleague and after some discomfort (like maybe an hour's worth), I was absolutely enamored with Vim in a way I had never been with Emacs.
Based on similar reasoning, I've been trying to get into trying BSD lately, as a current and avid user of Linux. I wish that this article would have addressed a bit more about the author's subjective experience of using BSD, as this is currently the sort of thing that would be helpful for me in considering FreeBSD as a desktop OS. The main thing that I have to reconcile currently is the fact that BSD isn't on the bleeding edge like, say, Arch Linux. To give a specific example, until recently, mesa lacked full support for the Sandy Bridge mobile GPUs, and so I couldn't play Minecraft on Linux. Pretty much as soon as a version of mesa with support for Sandy Bridge was released, Arch had it in the repositories where other distros would have lagged weeks behind. Of course, I could alter my lifestyle so that I wasn't always using such new hardware or didn't care so much about being able to play Minecraft without using Windows, but that would require FreeBSD being worth it in some other big way.
I find it strange that I used to enjoy debates like this, around the time the article was written. I was so fascinated with operating system kernels and base system layouts then.
I've been a Linux-on-the-desktop user since 1998 or so, and started using it full-time in 2001. Having grown up on closed & proprietary operating systems with "black box" operation, I found it amazing how transparent everything in the UNIX world was, and how much control you had over your machine.
Lately, I've just been happy that my laptop hardware finally works "out of the box" and with minimal tweaking, so I can get on with my life and focus on the things that matter (I'm a software engineer, so get on to coding & designing software).
I fear that simple usability and hardware frustrations caused many people who would have been Linux/BSD users over to Mac OS X -- a proprietary & closed system that at least has BSD roots. Linux may not be the best kernel design ever, but it's a Free operating system with serious UNIX roots and astoundingly good hardware & software support.
In my current work as an engineer of large-scale web applications and distributed services, I find that kernels and base operating system layouts are playing decreasingly important roles. We are automating these details with tools like Puppet and Chef. We are spinning up Linux machines in virtualized providers like Rackspace Cloud and Amazon Web Service. We want to forget about these details and get on with our lives.
We just need something that runs on our physical or virtual hardware and runs our stack of open source databases, programming languages, and services. We need something that just works.
I only came across one place, recently, where operating system choice seemed to matter -- and that was in the deployment of a pair of physical network router boxes in a colocation facility. For that, we chose OpenBSD over Linux due to its out-of-box better support for high-availability networking, packet filtering, load balancing, etc. But I can't think of another time -- desktop or server -- in the last 5 years where it has made sense to choose BSD over Linux.
However, I recently bought a few small and tiny VPSs and installed FreeBSD on some and Debian on others. For identical setups in terms of apps and daemons, FreeBSD is using only roughly 2/3rds the memory of Debian.
So there is a cost advantage since the tiny VPS running FreeBSD is cheaper than a small VPS running Debian. But a tiny VPS may not have the reserves to survive a slashdot. Swings and roundabouts.
> Lately, I've just been happy that my laptop hardware finally works "out of the box" and with minimal tweaking, so I can get on with my life and focus on the things that matter (I'm a software engineer, so get on to coding & designing software).
For me, that's Ubuntu on Lenovo hardware. I'm not trying to push this setup, just respond to the idea that 'just works' means you have to use a Mac.
Just wanted to second this. I've been using Ubuntu on Thinkpads since 2006. It's been 5 years since I really had to deal with the Ye Olde Unix Desktop problems of yore ("why doesn't my wifi / digital camera / suspend resume / etc work").
It's been the same disk image and /home partition this whole time, too -- no full system reinstalls. I just keep upgrading to the oldest supported LTS release, which might have something to do with the fact that everything "just works."
Interestingly, his conclusion about why he uses BSD matches exactly with why I use Linux. Personally I haven't used BSD very often or much. In the same way the OP says he's picked the right OS for him, I've picked the right one for myself and could underline my choice just as strongly.
There just is no one true answer to this debate. Each to his own liking.
Is it valid to lump together all system with a linux kernel and then talk about the user experience? The user experience differ quite a lot depending on if you use debian, redhat, ubuntu, android, Mandrake, and so on. Sure, they can all be modified to be more or less the same experience, but the amount of modification needed to make a redhat user experience the same as a debian user experience is so large that you may just easier start with compiling your own kernel and go from there.
It is 2012, it is time to stop comparing BSD with Linux and start comparing FreeBSD with Debian, or OpenBSD with redhat, and so on.
My only problem with split articles like this is when reading with Pocket(Read it later) I end up having to follow the rest of the links and add them individually.
The main reason I got into the BSDs years ago was because of the ports system. I remember having a fun time with dependency hell that was on all Linux distributions. Then a friend showed me OpenBSD and did a "make install clean" from the ports tree, downloading all dependencies and installing them too. I was hooked.
Linux distributions eventually caught up and made software easier to install, but I've stuck with the BSDs.
I think it's funny (and great) that's a lot of OSX users "support" FreeBSD and BSD in general because of OSX using part of the userland of FreeBSD. And it's funny when they said "not been able to get it with Linux".
I've often wondered why BSD is not more popular as a desktop system. Since it seems more "stable" it would surely make an easier target for development?
There must be a reason Apple chose it instead of Linux to be the core of OSX.
OS X is not really a BSD. True, its userland comes from a mish-mash of NetBSD, FreeBSD, classic big-U Unix, and OpenBSD, in roughly that order, but xnu is not a BSD kernel, and while it supports many FreeBSD APIs (e.g., kqueue), that's done by reimplementing those APIs in xnu, frequently via gratuitous copy and paste, but definitely not by using a BSD kernel.
I mention that not because I want to be pedantic, because there's a huge gap between "OS X is using some BSD components" and "BSD would make a great desktop operating system." The one doesn't imply the other.
That said, there is a fairly nice desktop OS, called PC-BSD, you can take a look at, that is FreeBSD with a KDE-based UI. Not my cup of tea, but you can check it out at http://www.pcbsd.org/
Apple couldn't choose Linux as a core of OSX or iOS even if they desperately wanted to, because GPL would expand to entire "collective work" including closed-source userland tools (if they are distributed together with a kernel as a single downloadable and installable package).
If Linux kernel would have been licensed under LGPL, or CDDL, then it would be possible. But GPL is too viral for such thing to happen. It was specifically designed to crash the barriers of closed source code and expand itself to entire derivative or collective works.
> Since it seems more "stable" it would surely make an easier target for development?
That's not really an accurate statement - you can have very stable Linux distros, and you can have very unstable ones - same goes for installations of the BSDs. (Not to mention that 'stable' is in itself an overloaded term).
One may be better for an individual use case, but I don't think it's possible to say that BSD is more stable than Linux (considering that you're not even comparing like quantities there!)
Although there's little to no doubt that Linux was evaluated for Rhapsody (and probably rejected for licensing reasons), another explanation is simply that Free and NetBSD represented a more direct upgrade path from NeXTSTEP's existing 4.3BSD codebase. Since the goal was to bring NS into the Apple ecosystem and explicitly not to create a new OS altogether it would make for the obvious choice.
It may be just me, but I tried using FreeBSD on my laptop. But sadly some software do not have distribution for BSD. I could not get eclipse working. And Android SDK is not available for BSD too. And it was a downer for me.
Even my limited experience with FreeBSD shows this is a falsehood. New major releases should basically be ignored due to all the bugs, especially concerning device drivers.
