OpenBSD fares far worse in performance than Linux and its BSD cousins because they actively avoid supporting CPU, memory, and other features that increase performance via some shared resource because these are often vectors for information leakage and attack.
Everyone else has taken the approach of utilizing these features and getting the performance, but mitigating attacks (or class of attacks) as they are are discovered. Which is not a worse approach per se, especially if your project places a higher value on raw performance (or performance per dollar spent) and you can strengthen security at other layers.
Thanks. I am aware of that test but it is two years old and OpenBSD had quite a few optimisation in between. Hopefully we will have some update test from Phoenix again once FreeBSD 14 releases.
Indeed. There's been a lot of work towards unlocking the kernel and network stack (removing "big locks" that force code to run serially), so it would be cool to see some iperf tests on the same hardware with different OpenBSD versions.
I believe it's an Intel-managed distribution and is heavily optimised for Intel hardware. Not surprising it did so well as the tests in that article were done on an i9.
Clear Linux OS defines its minimum hardware requirements to be second-generation Intel® microarchitecture code name Westmere (released in 2010) or later.
phoronix benchmarks are bad on average, but this one is particularly garbage.
it doesn't make sense for zstd to be performing orders of magnitude slower on some OSs, because the bottleneck (at least at higher compression levels) is pure userspace code. as I recall, someone on the freebsd mailing list found that the actual speed is almost identical, but zstd used a totally wrong timing API on freebsd. phoronix also uses totally different zstd versions and only sets the compression level the same, ignoring that the achieved compression ratio may vary greatly between versions for some special data.
considering these basic errors, the whole benchmark should be considered garbage in garbage out and not useful for any real purpose.
seriously the best operating system i have ever used, and i've tried ubuntu, debian, alpine, gentoo, osx, windows, solaris, freebsd, netbsd, openwrt.
it's also one of the best products i have ever used, staying consistent, being well documented, extreme application of principle of least surprise. learn it once, use it forever kind of product.
regularly scheduled updates, extreme focus on technology, hardly any politics. if we want software development to become engineering, this is probably what it's going to look like.
Look, I'm a big fan of OpenBSD (and use it myself), but journaling filesystems are many decades old at this point, and they have very clear advantages. One is not to have to sit through an excruciatingly long fsck after a power outage, with a real chance to lose data. This is not an esoteric scenario.
OpenBSD will be better once it adopted a journaling filesystem, until then nobody claimed it's "bullshit".
On OpenBSD 6.x, after power outage/intel drm kernel freeze I had catastrophic data losses. This is not acceptable for me on a desktop/workstation OS. Linux FS stability is better since the 2.4 era in my experience.
I wasn't quite as bad for me, but every once in a while, after a power outage (or the very, very rare kernel panic), I need to get out the laptop and the serial cable to manually fsck my headless server box, because the automatic fsck wouldn't continue on its own.
It's pretty annoying, to say the least. But OpenBSD is such a fantastic system overall, I keep using it, and just wait for them to adopt a journaling filesystem. (And have good backups.)
OpenBSD just refuses many things that are must have, like Nvidia, ZFS, .. so it's not a option for all things. For things it can do, it's often the best.
It's crazy that they did an entire release with no obvious major big new features, only a hundred small improvements here, a hundred small improvements there. I wish Apple could do the same with macOS.
Evey time BSD news gets posted, I always come in the comments looking for reasons to switch from Linux. There is consistently high praise accompanied by not so minor grips that make me stick with Linux.
Anyone got a strong, concise argument for or against BSD over Linux for desktop use?
> Anyone got a strong, concise argument for or against BSD over Linux for desktop use?
For desktop it should mostly depend on you. Does the things you personally run on a regular basis even work on BSD?
Unfortunately mine don't (terraform: too few providers support BSD and the one's I specifically work with do not). Yes, I could run terraform within a virtual machine on the system but that's heavier than I would like it to be.
If you eventually want some multimedia (3d, videos, etc), probably you won't like BSD. (opinion based on 4 year old experience)
I have used OpenBSD and NetBSD on desktop and servers. While they have their merits, as a Windows and Mac poweruser I have always felt some void. Linux is bearable from this perspective, BSDs were really far from the limited-priviliege user dynamical reconfigurability needed for a road-warrior notebook user. Linux is almost there.
If you have a mostly static setup and a sufficiently outdated Hw setup, you might be able to play high resolution youtube videos. If no other audio is holding the audio device. (though last time I used NetBSD had OSSv4 in the pipeline, and had limited success on openbsd, if all streams had the same sampling rate)
Oh, and OpenBSD managed to loose my data. (I liked many aspects of the system despite the above, but after this it got on my nope list, this was not acceptable even 30 years ago)
I was using softdeps on OpenBSD 6.4, on an old Thinkpad x200.
Once the battery ran out unexpectedly (old battery reporting incorrect remaining time), while I was doing some downloads and compiling a package. The system became unbootable because of filesystem corruption, after fsck and overwrite of system packages from other boot media I noticed extensive data loss.
After clean reinstall experiencing intel drm driver kernel panics during ports install the disk became corrupted once again, with some files lost.
I reinstaled the system once again and with disabled intel drm and softdeps the system worked for a while, but was slow as an ancient pentium.
I reinstalled windows and the machine worked great for years afterwards (with the wifi being a bit choppy, which was perfect on openbsd) for some tasks I needed a semi-portable windows machine (running some windows only plc programming tools).
The ssd was healthy, memcheck did not find memory errors. I reinstaled my openbsd server with linux which was running ok meanwhile, but now I can sleep assured that my data is mostly safe.
> Anyone got a strong, concise argument for or against BSD over Linux for desktop use?
Let me try.
First up, it is extremely possible that OpenBSD is not for you. If you require something that is Linux specific, or you absolutely need Bluetooth or one of the other few things that you don't get with OpenBSD, and you are unable to refactor your life to not need those things anymore, then OpenBSD is a no go.
If that is not a concern, the strongest argument I can make for OpenBSD is that it's an operating system that wants you to trust it. It's written by people who understand system correctness matters above all else (and security just happens to be a nice side effect). Most of the time, this has only small and subtle user facing effects: good documentation, sensible defaults etc. But it really shows when you use it for a long period of time and see how over and over again, a decision made 10 years ago made OpenBSD somehow immune to the burning zero-day crisis of the day.
OpenBSD itself is a very capable and secure, but also very clean operating system. Everything feels as if it's out of "a single mold", much unlike e.g. Linux which is, in a sense, clearly cobbled together from many different pieces.
Changing the system is a breeze, documentation is extremely clear and detailed, and it just "doesn't get in the way".
That doesn't mean it's the OS for you. There are disadvantages with using a less common operating system, and it does require a certain mindset of liking to tinker with a UNIX-like operating system. I don't use it as a desktop OS, but for various servers.
My concern is lack of support for certain things and flexibility.
To be fair, I have very little knowledge of what's supported and what's not. If it help, here's 2 things I love about Linux:
1. The dev experience. This is obvious. Great package managers, native container support, etc. It all works great and feels snappy.
2. Ability to do obscure things. For example, a family friend may want a bunch of pictures archived. I can mount his google Drive with rclone, grab all of his pics and burn them to a blu-ray. Obviously, this is not an everyday use case but I appreciate the ability to do these types of things if I ever need to. I don't want to have to spin up a VM to support these odd one offs.
the ports often dont work (or require a rodeo-size production to get them to work). A couple of years ago I installed FreeBSD, went to ports and did a "make install clean" of vim, and it wasted 10 minutes of my time only to fail on some arcane package's compilation. I asked for help and was told that "ports are not the OS, contact the ports maintainer for your pkg", technically true, but they tout their ports as this awesome, universal collection of amazing software. (the real workaround is for common packages like vim, you use "pkg install vim" and it installs binaries). The beauty of ports (if they worked) is that you can do cool things with the USE flags (this should be familiar to Gentoo users, my mind is drawing a blank though for a concrete example to explain this to someone unfamiliar).
Recently I tried to install prolog on OpenBSD-7.3, it failed even from pkg. I didn't want to waste my time on ports, so I just wiped the OS from my machine (running neofetch takes a couple seconds, which gives you an idea of how slow it is, however if I ever needed a very secure machine (such as an SSH bastion or anything internet-facing) I wouldn't hesitate to pull it up again.
FreeBSD is almost usable as a desktop though. Only thing keeping me is audio wont work over HDMI/DisplayPort, but I totally understand they don't have time to fix all that hoopla. A pro OR a con, depending on your POV is that FreeBSD support really expects you to put your big-boy pants on when you ask for help. They get (justifiably) annoyed if you dont RTFM and concisely lay out everything you tried to do to fix it. For various reasons, the Linux ecosystem is way more tolerant of SO-style "how do I do X on linux" type questions.
> Only thing keeping me is audio wont work over HDMI/DisplayPort, but I totally understand they don't have time to fix all that hoopla.
What video card? I've got a half done patch for Intel that might help, a little. Some things are easyish; there's a flag I forget the details of that got audio devices to show up, in the likely event that boot time firmware didn't set things up properly. Some things are much harder; at least on haswell era intel video, audio and video clocks are linked, so the audio and video driver really need to communicate, but (when I was last looking at it) there's no plumbing for that in FreeBSD, and the video driver is imported from Linux anyway. Some things seem impossible; on the machine I using HDMI audio with, the audio device stops responding overnight and rebooting is the expedient way to get it back; there's probably something better, but I dunno.
Right tool for the right job. I used to say OpenBSD is great for routers and firewalls, but honestly it's so left behind in performance and Linux has gained so much with eBPF that Linux is looking like the better option now.
I used FreeBSD on my desktop way back in 2000-2008 but today after 9 years on Fedora it seems like the stoneage.
UFS/FFS is well tested code and won't corrupt itself, but it lacks the checksumming to detect data corruption from unreliable hardware/firmware/drivers.
I had a power outage corrupt UFS and another indecent due to a kernel panic while debugging a WiFi driver.
I've run Linux on various filesystems for significantly longer and have never seen filesystem corruption - (excluding me not reading btrfs documentation right).
This deals with the 'original' Hammer, this is way above my head, and I don't know how much applies to either OS or the HAMMER2 so this is just me posting another link but:
"There are several major differences:
* All VOP operations related to the namecache... those using named
path elements like lookup, rename, etc... those are completely
different.
The biggest one is that our VOP_NRESOLVE() API is completely different
from the old VOP_LOOKUP() API. The old VOP_LOOKUP() API had to handle
numerous side effects and I don't recall the FreeBSD namecache
subsystem doing any namespace locking (beyond locking vnodes, that
is).
Also our VOP_NREMOVE() is fairly radically different... it's an all
in one call whereas the older VOP_REMOVE was paired with a VOP_LOOKUP
that stored side-effects (not sure if FreeBSD has cleaned that up yet).
i.e. old was LOOKUP(save side effects) + REMOVE(use side effects).
And DragonFly's is just NREMOVE().
* HAMMER uses a far more sophisticated buffer cache call-back interface
which allows HAMMER to veto write requests from the buf_daemon's (to
enforce certain write ordering requirements).
* DragonFly uses a locking model that I don't think FreeBSD has an API
for (our token locking model which releases held locks within the
model when a thread switches out and reacquires them when the thread
switches back in). If FreeBSD also has an API for this model this
would be easy to port (if not for all of the above issues).
* DragonFly uses a slightly different stacked BUF/BIO mechanic for I/O.
This would be easy to port (if not for all of the above issues).
* DragonFly's BUF/BIO allows for different buffer sizes within the
file buffers (not just the device buffers). Generally speaking
there can be significant mixing of buffer sizes and the cluster code
has to be able to deal with it given appropriate argumetns. I don't
think FreeBSD's cluster code could handle it.
Personally I think it might be too much for a GSOC project.
-Matt"
OpenBSD or NetBSD would be better than Linux if you wanted to delve into operating system internals, or you wanted to operate the OS at a more direct explicit level. They are more straight forward in their implementation - modern Linux has more layers of abstraction (udev, dbus, systemd etc) which are useful but more complex.
Other than that, it mostly would come down to licensing or subjective taste questions.
Maybe someone here would have advice for upgrading ancient OpenBSD installs?
I inherited some 5.x OpenBSD systems at my current job and I'm really curious how I'd go about upgrading to 7.4 - I have a feeling I'll be running into some broken links.
I'd really like to meet the person who was gung-ho enough to use OpenBSD in prod but seemingly treated them like a LTS system - not a "releases are supported for ~1 year" system.
It's possible, but you'll run into annoying breakage long the way. It's probably safer and less troublesome (unless you're deeply familiar with the changes along the way and the old upgrade procedures) to take the existing configurations as guidelines what to recreate on the latest release.
Probably the best method.
I believe most applications our either our own (some Golang tools, for some reason?) or basic base applications (migration to relayd instead of nginx as a proxy is probably a good idea.)
Make backups, make sure you can restore them, then just step through it one version at a time. Things got a lot easier around 6.6 when sysupgrade was introduced.
It looks like some mirrors have packages going way back (http://ftp.eu.openbsd.org/pub/OpenBSD/), but depending on your use-case, it may be more beneficial to focus on the base system upgrades (documented in the upgrade guide) and worry about the packages later.
That many years of package changes could be troublesome to deal with, and it may be better to fast-forward to whatever the modern tooling would be.
However speaking with my manager I think the long term plan is to dump it for RHEL - too bad because I'd like it on my resume :-) Not every day you can play with OpenBSD in prod - usually it's just on my oddball computers.
What are you using them for? I feel a lot more comfortable using OpenBSD in production than Linux for the long-term (my personal opinion). I've been using it since ~3.5, and the 6 months releases have been ticking along nearly flawlessly for a long, long time.
Yes I feel like OpenBSD can be a great system for this use case, but the prior owner of this system had neglected it. Now it's still on 5.6 and who knows how much cruft has built up.
It's currently acting as a bridge system that translates 5010 X12s to 4010 and vice versa. Strangely enough the whole stack in Golang which I don't believe considers OpenBSD to be a supported platform?
81 comments
[ 3.2 ms ] story [ 156 ms ] threadAnother story points to the full release notes:
* https://news.ycombinator.com/item?id=37899478
OpenBSD fares far worse in performance than Linux and its BSD cousins because they actively avoid supporting CPU, memory, and other features that increase performance via some shared resource because these are often vectors for information leakage and attack.
Everyone else has taken the approach of utilizing these features and getting the performance, but mitigating attacks (or class of attacks) as they are are discovered. Which is not a worse approach per se, especially if your project places a higher value on raw performance (or performance per dollar spent) and you can strengthen security at other layers.
Which means most pre compiled software targets CPU’s from 10+ years ago.
ClearLinux compiles for current chips, which gains the benefit of new instruction sets.
Clear Linux OS defines its minimum hardware requirements to be second-generation Intel® microarchitecture code name Westmere (released in 2010) or later.
source: https://www.clearlinux.org/clear-linux-documentation/guides/...
it doesn't make sense for zstd to be performing orders of magnitude slower on some OSs, because the bottleneck (at least at higher compression levels) is pure userspace code. as I recall, someone on the freebsd mailing list found that the actual speed is almost identical, but zstd used a totally wrong timing API on freebsd. phoronix also uses totally different zstd versions and only sets the compression level the same, ignoring that the achieved compression ratio may vary greatly between versions for some special data.
considering these basic errors, the whole benchmark should be considered garbage in garbage out and not useful for any real purpose.
it's also one of the best products i have ever used, staying consistent, being well documented, extreme application of principle of least surprise. learn it once, use it forever kind of product.
regularly scheduled updates, extreme focus on technology, hardly any politics. if we want software development to become engineering, this is probably what it's going to look like.
Plus with 7.4 you can use ktrace(1) to find memory leaks, I have been waiting for this release since it was announced a few month ago.
No more third party applications to look for leaks :)
FWIW, upgrading is the easiest of any OS I have work with.
Correction: I realized I've run it in vain attempts to recover SD cards. It always failed.
OpenBSD will be better once it adopted a journaling filesystem, until then nobody claimed it's "bullshit".
On OpenBSD 6.x, after power outage/intel drm kernel freeze I had catastrophic data losses. This is not acceptable for me on a desktop/workstation OS. Linux FS stability is better since the 2.4 era in my experience.
It's pretty annoying, to say the least. But OpenBSD is such a fantastic system overall, I keep using it, and just wait for them to adopt a journaling filesystem. (And have good backups.)
Now that softdeps is disabled and the vfs getting an overhaul I might try it again... in a few years.
Hopefully some acceptable filesystem will be added in the near future.
"This repository will be abandoned once Linux or FreeBSD is stabilized with write support. OpenBSD is not the main area of interest."
[0] https://github.com/kusumi/openbsd_hammer2
https://www.openbsd.org/innovations.html
OpenBSD just refuses many things that are must have, like Nvidia, ZFS, .. so it's not a option for all things. For things it can do, it's often the best.
@dang, can the link be changed
---
Not sure why the other HN thread was closed that used the actual source link.
https://news.ycombinator.com/item?id=37899478
https://www.openbsd.org/images/ImHappyBecauseEveryoneLovesMe...
Anyone got a strong, concise argument for or against BSD over Linux for desktop use?
For desktop it should mostly depend on you. Does the things you personally run on a regular basis even work on BSD?
Unfortunately mine don't (terraform: too few providers support BSD and the one's I specifically work with do not). Yes, I could run terraform within a virtual machine on the system but that's heavier than I would like it to be.
I have used OpenBSD and NetBSD on desktop and servers. While they have their merits, as a Windows and Mac poweruser I have always felt some void. Linux is bearable from this perspective, BSDs were really far from the limited-priviliege user dynamical reconfigurability needed for a road-warrior notebook user. Linux is almost there.
If you have a mostly static setup and a sufficiently outdated Hw setup, you might be able to play high resolution youtube videos. If no other audio is holding the audio device. (though last time I used NetBSD had OSSv4 in the pipeline, and had limited success on openbsd, if all streams had the same sampling rate)
Oh, and OpenBSD managed to loose my data. (I liked many aspects of the system despite the above, but after this it got on my nope list, this was not acceptable even 30 years ago)
can you elaborate please?
I was using softdeps on OpenBSD 6.4, on an old Thinkpad x200.
Once the battery ran out unexpectedly (old battery reporting incorrect remaining time), while I was doing some downloads and compiling a package. The system became unbootable because of filesystem corruption, after fsck and overwrite of system packages from other boot media I noticed extensive data loss.
After clean reinstall experiencing intel drm driver kernel panics during ports install the disk became corrupted once again, with some files lost.
I reinstaled the system once again and with disabled intel drm and softdeps the system worked for a while, but was slow as an ancient pentium.
I reinstalled windows and the machine worked great for years afterwards (with the wifi being a bit choppy, which was perfect on openbsd) for some tasks I needed a semi-portable windows machine (running some windows only plc programming tools).
The ssd was healthy, memcheck did not find memory errors. I reinstaled my openbsd server with linux which was running ok meanwhile, but now I can sleep assured that my data is mostly safe.
Let me try.
First up, it is extremely possible that OpenBSD is not for you. If you require something that is Linux specific, or you absolutely need Bluetooth or one of the other few things that you don't get with OpenBSD, and you are unable to refactor your life to not need those things anymore, then OpenBSD is a no go.
If that is not a concern, the strongest argument I can make for OpenBSD is that it's an operating system that wants you to trust it. It's written by people who understand system correctness matters above all else (and security just happens to be a nice side effect). Most of the time, this has only small and subtle user facing effects: good documentation, sensible defaults etc. But it really shows when you use it for a long period of time and see how over and over again, a decision made 10 years ago made OpenBSD somehow immune to the burning zero-day crisis of the day.
Changing the system is a breeze, documentation is extremely clear and detailed, and it just "doesn't get in the way".
That doesn't mean it's the OS for you. There are disadvantages with using a less common operating system, and it does require a certain mindset of liking to tinker with a UNIX-like operating system. I don't use it as a desktop OS, but for various servers.
To be fair, I have very little knowledge of what's supported and what's not. If it help, here's 2 things I love about Linux:
1. The dev experience. This is obvious. Great package managers, native container support, etc. It all works great and feels snappy.
2. Ability to do obscure things. For example, a family friend may want a bunch of pictures archived. I can mount his google Drive with rclone, grab all of his pics and burn them to a blu-ray. Obviously, this is not an everyday use case but I appreciate the ability to do these types of things if I ever need to. I don't want to have to spin up a VM to support these odd one offs.
Recently I tried to install prolog on OpenBSD-7.3, it failed even from pkg. I didn't want to waste my time on ports, so I just wiped the OS from my machine (running neofetch takes a couple seconds, which gives you an idea of how slow it is, however if I ever needed a very secure machine (such as an SSH bastion or anything internet-facing) I wouldn't hesitate to pull it up again.
FreeBSD is almost usable as a desktop though. Only thing keeping me is audio wont work over HDMI/DisplayPort, but I totally understand they don't have time to fix all that hoopla. A pro OR a con, depending on your POV is that FreeBSD support really expects you to put your big-boy pants on when you ask for help. They get (justifiably) annoyed if you dont RTFM and concisely lay out everything you tried to do to fix it. For various reasons, the Linux ecosystem is way more tolerant of SO-style "how do I do X on linux" type questions.
What video card? I've got a half done patch for Intel that might help, a little. Some things are easyish; there's a flag I forget the details of that got audio devices to show up, in the likely event that boot time firmware didn't set things up properly. Some things are much harder; at least on haswell era intel video, audio and video clocks are linked, so the audio and video driver really need to communicate, but (when I was last looking at it) there's no plumbing for that in FreeBSD, and the video driver is imported from Linux anyway. Some things seem impossible; on the machine I using HDMI audio with, the audio device stops responding overnight and rebooting is the expedient way to get it back; there's probably something better, but I dunno.
https://github.com/freebsd/drm-kmod/issues/187#issuecomment-...
If there's been changes in the meantime, you'll need to adjust the patch.
I used FreeBSD on my desktop way back in 2000-2008 but today after 9 years on Fedora it seems like the stoneage.
There is no docker and if you have to use it then it's a problem
Same might go for anything that needs NVIDIA
I really hope the work to port HAMMER2 to OpenBSD lands in -current (and someone will own/maintain it).
https://github.com/kusumi/openbsd_hammer2
OpenBSD lacking a modern filesystem has been an achilles heel for it.
EDIT: why the downvotes?
Notes This repository will be abandoned once Linux or FreeBSD is stabilized with write support. OpenBSD is not the main area of interest.
https://www.openbsd.org/goals.html
My concern though is this line from the readme
> "This repository will be abandoned once Linux or FreeBSD is stabilized with write support. OpenBSD is not the main area of interest."
I've run Linux on various filesystems for significantly longer and have never seen filesystem corruption - (excluding me not reading btrfs documentation right).
Here’s to hoping we get a modern FS soon!
"One does not simply own/maintain a new filesystem".
Also, I wonder how much of HAMMER2 is tailored towards the DF-BSD kernel?
Given that the same developer is porting HAMMER2 to not only OpenBSD, but also NetBSD and FreeBSD - not much.
https://github.com/kusumi
"There are several major differences:
https://wiki.freebsd.org/PortingHAMMERFS"Correctly recognize umass(4) floppy disk devices as floppy disks. " :)
Some like the license more, some feel the cohesion is better, documentation is valued, sometimes it's more secure for the purpose.
Other than that, it mostly would come down to licensing or subjective taste questions.
I inherited some 5.x OpenBSD systems at my current job and I'm really curious how I'd go about upgrading to 7.4 - I have a feeling I'll be running into some broken links.
I'd really like to meet the person who was gung-ho enough to use OpenBSD in prod but seemingly treated them like a LTS system - not a "releases are supported for ~1 year" system.
Make backups, make sure you can restore them, then just step through it one version at a time. Things got a lot easier around 6.6 when sysupgrade was introduced.
My only concern is if I'll find missing packages for such old releases - I guess that's nothing a VM wouldn't show though.
That many years of package changes could be troublesome to deal with, and it may be better to fast-forward to whatever the modern tooling would be.
However speaking with my manager I think the long term plan is to dump it for RHEL - too bad because I'd like it on my resume :-) Not every day you can play with OpenBSD in prod - usually it's just on my oddball computers.
It's currently acting as a bridge system that translates 5010 X12s to 4010 and vice versa. Strangely enough the whole stack in Golang which I don't believe considers OpenBSD to be a supported platform?