Your browser doesn't seem to support CSS, which this page uses for all styling. Don't be surprised if it looks kinda boring.

[Jump to nav]


Ah, now this is the part I enjoy. Lots of soaring generalities, without a single hard fact in sight. Saves the trouble of having to do research. 8-)

What I'm going to discuss here is some of the real and imagined philosophical differences that both cause, and are caused by, some of the technical and organizational differences we've discussed. Like most such discussions, there's little that's hard-and-fast here; there's plenty of overlap in attitudes among people in the various camps. And there's certainly plenty of completely deserved flak for both sides to take, as well as undeserved flak they've been forced to. Still, I think it's important to examine some of these splits, without trying to presume that one is "correct" and the other is "incorrect".

Realize, I must emphasize, that a lot of this is very general. Practically every point is riddled with exceptions. And both systems often don't "follow the rules", or fail to meet their own expectations. It's more a question of inclination that of exceptionless implementation. I'm just saying this now, so I don't have to keep qualifying and re-qualifying every statement I make, until it's impossible to read.

Chaos vs Order

One common generality is that the Linux methodology is the living incarnation of chaos, whereas the BSD methodology is far more about control. To a large extent, it's true. Linux grew out of a spare-time hacking background, while BSD grew out of a controlled engineering background. Of course, there's plenty of weekend tinkers writing BSD code, and plenty of full-time professional programmers sloughing away at various parts of Linux. But the feel of the systems still does reflect that sort of schism.

We've already discussed the construction methodology; BSD builds up a core system which is uniform, whereas Linux distributions takes pre-existing pieces and pretty much puts them together helter-skelter. Naturally, the BSD method is far more amenable to keeping things ordered, while the Linux method practically necessitates utter chaos. That's not to say that chaos is inherently bad, or order inherently good. They're just different environments.

Linux will also generally chase new versions of other programs much more closely, adopting particularly more major changes like Apache 2 much sooner than BSD will move that way. Now, the stricter separation of "base" vs "ports" in BSD, as well as the structure of the ports tree itself, make it easier to have multiple parallel versions of packages in BSD. Sometimes, it's even possible and easy to have multiple versions installed at the same time. Linux, by not having that sort of separation, makes it very difficult to have parallel versions, and instead almost requires a single "blessed" one.

And the primacy of source-compiling in packages also makes it easier to handle multiple versions. For instance, PHP must be compiled differently depending on whether you're using Apache 1.3 or Apache 2. With from-source packages like ports, I can define an environmental variable when I compile and install PHP to tell it whether to use Apache 1.3 or Apache 2. With binary packages, you'd have to have 2 separate packages available, which will lead to confusion sooner or later.

Right vs Wrong

The difference can also be seen in the way core code is integrated. BSD tends to always shy away from hackish solutions when there's even a hint of a proper solution in the wings. The theory is that it's far easier to wait for the clean answer, than to integrate the dirty answer now, for several reasons. For one thing, if you integrate the dirty answer, that reduces the incentive to implement a better one. For another, once you dirty up the architecture to integrate something it'll never get cleaned up again. You know it as well as I do. Oh, sure, you'll say it's temporary. But you know there's nothing quite as permanent as a temporary stop-gap. And things grow. The only way to avoid giving a mile is to refuse to give the first inch. It's just like taxes; when was the last time you saw a temporary tax that ever went away?

You also see it in what is there. Traditionally (though not universally), Linux integrates support for a piece of hardware before BSD does. But when BSD integrates it, it works. It's solid. It's stable. Linux drivers tend to have a lot more variance, because they'll be brought in earlier. In many ways, this mirrors the add-on case above, but in reverse. BSD has a very tightly controlled base system, and can be very free with setting up add-on software, since it's all added on by the user independently. Linux has a very loose and fluid coupling between the kernel and the userland, but the userland as a whole, due to not having a base/addon separation, requires a lot more work to keep consistent, which places a much higher requirement for a central "blessing" of various versions of packages. The extensive use of binary, rather than source distribution just makes it that much more so.


Well, we've already pretty well covered audience. Linux, with its chaotic tinkering background, naturally appeals to a different personality, in general, than BSD with its academic and rigorous background. I, personally, think that's held Linux back in some ways that are becoming more apparent lately. Random chaos certainly has advantages, but it's not without its drawbacks as well.

Consequences of Design

The piecemeal-assembly methodology of Linux makes it easy (in theory) to just upgrade a single piece. In BSD, it's easy to upgrade the single pieces that are "add-on" from ports, but the pieces which are integrated in the base system can't easily be messed with independently.

OpenSSL, for instance, is imported and maintained in the base system, but I can't just upgrade it by itself; I have to update the whole base system. And that includes the kernel, as well as ls and gzip and gcc and less and ssh and sendmail and BIND. (Of course, you can always install different versions of sendmail and BIND, or Postfix and djbdns, through ports, and simply run the different version instead of the base one; it'll just sit around eating disk space, which is cheap).

In theory, that's a problem. In practice, I've found that it's usually easier anyway. I can't count the number of times I've locked myself out of a remote Linux box by upgrading OpenSSL, then trying to upgrade or restart ssh and have it fail because it's looking for a different version of OpenSSL. With the integrated system, that's not a problem, since they'll automatically be in sync. And with building them from source, they'll automatically be in sync anyway, even if they weren't integrated together in the base system.

As a result of that and similar situations, it's not so easy to keep Linux systems completely "up-to-date". 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. New packages for 7.3 are being made and updated for a certain amount of time, and often really new versions of packages never make it in. And if you try to use packages from a different version of your distribution, or from another distribution, you often run into missing dependencies and problems with different versions of other programs. And as hard as it is to keep a system up-to-date, it's even harder to bring them up to date after a period of neglect.

On the other hand, I have BSD systems that I installed in 1997, which have always been kept (and still are today) up with the latest kernel and the latest version of Apache and the latest Mozilla and the latest everything. 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. Those methodologies appeal to rather different kinds of admins.


We've spent a lot of time so far talking about the differences between BSD and Linux. We've spent a lot of time talking about how BSD works. And now we've sort of covered what BSD "is". So, let's take a quick trip into what BSD isn't, and dispel some myths.

  1. Intro
  2. Dramatis Personae
  3. Design :: The Base System
  4. Design :: The Ports Tree
  5. Technical :: Releases
  6. Technical :: Upgrading
  7. Technical :: Ports
  8. Philosophy
  9. Myths
  10. Conclusion
  11. Responses