The BSD and Linux approaches to development put coherence in different places

December 23, 2019

I said yesterday that both the BSD 'base system' approach and the Linux distribution 'assemblage of parts' approach to building systems each have their own advantages. One of the large scale differences between the two approaches is what winds up being relatively coherent and unified.

In the BSD approach where the base system is all developed by a single group under its own control, the base system is coherent and unified among almost all of the various parts (and exceptions tend to stick out and be awkward, like GCC). However, this internal coherence means that there's relatively less coherence across different BSDs, so FreeBSD is by now reasonably different from OpenBSD, NetBSD, and DragonflyBSD (and others), especially in the kernel. To a significant extent, having a coherent base system means not sharing parts of that base system with anyone except people who are already very close to your whole system.

In the Linux approach where the system is assembled from a disparate collection of parts, any particular Linux is far less coherent within itself simply because the parts are developed by different people, with different approaches and styles, to different priorities and standards, and so on. However, Linux shares those parts fairly widely across Linux distributions, and so Linux distributions are far more coherent with each other than the BSDs are. This sharing and reuse of parts is really why we can talk of 'Linux distributions' instead of 'Linuxes'; they are, for the most part, distributing more or less the same things assembled in more or less the same way, although with different tools, different priorities about customization and versions and updates, and so on. One Linux distribution is much more similar to most other ones than, say, FreeBSD is to NetBSD or OpenBSD.

(Some Linux distributions make different choices at various levels, including in the core C library, but distributions that go off the common path tend to wind up relatively different.)

There is no right or wrong approach here, merely different advantages and different priorities. Sometimes these priorities are necessary to get certain sorts of results; for example, OpenBSD really has to be a BSD. And people are certainly drawn to the coherence and unity of FreeBSD over the relative chaos of basically all Linuxes.

(Meanwhile, Linux probably makes it easier to experiment with alternatives to some pieces, because you don't have to sail off entirely on your own. Alpine Linux gets to reuse a lot of components that other people develop for them, from the kernel on up, while still swapping out some core pieces.)


Comments on this page:

But which one of the approaches is closer to the "true" Unix-like?

The way I remember it is that it used to be that the various Unix-likes and Real UNIXes of yore were more different from each other in the way that some Linux distributions and the BSDs are. However, I've also heard people argue convincingly that they still shared a lot of the same tools, with a few stand-out exceptions which is more like the Linux distribution way.

No rights, and no wrongs here, I think - just and endless series but small but important gremlins that sometimes jump at you and shout boo! And then there's all the things that POSIX don't cover like accounting, networking (and thereby NFS, despite it having been ported so broadly), and probably other things I'm forgetting too.

Written on 23 December 2019.
« OpenBSD has to be a BSD Unix and you couldn't duplicate it with Linux
Why udev may be trying to rename your VLAN interfaces to bad names »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Mon Dec 23 22:26:06 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.