The fact I miss pretty much all the drama around the latest corporate take over attempts on Linux is just icing on the cake. The toxic slug strategy is an amazing one that more open source projects should use.
One was to pick a set of norms repugnant to the mainstream that everyone currently in the community can tolerate and enforce them rigorously on all new members. This will limit the appeal of the community to people like the ones currently there and will make sure that it never grows too big.
Thus your community is as appetising to activists attempting a hostile takeover as a toxic slug is to a bird.
As an example from six years ago, when the code of conduct madness had just reached its peak:
>I believe OpenBSD's code of conduct can be summed up as "if you are the type of person who needs a code of conduct to teach to you how to human then you are not welcome here".
I think that the goal of any code of conduct is to prevent any semblance of arbitrary and whimsical punishment, which can kill entire communities.
Linux unfortunately has to endure with toxic contributors and even maintainers, and history showed that when those maintainers fail to human and consequently the community banishes them, they go on a tirade arguing all kinds of conspiracies. A code of conduct is a form of checks and balances, and code of conduct violation processes serve as processes to collect and present objectively verifiable paper trails of exactly when snd how those maintainers failed to human, and how bad at it they were. Those types can't simply argue their way out of a list of messages they were awful to others, how exactly they violated the code of conduct, and how bad it was. Thus any stunt they pull is immediately rendered moot by the deliverables from the project.
Quite ironic then that CoCs overwhelmingly lead to arbitrary and whimsical punishment.
I don't agree. I think it has been working quite well in spite of the conspiratorial bullshit excuses made up by those who failed so hard to human to the point they were slapped with one.
Nevertheless, one of the values of a code of conduct is that people like you and me can check the deliberation and hear what all interested parties had to say. Without a code of conduct, the one with the loudest voice and the more interest to subvert code of conduct deliberations could basically dedicate their life shit-talking the project.
As a result of this typically CoCs are used to block contributions or block contributors from projects where the people enforcing the CoC they wrote wield it as a weapon against men whose perceived personal politics they disagree with. And typically rumours are enough to trigger CoC proceedings against them.
I don't know which codes of conduct you have been exposed to. The ones in Linux cover basic things like not being cool to attack other maintainers with posts like:
> Get your head examined. And get the fuck out of here with this shit.
https://lwn.net/Articles/999197/
This is hardly what I would label as an ideological debate.
That's the opposite goal; the CoC is to be as broad as possible while still being as vague as possible.
It's a tool that has been repeatedly weaponised against the out-group by the in-group - there is never any sense of even-handed usage of a CoC against the community.
Nice.
True, but what you have ignored is that jerks exist equally on all sides of any CoC.
It's just as often as not that the producers and promulgators of some CoC are the jerks. In other words CoC's don't fix anything by merely existing. A few lines in a charter or mission statement already does the same to have something to point to just for formality and documentation sake.
--
[edit to expand or re-state a little...]
It's not that there is no problem and everything is fine already. It's that CoC's are almost always a thoughtless and ineffective, even actively counter-productive response to the problem.
A coc is an attempt to make an easy solution for something that there probably IS no easy solution for.
The problem takes the form of a continual fresh stream source of problem. IE a forever stream of new jerks, and existing jerks who dodn't just do one thing today but continue to exist tomorrow and the next day.
And so the solution can only be a matching continual case-by-case counter-effort, from intelligent insightful people who have good judgement.
Yeah, that doesn't scale and isn't easy and only some people do even a half-way good job of it.
It's just not a problam that you can bash script away.
But trying to do so is an example of being just a different color of jerk making life worse for others, but just in a different way and employing different mechanisms.
It's true that you can't just throw together a CoC and declare the problem to be solved. But there is value in writing down some ground rules. The purpose is not to "script" enforcement, it's to have something concrete you can point to. Having a CoC that says "no personal attacks" won't stop personal attacks, but it will let you very quickly shut down anyone who comes back with something like, "you just need to have a thicker skin."
- IDE support is an issue still
- Filesystem challenging when using a laptop that runs out of battery
- MATE lacking volume and WiFi controls
- This one is just me being picky but a GUI to help me gain a better understanding of the security settings or alternatively more up to date books.
- I am not exactly sure on how to correctly use virtualization and I need it to support docker workloads at work
> IDE support is an issue still
IMO, languages and platforms that require IDEs, also leads to complex software that is hard to maintain. The only exception is smalltalk.
> Filesystem challenging when using a laptop that runs out of battery
Easily resolved by using apmd and it `-z` flag. I think there's a couple utility out there that you can script for monitoring battery level.
> MATE lacking volume and WiFi controls
One of the good strength of OpenBSD is that the cli utilities are quite nice that I've not installed gui replacements (I'm using cwm). I don't mind doing a few `doas ifconfig` every once in a while.
> but a GUI to help me gain a better understanding of the security settings
I'm with you on that one. But the man pages are truly extensive. And the OS code is fairly readable.
> how to correctly use virtualization
Current vm solution is very bare. For docker, you'll need a linux VM, but the installation process maybe troublesome. It only supports serial interaction, which can be disabled by default in some distros.
“ IMO, languages and platforms that require IDEs, also leads to complex software that is hard to maintain. ”
The truth is that I (and probably other users) don’t always have the luxury of choice and a large portion of commercial codebases have a very large number of files. Sometimes, it is multiple codebases at once with a very large number of files .
“ Easily resolved by using apmd and it `-z` flag. I think there's a couple utility out there that you can script for monitoring battery level.”
Yeah but I don’t want to accidentally lose data if I shut the lid and accidentally forget to plug the thing in for a few days . “ One of the good strength of OpenBSD is that the cli utilities are quite nice”
I don’t want to enter and exit a cli tool in order to increase and decrease the volume . Ideally it’s a control in the top right or a keyboard mapping . What if something loud begins playing in a browser tab and I have to change the volume quickly?
> IDE support is an issue still
Yes, I agree. I enjoy using VSCode for most projects and there is no native support today in 2025 as far as I know. It is possible to use the web version (vscode.dev), but naturally, this lacks some features of the desktop application.
Typically I use some lightweight editor like Leafpad which has some basic IDE features. Not a replacement for a real IDE, but just an idea.
> Filesystem challenging when using a laptop that runs out of battery
Yes, OpenBSD uses FFS2 as the default file system. It's a solid filesystem with extensive history and testing, but it's not particularly tolerant of sudden power loss. In my experience most OpenBSD systems will come back online automatically after power loss, but there is a risk it will drop into single user mode if `fsck` wants a human in the loop.
There are some things one can do to help mitigate this, granted it's not very appealing coming from a more fault tolerant journalling FS: automated backups, using the `sync` option on your main data partitions (can affect performance), and of course monitoring power as mentioned.
IMO, this is a bit easier to manage on desktop or server roles where one can put everything behind a UPS.
> MATE lacking volume and WiFi controls
I haven't used MATE on OpenBSD. It's possible it's a combination of hardware + OpenBSD + MATE if it's not working. I know I have had working media controls on OpenBSD laptops in the past but I tend to stick with older laptops, Thinkpads, etc.
There are some in-base utilities to probe media keys and hook into X etc. if you're open to scripting a bit on your own hardware.
But yeah, after using Linux on laptops, it would be annoying for media keys to not Just Work after installation.
> This one is just me being picky but a GUI to help me gain a better understanding of the security settings or alternatively more up to date books.
Fortunately, there aren't too many security settings to change on OpenBSD. The most common one for laptops would be to enable SMT, e.g. enable hyperthreading on CPUs that support it. It is disabled by default as SMT is difficult to secure properly, but it does naturally improve performance. The command is `sysctl hw.smt=1`, or `echo 'hw.smt=1' >> /etc/sysctl.conf` to make it permanent.
> I am not exactly sure on how to correctly use virtualization and I need it to support docker workloads at work
Virtualization is a little unusual on OpenBSD. It's not quite as flexible as qemu, FreeBSD jails, bhyve, KVM, etc. The `vmm` and `vmd` systems were built in-house by the OpenBSD team. It is currently limited to just one core per VM the last I checked, and only supported serial and not VGA, so no way to run Windows under it for example.
I have had great success running Alpine Linux under OpenBSD and then running Docker on top of that, which opens the door for many tools and apps to run under an OpenBSD hypervisor.
There are also some VPS providers out there that fully dogfood OpenBSD and run their entire VM architecture on OpenBSD, such as OpenBSD Amsterdam, so it is totally viable depending on what one needs to virtualize.
Of course, one can run qemu on OpenBSD and virtualize whatever the heart desires.
---
That said, while OpenBSD can be a great laptop OS, it can require a bit more setup and understanding compared to a mainstream Linux OS. IMO it's still worth playing around with, even in a VM or on different hardware (desktop, Raspberry Pi, etc.) just to see the OpenBSD way of doing things, because it is truly a wonderful OS to use and learn. Other OSs start to feel a bit clunky to me after using OpenBSD for a while. :)
> One of the good strength of OpenBSD is that the cli utilities are quite nice that I've not installed gui replacements (I'm using cwm). I don't mind doing a few `doas ifconfig` every once in a while.
I also don't mind doing things like this for network, but for volume this is very much an instant always-there requirement. If I need to mute/lower/raise the volumne in a hurry, I don't want to hunt for the application playing the sound, then find the volume slider on it, etc.
This is literally a deal-breaker for desktop/laptop users.
What I'd like to know, if there are any OpenBSD people reading, is how hard is it to contribute a fix or similar to make the desktop environment's volume control work?
I can obviously fix it for myself with some gui script/keyboard shortcut/etc, but I'd rather have anything be in the default installation whenever I refresh the install.
I thought it was about the parallel ATA. And I tought "who uses that still?!" but is about IDEs for programming...
sorry about the topic deviation, but I laughed hard.
One of the reasons you don't see a lot of books around OpenBSD (aside from the very small userbase) is that the built-in documentation is so good. The manpages are actually worth reading, and for the more complex services, include examples and additional reading.
But still, the rest of your points are very true. OpenBSD is really not for everybody, but I think that's one of its strengths. It works extremely well for the people it works for, because it's not trying to coax new users into the fold.
Also, you know, like you don't have to use OpenBSD for everything. I still have plenty of Linux servers, and Linux computers, because there are some things OpenBSD is not suited to.