OpenBSD, or how I review software projects

October 29, 2022 by Lucian Mogosanu

This article is going to be, in the tarpitian tradition, quite a lengthy excursion, so make sure to grab a coffee while at it.

When reviewing a software project, my first criteria -- that is, by a long shot relevant over any other considerations -- are political. Software -- by which I mean all the texts involved in running a certain computer program -- cannot be decoupled by those who steer it, and thus software projects cannot be decoupled by those involved, either in writing the code, reviewing it or any other activities pertaining to said involvement. This doesn't mean that I won't use Excel simply because I don't like Microsoft's politics; of course I'm going to use it, only not in the manner Microsoft wants it to be used, and if the manner in which I wish to use it is made impossible by its owners, then I will simply stop and look for alternatives.

On a superficial level, I'm well aware that OpenBSD has recently (and not only) seen donations from Microsoft and Facebook. I am not moved by this aspect, as I'm not moved by, say, the fact that MP donated a hefty sum to the same project back in 2014; just as well as I'm not moved by the fact that the very same and other corporations donate a whole lot more to the Linux Foundation. Superficially, following the money seems like a good idea, since the economics of... well, pretty much any project make up a fundamental aspect of its definition. Still, economics cannot be reduced to money on one hand; while on the other, I'm not sure how much it says about the actual essence of said project. And in looking at essence, at the nature of something, I am faced, in the Heraclitean vein, with the necessary question of what changes and what stays permanent. More precisely, I am faced with the question: how much of [the] Linux [that I know] is still there in [the] Linux [that exists now]?

Before we proceed further, let us understand each other: I am quite often faced with reading Linux kernel code, both old and new, in my daily work. I know for the most part how Linux has changed since the days of 2.6.x to 3.x to 5.x, such as for example what architectural support was added, when certain mechanisms were implemented, as well as the political changes such as the introduction of CoCs and so on; and since I've crossed into BSD land more than once, I can for example enumerate the main design and implementation differences between the virtual memory management subsystems in FreeBSD and Linux, and more importantly, why they were designed the way they were. I may not always be up to date with the latest news, nor have I closely followed the latest dramaz within the community, but when I hear more of dramaz than actual news, I immediately smell something wrong there.

For example, I take the latest decision to integrate with Rust in the 6.x branch to be an ideological, that is, a post-religious choice. Before you ask, I am more than accustomed to the so-called functional style of programming since my days of Haskell and I have an entire category dedicated to Lisp over here. So then I have to ask: why Rust and not Lisp? or Scala, or whatever the fuck other fashionable piece of software out there? is it because Rust was "made for systems programming"? Give me a break, C++'s newer functionality would have made for a much stronger case, and let's not even discuss Ada, which was for a very long while ignored despite its long tradition as a language employed in safety-critical systems, and despite its long history of integration with the GNU toolchain. Stripped aside of all these considerations, the choice remains simply the fashionable one among them, or the "democratic" choice (surely, also pushed by "industry"), if you will.

Then I cannot but wonder if the symbol "Linux" does not simply denote yet another empty notion, just like democracy before it; or if not that, then perhaps it is just another metaphor for a dune of sand shifting with each pale of wind, each revision merely adding to the chaos of tools and languages, a sort of post-modern Babylon, identified merely through its supposed quality as the navel of system software. While that may indeed be the case, I'm not content with this prospect, and not necessarily for any ideological reasons. From a more practical perspective, it'd be a wasted effort on my part to continue in this style; such that now if I'm forced to use a Linux system, I'll just use it irrespective of other considerations, and quite irrespective if its userland comes with a systemd or some other abomination. In other words, I'm really not that involved or invested in that community1, much like I'm not invested in Windows or MacOS, Android, SteamOS or whatever else.

So then this leaves me with either some other fancy and fashionable or otherwise hipstery operating system2, or otherwise with one of the traditional Unixen. As I've said, I've used FreeBSD in the past and I'm not impressed; and I've had some brief encounter with DragonflyBSD, but not close enough to care; otherwise there's NetBSD and OpenBSD, the latter touting that, I quote, "[our] efforts emphasize portability, standardization, correctness, proactive security and integrated cryptography". If this means that the item in question is changing its core at a slower pace than other projects, I very sure welcome it, despite any other shortcomings that I know3 or might find. Insofar as I can see, such as by looking at the the lastest release, these folks introduce very few compatibility-breaking changes with new versions. While the whole list of changes may seem long, let's keep in mind that unlike Linux, OpenBSD is an entirely integrated system, including both the kernel and the userland, much rather comparable to a Red Hat or a Debian. Only in the case of OpenBSD, GNOME 40.4 is not even an option for initial deployment, which at least on a superficial look seems to maintain a certain separation of concerns.

