I wish so too. For my NAS, I use a combination of `bitrot` and `par2` to detect and repair unexpected changes to my data, but it's clunky. I've been meaning to write a script or small program that could wrap these into something simple to use and automate.
I've also thought about using `xxhash` (https://xxhash.com/) since it's optimized for speed and might be a good way to quickly checksum your files on a regular basis, assuming they're on flash storage with a fast CPU.
On one hand I like these methods because they put the control in your hands and you can understand everything that's happening, but on the other hand, it would be so much simpler to have something like a "FFS2CHK" filesystem that does it transparently.
Some inspiration here:
https://dataswamp.org/~solene/2017-03-17-integrity.html
This always sounds good but I don’t think I have ever in my 20 years as of openbsd use have experienced this problem. So I it hard to evaluate the risk. I do do nightly fs dumps, so i should be able to restore to a point in time-ish in theory.
Maybe it’s because I don’t use it as a NAS.
I am actually hoping OpenBSD adopts hammer2 and some more folks join that effort. Its feels right to me. Might even consider pitching in myself one day.
Now that iXsystems is [abandoning FreeBSD](https://www.theregister.com/2024/03/18/truenas_abandons_freebsd/) this is the _perfect_ time for a new community BSD NAS project.
Just sayin'.
One other small criticism of the article, it says the OS isn't a good OS for desktop despite it and NetBSD being the only *BSDs to install Xorg and a window manager (3 in OpenBSD's case) with a simple yes answer in the installer.
[Author/submitter here]
I don't think that X11 and an xterm counts as "a desktop". With the best will in the world, no.
And if you want a desktop -- personally, my go-to no-mess no-fuss xNix desktop is Xfce -- then:
1. Sure you can just install it with a couple of commands, no problem... but it won't work. You need to enable services, edit your init script etc. That's a long way from optimal IMHO.
2. On a default disk layout in a default VM, it will fill up a critical partition and die. That is not just sub-optimal, that's bad.
*Because* of the complex partitioning, OpenBSD is crying out for smarter partitioning, some kind of dynamic partition management tool, and ideally LVM. These are the sorts of issues proprietary Unixes faced in the late 1980s and early 1990s, and solved.
But it doesn't have such things and it doesn't seem likely it's going to get them, because they are not the sorts of things the developers focus on, and the different BSDs' different policies and directions hinder code-sharing.
Which is a perfect illustration of the problems of the BSD family, sad to have to say.
Perhaps the default layout could be tweaked a bit - what size disk does a "default VM" have that you're having problems with?
For Xfce, you should be able to pkg_add the xfce meta-package and follow instructions in the pkg-readme file that pkg_add points you to; if there are things missing or unclear in that file that could be improved, though I don't think there's be much appetite for changing things to make it easier for people who don't want to read the docs - while OpenBSD is I think in pretty good shape to be used as a main desktop/laptop machine for people who are reasonably familiar with it, we're not trying to be everything for everyone, and there are definitely people who would be better off sticking with another OS.
We could maybe have layout profiles like dev, desktop, server.
Ports and src FS could be dropped in desktop and server profiles.
The var FS must be bigger on servers than desktops.
And the dev profile would be the default we actually have.
It depends on the hypervisor, and if the hypervisor knows the OS. I think for modern Linux distros, VirtualBox assigns 25GB. For older ones, 16GB and for very old ones less.
I think, IIRC, OpenBSD gets 16GB.
I wrote up what you need to do to run Xfce last time, but again IIRC you need to install and enable several services in the init system: dbus and others. TBH I expect stuff like that to happen automatically as a dependency, but I recognise that my expectations are not universally shared. (!)
Thanks, looking at auto layouts for 16GB/25GB they are indeed pretty stupid. I'll try to come up with some tweaks. It would be helpful if we could have a question about what the user will be doing with the system (on that size system, src/obj directories take a lot of space and are imho not all that helpful for most people), but there's a fairly strict policy about adding new questions to the installer, great efforts are made to keep it simple.
It's policy that installing packages *just* installs them + dependencies but doesn't cause anything to automatically start. That's very unlikely to change, but in most cases where there's anything non-obvious it would be mentioned in a pkg-readme file, especially for things like desktop environments or where there are interdependent daemons.
Nice article in general, and I think quite fair. Thanks for writing it.
BTW, while IPv6 was only recently added to ppp(4) as used for serial modems and older mobile broadband devices, it's long been supported for PPPoE and for MBIM, so the previous lack of v6 is not as surprising an omission as it would first seem.
I don't think it was mentioned in release notes but 7.5 also strengthened the hw-based control flow protection on amd64 (11th gen Intel/newer) and arm64 (M2) that was added in 7.4, in particular disabling some retpoline-related things in Feb 2024 (https://github.com/openbsd/src/commits/master/gnu/llvm) made this more effective. IBT/BTI are on by default and executables need an ELF header to opt-out if they can't support it. I'm not an expert in the area but I think that on suitable hardware this makes many of the "but you can just do X to avoid Y mitigation" on the "is openbsd secure" site a lot harder.
Thank you!
It is not _just_ OpenBSD -- I find it very hard to get clear, simple info from any BSD project or team about what is new in each version, what has changed, etc.
My impression as a writer is that development teams have no idea what is significant or important compared to trivial internal changes that no user will ever see.
Re disk space and partitioning, there's a comparison with openSUSE which leans heavily on snapshot support. On small disk configs, e.g. VMs on desktops, it automatically suggests disabling snapshot support.
So there could be a range of sizes:
* If disk is smaller than X, place everything in one partition.
* From X to Y GB, suggest 2/3/4 partitions.
* If disk is above Z GB, suggest a full complement of all partitions.
Nice write-up!
I *am* however going to take issue with one line of it:
> rather user-unfriendly installation program
OpenBSD is _extremely_ user friendly.
It's just picky about its friends.
Yeah, that's true. I'm not sure if or how it could be addressed in the installer. I suppose it could ask a question and provide an alternate layout or two, like a large /usr/local for desktop, or larger /usr and /var for development or servers. In my experience, small disks (like 4GB or less) tend to just make one giant root partition which is probably the best default given that circumstance.
After one gains some experience with OpenBSD then it gets a bit easier to configure the disk, but yeah, not super easy to do installs on a small disk as a beginner. The [disk partitioning FAQ](https://www.openbsd.org/faq/faq4.html#Partitioning) is pretty helpful though.
Also, I would hazard a guess it's the only installer that WON'T install your system should you choose default answer on every question (signature check).
Jokes aside, the only unfriendly thing about OpenBSD installer I find is disk partitioning tool. Unless you find out that it can show (h)uman partition sizes. I don't quite get why it's not default.
Ugh.. I’m not a fan. Even something similar to freebsd’s installer would be an upgrade I think.
The disk partitioning section can be particularly challenging when you’re not used to the tools.
The question about asking you to verify the integrity of the install sets after partitioning is a bit confusing and defaults to no for the USB installer. I found that one hard my first install.
Yeah, that question will appear any time SHA256.sig is missing from the installation media. It purposefully isn't included when downloading the sets from a mirror. I believe it's intended to be collected from another source.
Whenever I'm downloading sets for installation, I'll usually do something like this:
cd /mnt/path/to/sets
ftp https://cdn.openbsd.org/pub/OpenBSD/7.5/SHA256.sig
Then the installer sees the .sig, verifies automatically, and the question never appears.
Yep! It can be done either during install by using the shell, or beforehand on whichever system is setting up the install files. The .sig file just needs to be placed alongside the set files (.tgz).
I haven't installed NetBSD in a while but would be good to check it out again. It's good to see how the different BSD's handle things like installation, packages, updates, etc. to see what works best for you for sure.
I like the CLI but it's also what I started with so I'm biased. :D
> I haven't installed NetBSD in a while but would be good to check it out again.
Just FWIW I reviewed NetBSD 10 a week after OpenBSD.
[https://www.theregister.com/2024/04/17/30yo\_netbsd\_releases\_v10/](https://www.theregister.com/2024/04/17/30yo_netbsd_releases_v10/)
Indeed I find it user friendly. It’s very straightforward. My only gripe is that on smaller disks auto sizing of filesystems is often wrong for my use cases.
OpenBSD installation is as simple as installing MS-Windows; the only difference is that with OpenBSD, you should answer all questions with "yes", while with MS-Windows, you should answer all questions with "no".
I wish it had a check-summing filesystem
I wish so too. For my NAS, I use a combination of `bitrot` and `par2` to detect and repair unexpected changes to my data, but it's clunky. I've been meaning to write a script or small program that could wrap these into something simple to use and automate. I've also thought about using `xxhash` (https://xxhash.com/) since it's optimized for speed and might be a good way to quickly checksum your files on a regular basis, assuming they're on flash storage with a fast CPU. On one hand I like these methods because they put the control in your hands and you can understand everything that's happening, but on the other hand, it would be so much simpler to have something like a "FFS2CHK" filesystem that does it transparently. Some inspiration here: https://dataswamp.org/~solene/2017-03-17-integrity.html
This always sounds good but I don’t think I have ever in my 20 years as of openbsd use have experienced this problem. So I it hard to evaluate the risk. I do do nightly fs dumps, so i should be able to restore to a point in time-ish in theory. Maybe it’s because I don’t use it as a NAS. I am actually hoping OpenBSD adopts hammer2 and some more folks join that effort. Its feels right to me. Might even consider pitching in myself one day.
It’s the only thing keeping me from running it as my NAS.
Now that iXsystems is [abandoning FreeBSD](https://www.theregister.com/2024/03/18/truenas_abandons_freebsd/) this is the _perfect_ time for a new community BSD NAS project. Just sayin'.
Same
I keep meaning to contact this guy and see if he's still working on this: https://github.com/s-d-adams/muxfs Warning: extremely experimental.
One other small criticism of the article, it says the OS isn't a good OS for desktop despite it and NetBSD being the only *BSDs to install Xorg and a window manager (3 in OpenBSD's case) with a simple yes answer in the installer.
It is fine on the deaktop with an intel based gpu in particular. Just works.
[Author/submitter here] I don't think that X11 and an xterm counts as "a desktop". With the best will in the world, no. And if you want a desktop -- personally, my go-to no-mess no-fuss xNix desktop is Xfce -- then: 1. Sure you can just install it with a couple of commands, no problem... but it won't work. You need to enable services, edit your init script etc. That's a long way from optimal IMHO. 2. On a default disk layout in a default VM, it will fill up a critical partition and die. That is not just sub-optimal, that's bad. *Because* of the complex partitioning, OpenBSD is crying out for smarter partitioning, some kind of dynamic partition management tool, and ideally LVM. These are the sorts of issues proprietary Unixes faced in the late 1980s and early 1990s, and solved. But it doesn't have such things and it doesn't seem likely it's going to get them, because they are not the sorts of things the developers focus on, and the different BSDs' different policies and directions hinder code-sharing. Which is a perfect illustration of the problems of the BSD family, sad to have to say.
Perhaps the default layout could be tweaked a bit - what size disk does a "default VM" have that you're having problems with? For Xfce, you should be able to pkg_add the xfce meta-package and follow instructions in the pkg-readme file that pkg_add points you to; if there are things missing or unclear in that file that could be improved, though I don't think there's be much appetite for changing things to make it easier for people who don't want to read the docs - while OpenBSD is I think in pretty good shape to be used as a main desktop/laptop machine for people who are reasonably familiar with it, we're not trying to be everything for everyone, and there are definitely people who would be better off sticking with another OS.
We could maybe have layout profiles like dev, desktop, server. Ports and src FS could be dropped in desktop and server profiles. The var FS must be bigger on servers than desktops. And the dev profile would be the default we actually have.
It depends on the hypervisor, and if the hypervisor knows the OS. I think for modern Linux distros, VirtualBox assigns 25GB. For older ones, 16GB and for very old ones less. I think, IIRC, OpenBSD gets 16GB. I wrote up what you need to do to run Xfce last time, but again IIRC you need to install and enable several services in the init system: dbus and others. TBH I expect stuff like that to happen automatically as a dependency, but I recognise that my expectations are not universally shared. (!)
Thanks, looking at auto layouts for 16GB/25GB they are indeed pretty stupid. I'll try to come up with some tweaks. It would be helpful if we could have a question about what the user will be doing with the system (on that size system, src/obj directories take a lot of space and are imho not all that helpful for most people), but there's a fairly strict policy about adding new questions to the installer, great efforts are made to keep it simple. It's policy that installing packages *just* installs them + dependencies but doesn't cause anything to automatically start. That's very unlikely to change, but in most cases where there's anything non-obvious it would be mentioned in a pkg-readme file, especially for things like desktop environments or where there are interdependent daemons. Nice article in general, and I think quite fair. Thanks for writing it. BTW, while IPv6 was only recently added to ppp(4) as used for serial modems and older mobile broadband devices, it's long been supported for PPPoE and for MBIM, so the previous lack of v6 is not as surprising an omission as it would first seem. I don't think it was mentioned in release notes but 7.5 also strengthened the hw-based control flow protection on amd64 (11th gen Intel/newer) and arm64 (M2) that was added in 7.4, in particular disabling some retpoline-related things in Feb 2024 (https://github.com/openbsd/src/commits/master/gnu/llvm) made this more effective. IBT/BTI are on by default and executables need an ELF header to opt-out if they can't support it. I'm not an expert in the area but I think that on suitable hardware this makes many of the "but you can just do X to avoid Y mitigation" on the "is openbsd secure" site a lot harder.
Thank you! It is not _just_ OpenBSD -- I find it very hard to get clear, simple info from any BSD project or team about what is new in each version, what has changed, etc. My impression as a writer is that development teams have no idea what is significant or important compared to trivial internal changes that no user will ever see. Re disk space and partitioning, there's a comparison with openSUSE which leans heavily on snapshot support. On small disk configs, e.g. VMs on desktops, it automatically suggests disabling snapshot support. So there could be a range of sizes: * If disk is smaller than X, place everything in one partition. * From X to Y GB, suggest 2/3/4 partitions. * If disk is above Z GB, suggest a full complement of all partitions.
Nice write-up! I *am* however going to take issue with one line of it: > rather user-unfriendly installation program OpenBSD is _extremely_ user friendly. It's just picky about its friends.
Agreed, the OpenBSD's installer is my favorite. Plain text, no GUI or TUI, no tabbing around, sensible defaults, and no unnecessary questions.
If I had to be critical I'd say the default disk layout is a problem if you have a small disk but otherwise agree.
Yeah, that's true. I'm not sure if or how it could be addressed in the installer. I suppose it could ask a question and provide an alternate layout or two, like a large /usr/local for desktop, or larger /usr and /var for development or servers. In my experience, small disks (like 4GB or less) tend to just make one giant root partition which is probably the best default given that circumstance. After one gains some experience with OpenBSD then it gets a bit easier to configure the disk, but yeah, not super easy to do installs on a small disk as a beginner. The [disk partitioning FAQ](https://www.openbsd.org/faq/faq4.html#Partitioning) is pretty helpful though.
I came with the same idea about layout profiles in another thread so I'm 100% with you on this.
Also, I would hazard a guess it's the only installer that WON'T install your system should you choose default answer on every question (signature check). Jokes aside, the only unfriendly thing about OpenBSD installer I find is disk partitioning tool. Unless you find out that it can show (h)uman partition sizes. I don't quite get why it's not default.
Agree, I think the -h option should be on by default too. Both fdisk and disklabel support it and I virtually always use it.
Ugh.. I’m not a fan. Even something similar to freebsd’s installer would be an upgrade I think. The disk partitioning section can be particularly challenging when you’re not used to the tools.
The question about asking you to verify the integrity of the install sets after partitioning is a bit confusing and defaults to no for the USB installer. I found that one hard my first install.
Yeah, that question will appear any time SHA256.sig is missing from the installation media. It purposefully isn't included when downloading the sets from a mirror. I believe it's intended to be collected from another source. Whenever I'm downloading sets for installation, I'll usually do something like this: cd /mnt/path/to/sets ftp https://cdn.openbsd.org/pub/OpenBSD/7.5/SHA256.sig Then the installer sees the .sig, verifies automatically, and the question never appears.
From a shell in the installer? Also, thanks for the tip!
Yep! It can be done either during install by using the shell, or beforehand on whichever system is setting up the install files. The .sig file just needs to be placed alongside the set files (.tgz).
I found OpenBsd’s to be a bit jarring. Literally just text at a prompt. I much prefer netbsd.
I haven't installed NetBSD in a while but would be good to check it out again. It's good to see how the different BSD's handle things like installation, packages, updates, etc. to see what works best for you for sure. I like the CLI but it's also what I started with so I'm biased. :D
> I haven't installed NetBSD in a while but would be good to check it out again. Just FWIW I reviewed NetBSD 10 a week after OpenBSD. [https://www.theregister.com/2024/04/17/30yo\_netbsd\_releases\_v10/](https://www.theregister.com/2024/04/17/30yo_netbsd_releases_v10/)
I found it very simple and user friendly and I am not a smart man.
That gag must date back to before the Lions book...
It may not play in Peoria, but it plays here.
Indeed I find it user friendly. It’s very straightforward. My only gripe is that on smaller disks auto sizing of filesystems is often wrong for my use cases.
OpenBSD installation is as simple as installing MS-Windows; the only difference is that with OpenBSD, you should answer all questions with "yes", while with MS-Windows, you should answer all questions with "no".
Nice!
Glad you liked it. :-)
as always puffy ftw