Can’t see myself switching to OpenBSD at this point, but I’d try it just for fun if the installation has improved enough.
In real life OS testing and evaluation, I don't get to dedicate whole machines to any OS. No OS is that special, that important, or that versatile.
I always dual-boot because that often uncovers weaknesses and assumptions in installers... just as the OpenBSD devels encourage people to fail hard, the OpenBSD installer itself fails hard in a multi-boot scenario.
Example, to recreate if you are curious enough:
0. Set up a new PC (or VM, it doesn't matter.)
1. Install Windows (say, v10 as it's easy.)
2. Add a random Linux distro. For best results, have separate /, /home and swap partitions.
3. Now, try to add OpenBSD to that.
For best results, do this by directing a friend who has never used Unix through the process, over the phone so you can't see the screen. ;-)
If that's too easy, partition the disk with MBR so you have to deal with logical partitions too.
Maybe it’s less hairy now.
If you don't need old school partition learn what you do need and move on. The documentation has always matched the experience with OpenBSD. I enjoy OpenBSD simply becuase I know where to find the documentation. Some OS's have so many variations that I'm overwhelmed.
Considering the goals of OpenBSD the partitioning is a feature and structural.
If you decide to put everything in one large partition (not really recommended), always make sure /usr/local is on its own partition. If you do not do that, some ports will core dump. If you use one big partition, you will need to disable an important security feature to allow the ports to run.
What ports are you talking about? I'm using FreeBSD as my daily driver, never had a port core-dump due to this.
OpenBSD prohibits this except when code is run from a partition that permits it by means of a mount flag. Otherwise you get a core dump.
And all the partitions are largely an availability feature: if errant code fills up /var/log then /home is still usable.
I'm aware of that if no partitions are filled it causes an domino effect if not on its own partition. I have ZFS quotas configured so surely that mitigates the issue?
Handy to know though.
"On platform X, you must do A."
"Huh, weird, that's never affected me using (thing that only runs on platform B)."
They assume since it's your disk you best know how to partition it. One is free to edit the default save them to file for next time.
If one wants to manage the details of a computer system with documentation describing the implications of each decision OpenBSD is perfect.
There are plenty of other operating systems that will most do the right thing. How many operating systems do exactly what you tell it to?
Then it shall have some documentation on system requirements.
I tried to install Freebsd on a VM with UFS as a filesystem and the show ended with out of inodes when installing the ports system. This in 2020 is a bit sad.
Really no idea why it insists on splitting it into 5 partitions when just a seperate /usr/local mounted with the wxallowed flag is mostly fine.
Other than that though it's mostly just hitting enter a bunch of times if you ever want to give it a shot again.
Because OpenBSD recommends having nosuid on everything that isn't /, /usr and /usr/local, and nodev on everything that isn't / (where /dev lives).
I just like the BSDs because they all maintain a single document that can get you from a single system host install to a supporting network installs DHCP->TFTP install.
I always go for either NetBSD "We install on anything" or OpenBSD "We are still just trying to get secure implementation of the 4.4 spec"
Unlike some other operating systems, OpenBSD encourages users to split their disk into a number of partitions, rather than just one or two large ones. Some of the reasons for doing so are:
• *Security: Some of OpenBSD's default security features rely on filesystem mount options such as nosuid, nodev, noexec or wxallowed.*
• *Stability: A user or a misbehaved program can fill a filesystem with garbage if they have write permissions for it. Your critical programs, which hopefully run on a different filesystem, do not get interrupted.*
• *fsck(8): You can mount partitions that you never or rarely need to write to as readonly most of the time, which will eliminate the need for a filesystem check after a crash or power interruption.*
[1]: https://www.openbsd.org/faq/faq4.html#Partitioningnot at all practical on a router with a underpowered cpu and little disk
apparently the developers have had a change of heart here (previously they didn't believe in providing binaries for security fixes)