Before I move on to the technical considerations, there are of course other political matters: such as the chosen means4 for communication, or the CVS/git choice of mirroring; or many others, which as far as I'm concerned are minor details. I'd happily go as far as using Discord to get in touch with folks I care about, if only my repeated attempts of using Discord hadn't delivered repeated triteness. Anyway, I don't expect De Raadt to move his coșmelie over to Zuckbook anytime in the foreseeable future, so I guess I'm fine on that count. Besides, reading their logs, it seems that they're too busy with whatever work they're doing (support for various hardware, for the most part) to spend their time with trifles.

As for the actual technical issues, I'm not sure where to begin. I've installed it on some shitbox I have and I'm in the process of understanding OpenBSD's device driver model. As someone said to me recently, OpenBSD is a Unix taken and patched up5 with some security features and, more importantly, defaults and practices, which already begin veering outside of the technical sphere and into the more general philosophical. In other words, OpenBSD might not be the next generation of computing design, but at least it's lasted this long, which readily falls in line with the idea that security is an operational problem at last as much as it is a technical implementation issue.

This is also what the Rust ideologues don't understand: given enough incompetent programmers, they will readily proceed to fuck up Linux using Rust; adding some "safety features" may cause them some grief in the short term, but eventually they will end up turning everything into a more obscured and confusing version of itself, that is, worse for everyone involved. So with this view, I'll immediately grant that "security" is by and large the user's problem, despite the ongoing efforts to create a "police of computer security", which resulted in such things as SELinux (by NSA), AppArmor and other LSMs, among many other "features". In contrast to that, pledge and unveil look somewhat decent, and at least they extend the system directly as new system calls and without any special pretense to modularity.

Besides that, I haven't encountered any technical issues worth the mention. The documentation is very clearly structured, although perhaps one might more easily find explanatory pieces regarding NetBSD, which is fortunate, because I expect there's some code to be shared between the two, either historical or new. Once installed, the system is ready to be used and that's about it -- it's a Unix that works if you know what you're doing, and if you're not, it's perhaps an opportunity to learn6, or otherwise an opportunity to shoot yourself in the foot7.

To sum this up: any other criteria come downstream of politics, for what is human if not first and foremost a political animal, and how is "tech" to be considered in the absence of persons. Downstream one may find, happily intermingled, technical, philosophical, social and other aspects to examine howsoever one wishes -- if you wish to go as far as questioning whether it runs Linux, then I'm not the one to stop you; if you wish to simply know whether to use it or not, then you're in a tough spot, buddy, as no one can make your choices for you -- and if that's what you think you need, then maybe Windows or Ubuntu are the right choice for you. I guess we're left with what -- aesthetical judgments? Sure, I enjoy the subject, otherwise I wouldn't have spent 2K words on it.


  1. Seriously, Debian has been releasing their images with Python in the base system since... when? I don't know, nor do I care to look, but I'd rather have no Python dependencies in base as far as I'm concerned. I can install it myself, just like I install SBCL or whatever. 

  2. There's a few out there, for example this one

  3. Such as, for example, the lack of this or that driver for some hardware that I'm interested in. In other words, I'd much rather write a missing driver than get the driver and Python. I have nothing against Python, Python is just a poor victim of its own success; at the same time, it is up to each one to decide what constitutes "too much", either way "too much" is also a cost to be paid one way or another. 

  4. I'm aware that "email versus IRC or Discord" is also a technical point of discussion, but that's not what I'm discussing here. 

  5. In Romanian that would translate to "cârpit", which is a whole lot more expressive than today's English can muster. The word comes from "cârpă" which means literally a rag. So it's not just patched up -- it's patched up with whatever rags they could be arsed to find. This is a fair critique, if you ask me, as it says quite clearly that the intellectual resources for more than that are sorely missing at the moment. 

  6. Nor do I think that any departure from the assorted pile of C/Unix systems is possible unless Unix is first captured and thoroughly deconstructed, in its technical but also in its essential aspects. Maybe the Plan 9 folks came closest to an alternative, but only because Rob Pike was there when C/Unix were made, although he has meanwhile moved on to Google's projects. So this doesn't seem to be it. 

  7. For example, at some point during this review I had the urge to look for a cross-compiler for my target system. But then I was immediately ensured that this is not the kind of thing that I'd want to do as a noob -- more plainly, that system bootstrapping is not the way to go until I have a better grasp of the stuff I'm dealing with. 

Filed under: computing.
RSS 2.0 feed. Comment. Send trackback.

2 Responses to “OpenBSD, or how I review software projects”

  1. [...] I did mention these recently, I might as well lay out in blog form whatever notes I have gathered so far, for future [...]

  2. [...] when it used to work. Some traces of this approach of doing things still remain for example in the BSD world -- but don't trust me, make up your own mind about [...]

Leave a Reply