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.
So, the article seems to be mostly about desktop usage, but for me, the best way to show off OpenBSD is to just run `ps ax` after a clean install, and compare that to, say, Fedora CoreOS (just because that happens to be the other common OS I use for my server VMs).
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...
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.
That's because Linux is showing you the kernel processes and OpenBSD isn't.
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.
Counterpoint: possibly OpenBSD doesn't really have any relevant 'kernel processes' (in line with the model: the kernel is there to serve user-mode, and not a goal on its own). (And tangentially: why do I need multiple `psimon` kernel processes? Tire pressure is good to keep in mind, I guess, but, at the kernel level? Repeatedly?).
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?
> 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.
Its all very well to blow smoke up OpenBSD's backside today, but what the author carefully skirts around is that it hasn't been this way for that long.
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.
>lets not pretend OpenBSD has always been like this, because it has not.
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.
I always smile a bit when i read this kind of posts because authors usually don’t realise the kind of “brainwashing” they went through: they basically adapted themselves to the os rather than adapting the os to themselves.
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?
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'm still trying to figure out what you can adapt on windows that you can't adapt on a bsd. your reference about desktop - are you referring to background themes, adjusting the mouse speed, etc?
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).
I suspect the number of people who have personally turned LFS into a customised daily desktop OS are very few and both of them are reading this thread.
Most non derivative distributions started as Linux from scratch.
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.
> Whereas Linux might have some files in 'usr', others in 'bin', others still in '.local' or even just dumping random files in your '$HOME' directory.
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?
It really is.
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.
Here are some outstanding issues in the way.
[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.
> OpenBSD's positively Byzantine, labyrinthine partitioning
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.
So, the article seems to be mostly about desktop usage, but for me, the best way to show off OpenBSD is to just run `ps ax` after a clean install, and compare that to, say, Fedora CoreOS (just because that happens to be the other common OS I use for my server VMs).
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...
> 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
Have you got the actual outputs to compare?
Sure, why not: https://openbsd-ps-vs-coreos.tiiny.site/
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.
That's because Linux is showing you the kernel processes and OpenBSD isn't.
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.
Counterpoint: possibly OpenBSD doesn't really have any relevant 'kernel processes' (in line with the model: the kernel is there to serve user-mode, and not a goal on its own). (And tangentially: why do I need multiple `psimon` kernel processes? Tire pressure is good to keep in mind, I guess, but, at the kernel level? Repeatedly?).
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?
> possibly OpenBSD doesn't really have any relevant 'kernel processes'
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.
Just compare he results of mount(8) between Linux and OpenBSD, another eye-opener.
Linux has a lot of in memory file-systems that I do not know what they are all for :)
> 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.
Its all very well to blow smoke up OpenBSD's backside today, but what the author carefully skirts around is that it hasn't been this way for that long.
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.
>lets not pretend OpenBSD has always been like this, because it has not.
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.
> Odd statement
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.
I always smile a bit when i read this kind of posts because authors usually don’t realise the kind of “brainwashing” they went through: they basically adapted themselves to the os rather than adapting the os to themselves.
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?
Kind of the definition of man-machine interface. You in some way adapt to whatever you choose to interact with.
> they basically adapted themselves to the os rather than adapting the os to themselves.
That's an odd thing to say. Is there an OS that you have adapted to you?
> That's an odd thing to say.
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'm still trying to figure out what you can adapt on windows that you can't adapt on a bsd. your reference about desktop - are you referring to background themes, adjusting the mouse speed, etc?
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).
> That's an odd thing to say. Is there an OS that you have adapted to you?
Microsoft BOB
https://www.linuxfromscratch.org/
I suspect the number of people who have personally turned LFS into a customised daily desktop OS are very few and both of them are reading this thread.
Most non derivative distributions started as Linux from scratch.
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.
> Too bad openbsd people can’t even conceive something like this possible
maybe they prefer to use the right tool for the job?
> Whereas Linux might have some files in 'usr', others in 'bin', others still in '.local' or even just dumping random files in your '$HOME' directory.
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?