OpenBSD Is Hard to Show Off
atthis.link
atthis.link
I just reviewed it:
https://www.theregister.com/2024/10/10/version_76_openbsd_of...
It worked, but a lot of stuff was way harder than it should be.
[1] Docs.
Some of the issues I've faced with it could be fixed with better documentation.
Baseline: you have an older computer, one you can afford to have non-working for a while. You want to be able to download drivers and stuff so you want to dual boot with another OS. What other OS doesn't really matter: could be Windows, could be Linux. Not important. Partitioning
Document how to partition a disk while identifying what existing partition is which. How to ID a bootable working Windows partition, say, but remove the useless "recovery partition" and reuse that space. This needs covering for both BIOS/MBR and UEFI/GPT.
Also: how to customise OpenBSD's positively Byzantine, labyrinthine partitioning so you have room to install GNOME or whatever. (Personally I detest GNOME and I'd say the only desktop in line with OpenBSD's goals of simplicity and cleanliness is Xfce, but whatever.) Bootloader
Also: how to add the OpenBSD bootloader to GRUB.
[2]
Installer and partitioner.
Many of the others... Well: while I was researching this article, I found a number of people posting on fora all around the Web going "the installation program is great" or words to that effect. The installation program is not great. It's a nightmare.
[3]
Virtualisation
As it happened after installing 7.1 and 7.2 I was emboldened to get 7.5 running on bare metal, which was hard and I felt considerable pride that I did it, as one of 5 OSes on that machine.
That happens to be around the time it stopped working in VirtualBox. Readers have commented to this effect, and I tried it and I've confirmed it.
Out there in the real world people will try it first in a VM. It must work without any special config. It did work until around 7.3 or so and now it's broken. This is a major priority.
I believe this stems from its BSD Disklabel roots. Disks are divided into 'slices' under BSD, which are called 'partitions' under non-BSD, either MS-DOS style or EFI. This 'slice'/partition is then sub-divided into different lettered "sub-partitions".
And for historical reasons, the 'c' partition refers to .. I think the whole slice.
I suggest reading my article. HN will break my formatting here.
https://www.theregister.com/2024/10/10/version_76_openbsd_of...
OpenBSD created no fewer than nine separate partitions in its 32GB primary volume. The result is that it hasn't got the space to install, say, Xfce.
````
thinkpad-w500$ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/wd0a 986M 248M 688M 27% /
/dev/wd0n 7.4G 227M 6.8G 4% /home
/dev/wd0d 1.8G 5.8M 1.7G 1% /tmp
/dev/wd0f 3.5G 1.5G 1.8G 45% /usr
/dev/wd0g 986M 329M 608M 36% /usr/X11R6
/dev/wd0h 4.1G 924M 2.9G 24% /usr/local
/dev/wd0m 5.7G 2.0K 5.4G 1% /usr/obj
/dev/wd0l 1.8G 2.0K 1.7G 1% /usr/src
/dev/wd0e 2.8G 10.4M 2.6G 1% /var
````
The real point here is that with such elaborate partitioning, this OS needs dynamic space management such as a logical volume manager.
<sarcasm>
But its developers are too old-school and want users to exercise their psychic powers and foresee their disk space needs in a few years and plan ahead. Sadly my clairvoyance is extremely weak.
</sarcasm>
IRL they think you're going to give a whole huge disk to the OS and the problem will go away.
Same as the SUSE devs with Btrfs. It will fill its own disk with snapshots and because the FS design is broken, `df` does not work, so it can't tell and then it will self-destruct.
Actually, in practice, this is bad design. It needs to be fixed. To be fixed, it needs to be called out publicly.
That's what I am doing.
That's because the devs like it that way. They're comfortable with everything they learned 30 years ago and see no need for any of these newfangled usability improvements.
And then they wonder why it's hard to attract new users to the community, and the maintainers are getting old and occasionally dying.
See also: Emacs.
On OpenBSD, the list of processes is mercifully short, and I can tell you what each of them is supposed to do. CoreOS? Not so much -- and, yeah, I know, I could of course switch to non-systemd-infested distro, but even there, there would be at least a screen-full of processes of which I could maybe identify half?
This pattern extends to configuration: OpenBSD has a handful of very-well-documented files in /etc, whereas under Linux, things are literally all over the place, and you might even end up editing irrelevant configs, because they happen to be regenerated by yet-another-layer of tooling, or your distro is simply not using the tool you think you're configuring...
Still, I have no clear preference for one OS over the other! With workloads being mostly containerized these days, it's so easy to roll out a new VM, that the level of understanding required to, say, nurse a broken OS on physical hardware back to health, is now simply irrelevant. Just blow away the old and deploy the new, and forget about it.
On OpenBSD, the deployment tooling uses tried-and-true commands like `fdisk` and `ifconfig`, whereas for CoreOS it's YAML (pronounced: 'hell'), but the truth is... it doesn't matter that much. Getting the base OS installed, adding some volumes, creating sub-interfaces for the relevant VLANs, installing Docker(-compose), and getting the containers to (re)start is all very, very similar.
So, yeah, I sort-of get what the article is trying to say, but the ground-truth I think is that in most cases the OS isn't that much of a differentiator anymore, as they're pretty much all OK-ish...
Have you got the actual outputs to compare?
In fact, OpenBSD has gotten a lot more verbose over the years, due to sub-processes being listed explicitly. Good example here is `smtpd`, but even then, the difference with Linux remains... stark.
Filter out the Linux ones that have [ ] around them (grep -v ]$ will do the trick) but just a quick glance tells me the Linux and BSD lists are about the same length.
I truly don't know, by the way; this was merely an example to illustrate my perceived difference-in-complexity between Linux and OpenBSD, which might be entirely misguided, but definitely part of the issue the article linked in the submission hints at?
It does. They're just hidden from the listing. https://github.com/search?q=repo%3Aopenbsd%2Fsrc%20kthread_c...
> why do I need multiple `psimon` kernel processes?
It's the way that module is organised. There's nothing wrong with the idea, you'd need to dive into the code to understand the details.
> illustrate my perceived difference-in-complexity
It depends on the situation. Seeing many kernel threads is one kind of complex. Not seeing the kernel threads and not being able to understand which one is having issues is another kind of complex.
You just saw how the sausage is made, but that has nothing to do with the final taste / how the system actually behaves.
Linux has a lot of in memory file-systems that I do not know what they are all for :)
Which ones for example? I wanna know if you know some I might still not know of.
Linux mount is separated between the physical and the memory mounts. The only memory mount I added as for /tmp
OpenBSD: ======== /dev/sd1a on / type ffs (local) /dev/sd1h on /home type ffs (local, nodev, nosuid) /dev/sd1d on /tmp type ffs (local, nodev, nosuid) /dev/sd1i on /u type ffs (local, nodev, nosuid) /dev/sd1f on /usr type ffs (local, nodev) /dev/sd1g on /usr/local type ffs (local, nodev, wxallowed) /dev/sd1e on /var type ffs (local, nodev, nosuid)
Linux: ====== /dev/sda1 on /boot type ext4 (rw,noatime,stripe=4) /dev/mapper/cryptvg-home on /home type ext4 (rw,noatime) /dev/mapper/cryptvg-u on /u type ext4 (rw,noatime) /dev/mapper/lukssdb1 on /u1 type ext4 (rw,noatime) /dev/mapper/lukssdb2 on /u2 type ext4 (rw,noatime) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=4194304k,inode64)
proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=32768k,mode=755,inode64) devtmpfs on /dev type devtmpfs (rw,relatime,size=8192k,nr_inodes=1995831,mode=755,inode64) /dev/mapper/cryptvg-root on / type ext4 (rw,noatime) devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,inode64) cgroup_root on /sys/fs/cgroup type tmpfs (rw,relatime,size=8192k,mode=755,inode64) cpuset on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset) cpu on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu) cpuacct on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct) blkio on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio) memory on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory) devices on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices) freezer on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer) net_cls on /sys/fs/cgroup/net_cls type cgroup (rw,relatime,net_cls) perf_event on /sys/fs/cgroup/perf_event type cgroup (rw,relatime,perf_event) net_prio on /sys/fs/cgroup/net_prio type cgroup (rw,relatime,net_prio) pids on /sys/fs/cgroup/pids type cgroup (rw,relatime,pids) misc on /sys/fs/cgroup/misc type cgroup (rw,relatime,misc) cgroup on /sys/fs/cgroup/elogind type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib64/elogind/elogind-cgroups-agent,name=elogind) tmpfs on /run/user/1001 type tmpfs (rw,nosuid,nodev,relatime,size=1598624k,nr_inodes=399656,mode=700,uid=1001,gid=1001,inode64)
Do note that systemd mounts a lot of other stuff though that isn't mounted on your system (e.g. bpf, a few tmpfs for service credentials, autofs for keeping /boot and /efi unmounted by default [reason: VFAT is relativly brittle, so only mount when needed] and a lot more kernel fs'). This is on a relativly bare Arch image but I don't think there are a lot more mounts to add after the base system.
It is up to the user to change.
udev 3.9G 0 3.9G 0% /dev
tmpfs 785M 868K 784M 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1.6G 0 1.6G 0% /dev/shm
I just checked on my home server (Debian), running ps auxf, the only three userspace processes I did not install was udevd, uuidd and getty
The rest is my workload (nginx, random docker shit, postfix etc)
I've always appreciated a very minimal system, but nowadays Alpine Linux is much better for that IMO. I'm not sure there's a better alternative if minimalism is the goal.
syspatch did not appear until 6.1. Before that system updates were admin hell.
sysupgrade did not appear until 6.6. Before that, the "look at me and my hit-enter 20 minute upgrade" was very much not the case.
Network performance was generally rubbish unti the developers started making an effort sometime in the late 6.x releases.
Various userland bits were also rubbish until the developers started making an effort in the 7.x releases. For example, but not limited to, OpenBGPD (the OpenBSD native version, not the ported version which only has limited applications), which is something you wouldn't really want to use seriously in its earlier implementations for 101 reasons.
It is also still not perfect. For example there are various fibre NICs that FreeBSD supports out of the box but OpenBSD does not. And you still can't get SFP transciever data except in a VERY narrow combination of NIC + SFP cases.
I will grant you 7.5/7.6 have been great releases. I'm just saying, lets not pretend OpenBSD has always been like this, because it has not.
Finally, the author says of OS X "Terminals that crash when I create a new tab". As a long-term OS X user, I have never, ever seen this.
Odd statement, you realize OpenBSD has a much much smaller team than Linux. So changes take time and I think they went after the "big hitters" first. The same could be said about Linux between 1995 and 2000. By 1995 the Linux developers outnumbered the BSD developers almost 10 to 1.
Plus I remember the early days. Linux took a lot of things from the BSDs because they were easily ported over. Eventually many these items were replaced by GNU counterparts.
But nothing developed on Linux these days can be easily ported anywhere. So the BSDs have a hard time keeping up. Considering the team size, I say they are working miracles.
Its not an odd statement if you can be bothered to read it in context, i.e. this discussion. :)
We are talking, here, about somebody who has posted a blog post clearly written through the tint of rose-tinted spectacles, trying to convince the world that OpenBSD is the best thing since sliced bread.
AND YET
Many of the things the author chooses to promote, "Installing OpenBSD can be as easy as just hitting Enter", "I upgraded to 7.6 yesterday, the whole process took less than 20 minutes, was fully automated" etc. etc. etc. etc. etc. are all things that would not have been possible for the author to evangelise about anywhere more than 5 years ago (sysupgrade @ OpenBSD 6.6), and in many respects less than that (lots of other stuff that came much later).
Hence my statement ... lets not pretend OpenBSD has always been like this, because it has not.
Because, let's be honest, most other mainstream OS's have had, for example, sysupgrade-type capability much-much-much longer than 5 years.
The OpenBSD devs could, if they wanted to, have done sysupgrade/syspatch a long-long time ago. But for a long-long time it was nothing but an opinionated decision that they did not. I have recollections of people asking it on the misc mailing list and being shot down by the core-devs.
So you are complaining OpenBSD is better now then 5 years ago ? This is how software should progess, each release something improves. OpenBSD releases more then 2 release ago are not supported.
>would not have been possible for the author to evangelise about anywhere more than 5 years ago (sysupgrade @ OpenBSD 6.6)
I upgraded from 6.5 to 6.6, it was easy. The only difference beween then and now was I had to manually remove some files. Some people has to update config. But it was still easy, you just had to follow detailed instructions.
https://www.openbsd.org/faq/upgrade66.html
>Hence my statement ... lets not pretend OpenBSD has always been like this, because it has not.
So :) Software is suppose to improve as it is updated, OpenBSD has been improving in spite of the size of their team.
>For the past 2 years I've used OpenBSD as my primary OS for work, play, everything. It just works
Above quote from the article, he has been on OpenBSD fully for 2 years, so from his prespective it is easy.
Yes, many years ago OpenBSD was harder, but now upgrades and installing is close to trivial. So since it is "today" his article is fine by me.
Except non-amd64/i386 is much harder, the above is only for amd64 and i386
That's just weird. Linux doesn't put anything in home directories by default. You may install some apps that will do it, but they'll do the same thing on BSDs. What?
Any os can be great if you “just” learn to do your computing the way the os dictate.
And, am i really supposed to be impressed by the fact that you can “just press enter enter enter” to install openbsd? Like, for real?
That's an odd thing to say. Is there an OS that you have adapted to you?
Microsoft BOB
I am not the OP, but I would chime in to say it is not odd.
I am someone who regularly uses the entire spectrum of OSs: Windows, Linux, Mac, BSD.
OpenBSD is very much the most opinionated OS out there.
If your view of the world is inline with that of the OpenBSD core-devs (or if you just want a minimalist OS for a firewall or whatever) then you'll get on just fine with OpenBSD.
But for many people, it could easily be the case they would be better served by "anything else". Probably Windows/Mac/Linux, but even FreeBSD is not quite as hard-line opinionated as OpenBSD.
OpenBSD has a number of great server-side applications. But there's no chance you'd ever find me ever using it as a desktop or imposing it on anyone else as a desktop !
I personally won't be interested in daily driving a bsd until they can get suspend/resume at the very least, but I'm considering trying it out in a VM. my needs are few, and I could always use the host Linux for anything that didn't fit in the VM. I'm quite tempted by the whole "you can understand the whole OS" aspect, and I always took that to mean you can therefore mould it into what you want.
currently I do have a sweet setup with nixos though, it feels almost as an OS-as-an-appliance, on account of it being almost impossible to brick (I somehow managed it once, 8 years ago, but have never re-installed since).
Also, most of the embedded linux folks have at least tried lfs at least once. And almost all of them do the exercise of creating a custom linux distro (either via automated lfs or via some other kind of tooling like yocto or buildroot).
Too bad openbsd people can’t even conceive something like this possible.
maybe they prefer to use the right tool for the job?
> they basically adapted themselves to the os rather than adapting the os to themselves.