Interesting to see OpenBSD continuing to gain hardware support. I've been running it on a small home server for DNS/DHCP and the stability is remarkable. The man years of auditing really show.
> Even if it feels it should be simple, Linux has a way.
As someone who has run DNS and DHCP servers for over 30 years and continues to do so, this just feels like confirmation bias based on your personal anecdotes. If there's an issue, it's likely due to messy over-complicated distros. Alpine is no less solid than OpenBSD.
Nah, whenever I'm involved in a cloud cost audit, I routinely find boring unfashionable Ubuntu and RHEL servers someone forgot about with 5 year uptimes.
It's a new account, and by default new accounts have their posts flagged/dead I think?
FWIW my guess is you're right - this user looks like a bot based on this comment and their other one; I've noticed that somewhat-vacuous praise for a post is a bot tendency. Although it's also a human tendency, so maybe too soon to tell. What a world.
The artwork on the store may have been an earlier (non-final) version, or there's just simply multiple variations, which is usually the case for the t-shirt art.
Job Snijders works closely with the artists each release, and runs the store.
Edit: oops, bad eyesight led my brain to believe "no way this is legible text" when in fact it is. Needed a screen magnifier to read it clearly. Though the other items have police in place of security.
My bad. I have poor eye sight and on my first look the fonts appeared jumbled. On second look with a screen magnifier I can see it reads security while the others read police.
With all the security issues constantly being uncovered in other Operating Systems - which will only accelerate with Ai - it’s time everyone considers OpenBSD. Their decades-long security-focus is second to none. We have fully converted from Ubuntu/Debian to OpenBSD. No looking back.
I tried OpenBSD recently and found it behaves very differently from other OS. The same code works on Linux/FreeBSD/Windows but has poor multi thread performance on OpenBSD, async socket stopped working after sending at high speed for few seconds. I am not saying there is anything wrong in OpenBSD, it is just different.
OpenBSD uses a Giant Lock model (simpler code) instead of the fine grained locking mechanism in Linux. And Linux has a some quirks and hacks to improve performance (instead of doing the slow, but correct thing). One example is the USB Gadget thing.
This is not wrong per se, but they also try to reduce/remove this giant lock as much as possible. If you see entries like "Unlocked socket splicing." in the changelog, then this is one more case where the giant lock is not needed and in which therefore all cores can be used.
Is the code you ran on your OpenBSD available (e.g. on GitHub) for others to test?
Curious what async issue you faced, did you report it? Or ask for help addressing?
I just switched to single thread and didn't try to fix the issue. Single thread is fast enough to me, it has throughput ~ 730 Mbits/s in a OpenBSD 7.8 vm on a 7th gen i7 linux kvm host.
I was looking at that thread and honest question: how does Qubes OS deal with the binary blob issue?
I would guess it is deblobbed to a certain extend according to [0]
But I couldn't find if they have a strict "no binary blob allowed" policy like OpenBSD.
The “kernel” in Qubes is arguably Xen rather than Linux, and that’s where the security boundaries are supposed to be defined rather than within VMs that may be running any OS. VM compartmentalization as a security mechanism is hard to compare to a more conventional Unix like OpenBSD.
It's not just Xen, it also relies on the hardware-assisted virtualization (VT-d), which is virtually unbreakable compared to anything else. Most Xen vulnerabilities do not even affect Qubes: https://www.qubes-os.org/security/xsa/#statistics
You misunderstand the Qubes' approach to security. You isolate your workflows into separate VMs, so that security of a single VM doesn't matter. For example, my secrets are stored in a dedicated offline VM. All kernel bugs in it are just not exploitable. I open my online banking in a dedicated VM, in which nothing else is ever opened. Which attack vector do you think can be used against that?
(This site is extremely good and has fairly recent coverage, point-by-point, of all OpenBSD's mitigations. An important subtext to take to this is that OpenBSD has a reputation for introducing mitigations that exploit developers make fun of. Some of them are great, some of them less so.)
The slides are over 6 years old. The developers' attitudes haven't changed much, but are all of the arguments still valid?
I've followed this discussion here and there over the years and it always goes like this:
1) everyone makes fun of the mitigations
2) many even outright assert they can easily defeat and exploit OpenBSD
3) nobody provides a working PoC when asked to demonstrate how insecure the OS is
And somewhere in the mix there's also you and your usual blabber, also without any substantial examples of how insecure and exploitable the OS is. Always.
I have now read all of the points in the mitigations section. Just like the slides, the commentaries to the mitigations willingly assert uselessness and imply a sense of absolute insecurity, but without specific or even general examples.
So I'm looking forward to your careful explanation of how insecure the whole thing is and how easily it can be dismantled. Because I really want and need to know. Let's talk.
Cool! Trying out new ideas is very good way to open mindsets, even if those systems aren't used regularly, they serve as inspiration for future improvements.
It has some pluses, I miss an updated version of "The Design and Implementation of the FreeBSD Operating System", but it is understable there are other priorities and putting such a book out is lots of work for very little money, given how much book authoring gives back.
It's not even close! It's nearly two orders of magnitude higher for Linux.
This isn't anecdotal or “vague opinion” CVEs are facts.
You can ask the follow-up question: Why is that?
And there are many reasons.
It could just be that Linux having more users/eyes means more bugs are surfaced ...
But you need to dig deeper to understand why OpenBSD is so much more secure,
the core team of OpenBSD proactively reviews the security of other OSes and when they learn something, they rapidly implement the feature/fix in OpenBSD.
Again, read: https://en.wikipedia.org/wiki/OpenBSD_security_features
Many of the proactive security features OpenBSD has are not implemented by other OSes. And in the case of kernel-level Crypto, they won't ever be because US export restrictions.
> And there are many reasons. It could just be that Linux having more users/eyes means more bugs are surfaced
You really brushed that one off, uh? The ratio of linux devices to openbsd is quite literally a million to one. The ratio of tech companies invested in linux to companies invested in openbsd is roughly 50,000 to 1. The ratio of professional security researchers paid to find flaws in Linux vs OpenBSD is harder to quantify at the moment, but I think we can guess a trend here.
I can agree to a degree that OpenBSD takes security more seriously, and they have made very interesting design decisions to enforce their security model. But I entirely disagree that the number of "CVEs are facts" to back your opinion that it is superior.
> This isn't anecdotal or “vague opinion” CVEs are facts
No they aren't, they're data. Your source shows the amount of Linux CVEs in 2024 are an order of magnitude higher than the amount of Linux CVEs in 2023. Does that mean Linux became way more insecure in 2024? You imply it does, but that's obviously not true. What happened is that Linux changed how they report CVEs [0].
Just like your source doesn't say anything useful about the difference in CVEs in Linux, it doesn't say anything about the difference in CVEs between Linux and OpenBSD.
This announcement thread really isn’t the place to discuss or debate the data.
The OP stated they couldn’t find any data to compare the relative security of Linux vs. OpenBSD.
CVEs are independently, objectively verifiable and provable data. This is the dictionary definition of a verified “fact”. It’s not anyone’s opinion.
You don’t have to like it or me.
Going by CVEs, Haiku is more secure than OpenBSD. Linux has had strong kernel-level crypto enabled by default on major distributions for years, see AF_ALG or LUKS.
On the wiki page you provided, the only thing that really stands out at the kernel level is KARL, which has a dubious utility: https://isopenbsdsecu.re/mitigations/karl/ It is not even up to date: strlcpy(3) and strlcat(3) were implemented in glibc 3 years ago.
> I would be in favour to say that out of the box OpenBSD is more secure than Linux.
Also important to remember that diversity builds strength. Just as in biology, if all organisms are the same, they all succumb to the same virus.
I have a multi-layered firewall approach where some are Linux, some are OpenBSD, some are commercial. They'll all have bugs, but unlikely they all have the same bug.
You are correct; OpenBSD is secure by default. And it's not subjective at all.
The homepage of https://www.openbsd.org proudly states "Only two remote holes in the default install, in a heck of a long time!" if they didn't have the evidence to support the statement, the internet would have forced them to remove it by now. ;-)
Remote (exploitable) holes are the ones we all care about.
The key (and not saying it's bad, mind you) is that the default install has very few services installed, let alone running or open.
So even if Debian and OpenBSD ship the exact same web server, but Debian has it defaulted installed and on, but OpenBSD does not, then a remote exploit won't count against OpenBSD.
All OpenBSD services, including HTTP (httpd), SMTP (smtpd), and DNS (nsd, unbound, unwind), use privilege separation and sandbox themselves with pledge and either unveil or chroot. There's no extra configuration. And the developers dog-food these services; it's why they're in the base system.
How many Linux services use seccomp? Or chroot, mount namespaces, or landlock? If they do at all, it's usually imposed externally by systemd or docker, in which case they usually run with overly broad permissions because there's no integration with the specific application code, thus the AF_ALG exploits in containers. On OpenBSD services continue to narrow their privileges after starting up so by the time an external request is serviced they have only minimal access to syscalls and the filesystem, often only read/write/send/recv syscalls, and if open is allowed only the specific files and directories needed to service requests. Typically even the network-facing daemon accepting TLS connections doesn't have access to the private key--you simply can't do that by running a vanilla service application in docker.
Does OpenBSD have bugs? Of course. The question is, which environment has more trustworthy backstops? The Linux kernel provides all the facilities, but they're not used effectively, for many reasons.
Isn't that a good thing for certain use cases ? If you are building an appliance type thing (say a storage or networking device) then you would want something minimalist you can add only the necessary services on. And arent those the types of devices the BSD (in general) are used for ?
Less attack surface always equals less potential for bugs/flaws/exploits regardless of how good red teaming tools and workflows get.
Now obviously for other use cases Linux could be a much better option.
There was a time when Linux distributions shipped lots of things on by default; OpenBSD bucked the trend and did not. This is less of an issue nowadays.
> This was the most critical vulnerability we discovered in OpenBSD with Mythos Preview after a thousand runs through our scaffold. Across a thousand runs through our scaffold, the total cost was under $20,000 and found several dozen more findings.
I'm saying you don't even need Mythos to find bugs in OpenBSD. GPT 5.5 is SO much better than humans at finding these things.
The fact that we don't even need Mythos, or $20k (I just pay $24/month and this was one of my MANY uses), to find bugs in OpenBSD shatters the dream that there exists any human who can write C properly with enough expertise, dedication, and time.
As I mentioned in the post, I only did a brief exploration of OpenBSD in order to cheer myself up. I took some findings, confirmed them being true bugs, and ended there.
As I said in the out of bounds null termination write patch, I don't believe it's exploitable. I would have gotten a CVE, website, and logo then (kidding!). But it was UB. And one-byte overflows have in the past been exploitable by better sploit authors than me.
In any case, I reported that since I felt it was clear that OpenBSD folks would obviously care about it, exploitable or not.
Confirming these findings take time, even though I found GPT to almost always be correct. I will NOT report upstream until I understand the bug. I ain't no slop reporter. As I said in the post OpenBSD (and all other code bases) need a larger effort. The Mythos/Glasswing effort focusing on actually exploitable ones may be a good method for getting them fixed, without overwhelming projects with patches, even when the patches are correct.
I did confirm at least one more UB, and did consider whether to report that OpenBSD `find` reads `status` via `WIFEXITED(status)` without checking `waitpid()` for errors. This is UB since `status` is uninitialized.
(https://github.com/openbsd/src/blob/ae684bfaed6cae797cd90e27...)
The reason is my previous experience with OpenBSD where the reply may be "<some standard> is wrong in this regard", and because they control their whole system, they don't care. E.g. in this case they may go "we build with GCC x.y.z exactly, and we know what actually happens in this controlled domain". This may be a bit unfair to them, but not by much.
GPT also flagged the extremely surprising behavior of running `cat -n file1 file2` if file1 doesn't end with a newline. And that `find /etc/passwd -execdir[…]` doesn't run the command. But maybe that's how they want it? I don't want to go through the whole thing for them to go "yeah we won't do that" again. So I think this project is for them. GPT is as available to them as it is to me.
Tangent: in running GPT against `cat` I learned that not only is `cat -n` not standardized, but it also behaves COMPLETELY differently than on Linux, if you provide more than one file.
It's not meaningfully more secure than e.g. Debian.
Their claim to fame ("only two remote holes in the default install in X number of years") is definitionally only valid for the default install in its default configuration which means: no httpd, no smtpd, no unbound, etc. etc. etc.
The default install isn't very useful, because it doesn't do a lot, and so "only two remote holes" or whatever isn't really saying much.
Linux has more CVEs because it's orders of magnitude more popular. OpenBSD has appalling performance, and more or less nobody uses it, so there just isn't a large focus on auditing and fixing it.
It's a great research project, but I would not run it on my personal devices. Not because it's "insecure" but because the putative security benefits do not merit the shockingly poor performance.
> The default install isn't very useful, because it doesn't do a lot, and so "only two remote holes" or whatever isn't really saying much.
Thats not really true. Comes with spamd, pf, httpd, OpenSMTPD and others. Its actually one of the open source unix-like systems that packs more functionality out of the box.
Great firewall and VPN server. You can setup wireguard with just ifconfig.
I get your point, but GP is right: You said "Default install", not enabled by default.
The default install is actually very useful, and includes a lot, like parent said. Having run OpenBSD in the past, I found the their versions of things were often superior, at least for small setups (and some of them for large installs as well.. probably : )
I use it on my ~10 year old desktop as my everyday OS. Performance may be measurably worse on benchmarks, but I never notice it doing regular stuff as a user. It's fine.
Easy to install and upgrade, sane defaults, good documentation, lack of waffleburgers of complexity, so I'm not sure why anyone wouldn't run OpenBSD in the first place. Granted I put Windows in the unusable bin and it's been there for decades now and sounds like it is getting worse, what passes for Mac OS X these days is not so good given that you have to disable some security thing to properly kill the annoying and disruptive notification system, among other annoyances still being fueded with, and I gave up on Linux after trying to support that waffleburger in production for a year or two.
With due mention to FreeBSD's jails, BSD's security image developed mostly from OpenBSD which is said to have gained its security focus due to NetBSD being so insecure that the NetBSD folks were able to hack into DeRaadt's forked OpenBSD.
Android's Bionic was based on or heavily influenced by OpenBSD's libc iirc, though.
No, not really. Linux has better options available and is significantly stronger when configured correctly. The OpenBSD approach ls largely based around eliminating bugs in the first place, but isn't as strong at limiting an attacker that successfully exploited a bug they missed or weren't responsible for.
These are the operative words. With OpenBSD, you get this out of the box and everything just works. With other operating systems, you have to do a lot of the legwork that's already been done for you with OpenBSD and make sure you didn't break things with your configuration.
These are words that when applied equally to Linux and OpenBSD, has Linux coming out ahead.
> With OpenBSD, you get this out of the box and everything just works.
With OpenBSD, out of the box you get a blank slate that really can't do anything, that you have to configure to do what you want, and currently can't be configured to be as secure as linux can be.
Sorry but that's simply not true. There are various cases where vulnerabilities didn't affect OpenBSD due to defense in-depth in OpenBSD.
OpenBSD has a pretty long history of eg. limiting attacks through compile time mitigations while making them more usable for every day use compared to specialized "high security" Linux distributions. This can also be seen in patches of third party software (in the ports (packages) system) that often have patches so the code can live with these limitations.
One example of such a mitigation is W^X. Implemented in OpenBSD in 2003, copied later by Windows, Linux and the other BSDs (incl. macOS).
More recently of course pledge and unveil were also added.
Also in 2003 OpenBSD was also the first mainstream (no research or test OS) that implemented strong ASLR that in 2005 was supported in Linux through third party patch sets.
It really is true. OpenBSD focuses on auditing. In many cases they were not affected because of mitigations, but because they were just using a different stack. OpenBSD wasn't affected by regreSSHion for example, for basically the same reason Alpine wasn't.
OpenBSD didn't invent the concept behind W^X, and if you want to talk of 'copying', which I think is kind of silly personally, then PAX was first.
I'm familiar with the list of OpenBSD innovations, and in turn I would point you to https://https://isopenbsdsecu.re/ for a breakdown of their claims and marketing.
To this date OpenBSD doesn't have anything as simple as a proper ACL, let alone any type of MAC. They claim such systems are too complex, which is of course nonsense.
It's like I said - they focus a lot on preventing an attacker gaining access, but have little available to constrain attackers who DO get access.
> there are numerous other things that are done for mitigation outside of this.
Sure, and I think they are mostly great, main problem being they just don't go far enough. Where's the namespace level isolation, ACL or MAC support? Is there a way to give a user append only ability for one file, while having write but not delete access to another, and delete to yet another? What's the maximum extent to which OpenBSD could have limited an attacker, had they been vulnerable to regreSSHion?
Don't make the perfect be the enemy of the good. Just because they didn't stop escape via dirtyfrag doesn't make them useless let alone a joke. pledge and unveil are nice, but exactly how effective do you expect them to be against an ssh/sftp server? Maybe you have ssh configured so it can't manipulate user and/or system files, but that isn't typically common usage.
How long did what take? Learning the essentials of OpenBSD, budget 4-6hours. Switching over servers from Ubuntu, an hour for the first one then 10mins each after that. You can copy config with your favourite tools; most have ports for OpenBSD already.
If you want to learn more in-depth, read: Michael W. Lucas
Absolute OpenBSD, 2nd Edition: Unix for the Practical Paranoid. Highly recommend it as teaches many fundamentals most software engineers skip.
Note that this specific symlink was special cased because sandboxed programs still need to access timezones. Also note that you would need to be root to create that special cased symlink. It's embarrassing, but less catastrophic than it looks at first glance.
Running security-critical code as root is still a bad idea.
Maybe I'm misunderstanding the video, but it looks to me as if the situation is:
You are root inside a sandbox. As root-in-the-sandbox, you create a symlink and this gives you the ability to escape the sandbox.
(Whether this is interesting or not depends on whether anyone actually tries to use the sandbox facility in such a way as to give root-in-the-sandbox privileges to untrusted people or code. I don't know enough about OpenBSD to answer that.)
unveil was designed and intended to effectively sandbox root when combined with sufficiently strict pledge permissions. I don't think this exploit would have effected any existing OpenBSD services, but sometimes services need to keep around processes with higher privileges than the network-facing process, yet you still want to sandbox them as much as possible. For example, sshd uses a special auth process, and that process needs higher privileges to be able to access the password database. On OpenBSD this auth process doesn't need root, but there may be similar cases where you want to use unveil with a root process for defense-in-depth. Suffice it to say, it would be foolish to only use unveil with such processes.
The bug here actually involved the intersection of unveil and pledge. IIUC, it was more a pledge bug that accidentally allowed bypassing unveil checks.
So what? You're still root. You're relying on a sandbox to plug a few voids while you still effectively held keys to the kingdom before said voids were plugged.
I hear this excuse daily from developers who insist on running all their docker containers as root "because we have to".
If you're relying on a sandbox as your first line of defense you've already lost the war.
Thanks. It was not evident from the example whether root inside of the sandbox is necessary - I assumed creating arbitrary symlinks doesn't require any particular capabilities, and there's nothing special about the locations.
Though it's not clear to me now:
- why was this patched then?
- is the point about root that non-root wouldn't have access to passwd anyway?
But the issue of root and accessing outside of the sandbox is orthogonal, no? Even if you're logged in as XYZ, accessing XYZ's contents outside of the sandbox is still a breach and a problem. Or does this issue require actual root to manifest?
This path was special cased used to allow restricted applications to access time zone files, which are needed for time functions. Not any symlink will do, it has to be the specific one shown in the example exploit, or one of a small handful of others that were special cased for similar reasons. The place these symlinks live are owned by root. This is the same root user outside the sandbox as inside it.
So, yes, you need to have root on the box to set up this exploit.
I see, thank you for your time and patience spent to explain this. So there's no elevation, no general escape, and this got patched because it could possibly be used as a set-up-use-later backdoor style thing (such as dropping a setuid root binary somewhere in the OS). Yeah, not a thing I would use as an argument that it's a terribly insecure system.
Your arrogance is continued proof you could never comprehend the work that goes into building, releasing, and maintaining an entire OS, and your contributions will forever be limited to snarky negativity on message boards.
OpenSMTPD was substantially rewritten in 6.4 (2018). It is the best SMTP server for the majority of use cases. Unfortunately, the portable version has been weakly supported, so it's usually only OpenBSD users than learn how great it is.
I used it a bit, had it installed for a while on a G4 PowerBook (must have been early-ish 2000s). I like the no-nonsense attitude towards blobs, security focus. Overall the experience was very good. The bit of code I read was also written nicely. I'll always endorse it and should really install it somewhere again in the near future.
We use OpenBSD for our VPSes on Hetzner, bare metal (for security focussed clients) and older (but still good) hardware in our Home Lab. OpenBSD is excellent on older (no longer supported by Cupertino) Apple hardware. We have an Intel Mac Mini Cluster with near-perfect uptime. If you need to run any kind of server (Web, Mail, DNS, NFS, Database) where you need stability & security, look no further.
Some learning curve, but totally worth it.
Have you tried such Openbsd installations vs FreeBSD? I forget the differences between OpenBSD and FreeBSD, so forgive the naivety. (I think NetBSD is more for embedded stuff, and Ghost and Dragonfly are more for conventional desktop use-cases if i recall correctly.)
I'm asking because i have not touched any BSD for over 2 decades...and I'm getting the itch to try some out...and was wondering if for server-type use cases (like you noted) whether OpenBSD is preferred over FreeBSD or the reverse, and why? Thanks in advance for any feedback you might provide!
FreeBSD is a heavier, more capable system, suitable for large servers. It's got its own virtualization platform (bhyve), an LXC-ish container system (jails), native ZFS, dtrace, Linux emulation, and a bunch more. It makes for a decent workstation and has pretty decent hardware support.
NetBSD is small and simple. It's a lot like an old-school UNIX. It makes a decent platform for small services. I run bind and dhcpd on a NetBSD machine. The source code is very pleasant to read. It uses the pkgsrc software repository. It's my preferred platform for writing POSIX code.
OpenBSD still carries much of the general feel of NetBSD and can fill a similar niche on a network, but the security focus stands out in their documentation, subprojects (OpenSSH, LibreSSL, OpenNTPD, etc.), APIs (see pledge(8)), and policies. It makes for a great firewall. I'd say it also requires the most know-how.
All of them have excellent documentation (especially compared to Linux distros) and the base system is developed alongside the kernel, giving you a very consistent experience compared to Linux distros where everything is developed in isolation. If you write C, it's worth keeping a BSD system around just for the manpages and to make sure you're not letting Linuxisms creep into your codebase.
Just to clarify. It's not emulation in the sense it's slower or something. They call it compatibility layer, which is better, but also nobody knows what it means.
This is simplifying a bit, but it's essentially "Linux is just a kernel" so the interface is just Linux syscalls, so the FreeBSD kernel when executing a Linux binary simply answers like Linux (so it has those system calls). How this is used in practice is that on your file system you have Ubuntu/RedHat/... "installed" (so the files and the file hierarchy are lying there) and you either directly or in a FreeBSD jail execute things in there or the binary you have.
I don't know how well it works in the present but in the past that means you could simply download the Unreal Tournament 2004 multiplayer demo or Enemy Territory or other games and just play them as if you were running Linux, 3D acceleration and all, without VM without real emulating, just the kernel providing what a Linux kernel would provide.
Also "heavy" is very very relative and subjective. You can totally have a tiny FreeBSD and a huge OpenBSD and one could argue OpenBSD is "heavy" because it comes with three window managers, an HTTP server, a full blown SMTPD server, ACME client and a ton of stuff that eg a server install of Debian or Ubuntu doesn't come with. But also if you run eg. ZFS things are heavy of course. FreeBSD has however had a time when it tried to strip a lot of stuff from the default install and make stuff either optional or make things available through ports/packages only.
And also there are surprises to be had with such overviews: Eg. your Lenovo laptop likely will give you a more "out of the box" experience on OpenBSD compared to FreeBSD with things like simple wifi setup, sound often doing the right thing (work, come out the right place, etc.) compared to FreeBSD. Also with stuff like HTTPD with ACME being available in a simple way after install I'd say OpenBSD is easier than FreeBSD.
FreeBSD to me feels a bit more like "it can be everything you want it to be". Ports and packages can be complicated if you just start out, compared to OpenBSDs "just use packages" stance. On OpenBSD things in my experience are more of a "it works or doesn't" and when it works often out of the box and/or with docs, while on FreeBSD it's more like it throws some tools into your direction you can build stuff (poudriere, jails, a build system with many options). So it's really cool if you want flexibility but a bit more like you have to figure out if it's possible and how. But that might simply be because of the use cases I used it for.
That said all of them are real general purpose systems, unlike eg. some Linux distributions. So it's not like "OpenBSD is for routers" even though it often seems like it. There are time when the GPU support is better on OpenBSD than FreeBSD's. But also FreeBSD has official NVIDIA drivers, so it's all not that clear cut.
I don't have much to disagree with there, only that any survey answer is the difference between complex things is going to be simplified. I'm thumb typing here and no one's paying me to write a book.
I will defend my "heaviness" argument, though. Sure, you can run OpenBSD on large hardware, but it's not going to be able to take advantage of it like FreeBSD can. Which makes sense if you think about it - FreeBSD optimizes for heavy workloads. Conversely, if you set up minimal installs, OpenBSD will be smaller. Again, that makes sense, since OpenBSD focuses on security over features (plus the only truly secure code is the code that doesn't exist). There's a lot of overlap in the middle, of course.
I wouldn't use OpenBSD for a NAS, and I wouldn't use FreeBSD for a diskless firewall. Not because they can't do those things - they just each have their strengths and weaknesses.
The "lightweight" nature of OpenBSD is a matter of perspective - if you are happy with OpenBSD's feature set, then it's a plus. On the other hand, FreeBSD has a lot of additional features, including ZFS, which may be of interest. The last I checked, FreeBSD was more performant in various benchmarks, particularly regarding multi-core performance.
FreeBSD has a bit more of a lax attitude historically to security[0] and seems to prefer being reasonably performant and "easy to use" (this is subjective, but they care about supporting packages outside of base very much, and bundle non-FreeBSD produced packages as part of their base).
OpenBSD on the other hand is perfectly happy to leave oodles of performance on the table for security. They were the first OS to completely drop Hyperthreading support for example, years before spectre/meltdown.
So with these things in mind, FreeBSD is a lot more performant.
FreeBSD has the same roots as OpenBSD but the former has a “compatibility” focus whereas the latter has the security focus.
Having a background in security, the choice was obvious for me. But each person/org should decide based on their needs.
Haven’t had any issues running it on all major hardware (Dell, HP, Lenovo, Apple, etc) the UI isn’t as pretty as macOS on Desktop, but it runs Firefox & Chrome, etc. so you can do everything you need.
If you have an older Lenovo or Mac lying around collecting dust, dive in!
There was FreeBSD and NetBSD. NetBSD supporting many platforms while FreeBSD supported just x86. There was some contention between NetBSD developers and Theo and crew left to create OpenBSD. They all more or less have common ancestry being derivatives of 386BSD.
Yeah, i knew there was some aspects of decendancy across the different BSDs.
And, I mentioned NetBSD for embedded stuff...but really, i *think* its that NetBsd is simply installed on tons of different hardware....so not only embedded....i kinda remembered that about NetBSD.
But, its the other BSDs - in particular FreeBSD vs OpenBSD - that i always forget the differences...but got it now. Thanks!
It can be customized just like linux where you can compile a custom kernel omitting unneeded features and then also ship a small userspace around it, and the core userspace tools are generally a little less feature rich than linux's already.
But it's not a matter of surface area that makes openbsd solid, it's the priorities while writing that affects how every little thing has been written over time.
You can write 10 different versions of a function that all work and are all nominally perfectly free of security gaps.
Yet they will all still be 10 different levels of robust. Some versions will fail as soon as some assumption is violated, and some make fewer assumptions and remain safe even when varying amounts and forms of "that can't happen" happens.
It's not just cosmic ray bit flips either, or a hacker trying to do power glitch attacks or rowhammer etc, stuff that makes the hardware violate it's promises. But stuff like a different developer updating something 15 years later who is not the original and does not realize every single facet of how it works and just how the current implimentation covers all possible edge cases, and so doesn't realize how their change opened up an edge case that was covered before. With fragile code, the new code simply has the new security gap until someone discovers it the hard way. With robust code, it's more likely to still be safe. The edge case maybe makes it fail to function, but not in a way that anyone can use productively.
Not that freebsd is exactly swiss cheese. These are all relative. I would and do rely on freebsd any day.
It's also superficial and wrong, and as bad as dividing people up by hair colour into blondes, brunettes, and redheads.
The way that the BSDs differentiate cannot be reduced in this way, not least because there is a lot of what Justin C. Sherrill (of the DragonFly Digest) calls 'cross-pollination' amongst the BSDs.
A case in point:
Superficially, and erroneously, one might observe that OpenBSD, NetBSD, and FreeBSD have nvi, and only DragonFlyBSD has nvi2. In fact there was a three-way fork of actual Bostic nvi, all of them making revisions and leaving the original behind, and then things got really complex with nvi2 taking from OpenBSD's nvi, and FreeBSD's nvi taking from nvi2; not even getting into the existence of nvi-m17n along the way and how there are nvis in base and nvis in ports. (https://news.ycombinator.com/item?id=48132452) One cannot divide the BSDs up into those that have nvi2 versus those that have nvi.
Yes, you're not at all wrong! However my goal is not to definitively 100% know the exact differences between the BSDs...i merely wanted to seek out a quick/easy starting point (the very high level diffs)...so that i can start *somewhere* and hopefully avoid my paralysis by analysis. :-)
It is a generalization of the essentials, and not wrong.
You know even though I said the execution is unlike linux, in fact, there are many many details that are just like linux! What a freaking ignorant liar eh? There's like 100 things like that you could say. No wait, no way it's exactly 100. There's obviously some other number like 105 or 612 things like that. So superficial and wrong!
OpenBSD does support some older hardware already not supported by, say, most Linux distributions. As an example MacPPC has’t had support from most Linux distributors since IBM Power went little-endian, but OpenBSD runs fine on it.
NetBSD is, however, the gold standard for an OS that runs on just about anything. Their (maybe unofficial) slogan has been “Of course it runs NetBSD!”. Their logo has a flag in it because they “plant their flag” on so many platforms.
100%. I put off learning/using OpenBSD for a decade until a breach at a client (we weren’t responsible for DevOps/SysAdmin) made me pick it up because I don’t have time to be a full-time Linux Sysadmin anymore. Just want the servers to run without having to think about them. Wish I’d done it sooner.
Lost at lot of time on Linux, Docker, K8s, etc. that I could have skipped completely with OpenBSD.
Our servers are an order of magnitude simpler now, just single services per VM and I sleep better. ;-)
> ...I don’t have time to be a full-time Linux Sysadmin anymore. Just want the servers to run without having to think about them...
Very salient comment there! And, while not the only reason for me, but what you noted is sort of one reason that's triggering the itch in me to go back to playing with the BSDs. Don't get me wrong, I still do love fiddling around with some areas of linux once in a while....but then, there are other uses/areas where i just want a server to do its thing, and for my maintenance to be a little less (at least less than some linux distros require). So maybe i'm not the only one? :-)
Yeah, time is finite and fleeting and the older I get the faster it seems to go!
As a teen I had infinite time to compile Linux and debug stuff. Now I just want to spend time with family/outdoors and not be stuck in a windowless room negotiating with a black box. ;-P
And, wow, do i miss the old X-window workstations...well, i should clarify that i LOVED those (I think they were Sparc?) workstations that ran Solaris or SunOS back in the day! Man, that takes me back some years...but i really loved those machines! :-)
OpenBSD supports sparc very well and is compatible with old sunos stuff (iirc). Unfortunately no 68k anymore (okay, technically there's a niche flavour of 68k that still is supported because of a very dedicated man in Japan)
Kenji Aoyama truly is aligned with the best of the hacker spirit. As for getting your hands on a luna88k, I have no clue. The only thing I managed to find was a broken one that sold for ~USD 750 at an online auction.
It's worth mentioning at this point that one can still get (Open)Solaris descendent operating systems: OmniOS, SmartOS, and Tribblix. The latter still has SPARC in its installation guide.
Another part of my nostalgia with those old workstations (besides the core OS) was the desktop environment, i think CDE or motif or something like that. Something about the look and feel of that DE i always thought was cool!
I've just setup a new ThinkPad with openbsd. You just need to put the firmware needed on a usb stick, mount it and run one command, fw_update -p ./ It wasn't hard.
I use OpenBSD among Hyperbola GNU/Linux, soon to be rebased from a deblobbed OpenBSD 7.0 hard fork. IT's dumb easy to setup too. Also, I daily use nvi, oksh, oed (a portable ed for GNU/Linux) among Xenocara and CWM, and this way the environment it's almost the same as OBSD but with a GNU/Linux kernel.
Yeah, I'm aware of FSFLA and Linux Libre, but Hurd is not ready yet and it's being worked on with LLM's (something really anti-GNU, as it's propietary SAAS).
I don't really see the LLM use as anti-GNU. It would be no different if the code was written in a proprietary IDE with fancy code completion. GNU doesn't restrict contributors to using exclusively free software for their contributions (if they did, they likely wouldn't have gotten very far considering how much work apple did on GCC). As long as the license is free and GPL compatible, it isn't inherently non-GNU (though, they'd encourage you not to use a SaSS for your own sake)
Now, is LLM code in the hurd a good thing? No, absolutely not. Ignoring the licensing limbo of LLM output that still isn't settled , LLMs make pretty bad code often enough that I wouldn't trust it to work on something as niche and relatively undocumented as the hurd.
A local LLM with GPL compatible input and with options to properly tag the source with a full backtracking of the code? Maybe, but that's not what's happening, but massive license laundering.
I want to use OpenSMTPD so badly, but it doesn't have proper support for authentication via LDAP (at least, as far as I can tell). It insists on reading plaintext passwords from the LDAP server, rather than BINDing as the user in question.
I use it on my personal laptop, essentially because I like how slim and simple it is.
Packaging is simple, kernel development and upgrade is simple, etc. Also the kernel code itself is written in a style I like, it's to the point, no useless abstractions, no fuss. I prefer it even amongst other BSDs I tried (netbsd and free*lbsd/dragonfly).
It just feels nice to be able to understand most of your system. It's not as fully featured as Linux, but there is a sense of understanding your system that is refreshing. A bit like if you're on vacation in a small and cute village where life is mundane and calming. At least that's how I feel with it. Mileage may vary.
A while ago I made some blog posts[1] diving into the source code of OpenBSD and FreeBSD (shameless self plug), but haven't had the time recently to write more.
Being able to understand the system, or at least being able to take a quick look when something doesn't work is very refreshing. Not to mention the outstanding man pages. Barely need to google things.
I used to run it on a laptop too, but the battery life was shorter and the laptop ran noticeably hotter than under Linux, so I eventually switched back.
That said, OpenBSD feels unusually coherent (ej. check wifi connection from terminal). The whole system has a level of consistency that's hard to find elsewhere, also between other BSDs.
I ran OpenBSD on my laptop 22 years ago. Back then, a full GUI environment with terminal, web browser, editor: 28MiB of memory for the whole operating system and user environment!
About 10 years ago we moved offices, and I was over checking out the new internet circuit and cabling in the office. The circuit was up, and I hadn't brought anything with me to connect to the network, but we had already moved some boxes of old stuff over.
I found a 10+ year old Dell Pentium III laptop in one of the boxes, installed OpenBSD to do some simple connectivity testing, and ended up with a full workstation install and using it for network monitoring and some other random stuff. It stayed in the network/server closet until we moved out of that building just a few years ago.
> there is a sense of understanding your system that is refreshing
That's why I used to run Slackware, and then foud Alpine to be the best - much better than Void or Arch IMO. Works well as a very minimal system, and I know everything very well because of it. It's an ideal approach IMO, the best of both worlds.
I run it. Home firewall, office desktops and laptops. It's pretty stable and I'm fairly familiar with it. Really simple if you know Unix. I hope it never goes away, not sure what I would replace it with. Linux is so complicated now, it's just too much for me to deal with
If OpenBSD dies (somehow, at this point so many things are maintained there (OpenSSH, LibreSSL, PF, Tmux, sudo kinda) that it'll always exist to a degree) one of the other BSDs will suffice. FreeBSD is bloaty but for the most part works fine enough
Not GP, but I mostly use: Firefox; Emacs; MPV; Keepass; calibre; xfe; mupdf;... Then a bunch of cli tools. There's a lot in base, so cli are mostly extra utilities like cmus, git, tig, ncdu,...
I would imagine that a lot of people who use OpenBSD on their laptops/desktops run a lean installation with one of the window managers in base (an ancient fvwm version, cwm which I find very nice and twm).
You can however have a full-fat desktop environment with xfce4 or gnome and applications like libreoffice, gimp, inkscape, audacity and so on if you wish. I've never tried KDE on top of OpenBSD base but I gather packages are in ports.
I think it is fair to say that the amd64 arch has good support. The i386 platform arch is on a 'best effort' basis these days which is understandable. I've never looked at the others.
SPARC is well supported (mostly because it's very good at finding bugs that wouldn't be big problems anywhere else despite not being 'correct') and big endian PowerPC (both 323 and 64) is fine, though hardware can be tricky since apple products tend to be so integrated that you can't really, say, replace a GPU because the support is poor
My wife and I are building a wedding rentals company. I'm responsible for the digital part and building a Ruby on Rails app deployed to OpenBSD. The entire thing runs on a cheap Supermirco U1 server in a rack at our home. :-)
open-bsd will always feel like a safe pick for anything in regard to vault or key holding ; it's not appropriate to run anything CPU intensive - but it's a very appropriate system for anything that just need to boot up and hold some data ; eventually expose a network interface.
I use it for my home router, a small home server, a personal VPS at https://openbsd.amsterdam and a development VM (mostly for testing BSD backends on portable software).
I wish I had an OpenBSD development laptop, but I don't have one right now.
Authoritative DNS (nsd) and email (opensmtpd) runs out of the box with minimal config on very low ram kvms. The documentation is fantastic, installation is easy; sysupgrade has been a big improvement, though I wish they'd slow the release cycle a little
I use it for home router, my laptop, several vms for various services, and on one vps I keep around should I need to quickly set something up. I keep a proxmox server for anything I can’t or won’t run on OpenBSD.
Been running it as my home router since 2.3.
I had it on a server for a very short time when I used hardware RAID but I replaced that quickly with FreeBSD for ZFS once I could afford to replace that old Dell.
I ran it on my personal laptop for several years when I had one, but having a work laptop for these past decades I don't have much use for a personal laptop. I would probably run it again on a nice portable when I retire. It would be nice to focus on being creative on such a machine. Coding and drawing mostly. I will continue to use Linux in my recording studio though.
I've been running OpenBSD on my main laptop for about a decade, as well as on routers. It has the most consistent and well-designed interfaces of any modern *nix other than arguably macOS.
It is, by far, my first choice for a router/firewall. It has so many niceties for this, all well integrated OOTB, and you can deploy something top notch in no time at all.
I use it for my mailserver (thank you openbsd.amsterdam), for the gateway in my homelab, a dedicated OpenBSD VMD machine in my homelab, and on personal machines (Macbook Air M2, a Thinkpad X220 and on a T480 that dualboots OpenBSD/FreeBSD).
For mailserver I think it is the best option. And for Gateway, PF is just wonderful.
But even on my laptops I enjoy it. It is rock solid, and I have pretty much no complaints.
Not really, but OpenBSD has been in my life for 25 years.
I used OpenBSD to create the firewalls for our LAN parties when I was at school.
The first shellserver I ran, on an UltraSparc IIi was OpenBSD, gave out accounts to my friends.
And then I used it as a firewall, both professionally and personally, for many years. Until the first Turris Omnia was released, and now I have retired even Turris for pfSense, which is FreeBSD I believe.
But the PF firewall in OpenBSD was superior, definitely to the syntax of IPtables.
To me Linux was a great server OS, and OpenBSD was a great FW/Gateway OS.
My home router, firewall and VPN gateway is an OpenBSD box, Intel N100 with quad 2.5G Ethernet. To be frank, Linux has better support for fighting bufferbloat with FC-CoDel, but pf is so much saner than Linux firewalls it's not even close.
WiFi is handled separately by a Ubiquiti UniFi system, but I don't trust Ubiquiti not to exfiltrate data after their underhanded attempt to turn telemetry on a few years ago. OpenBSD WiFI is somewhat mediocre, but it has improved in this release with experimental support for WiFi 6 after years of being stuck at 802.11n.
The closest you will get to the OpenBSD experience on Linux is with Alpine Linux.
>so much saner than Linux firewalls it's not even close.
This is a big one for me. I've run openBSD and Linux custom boxes as SoHo routers and I just cannot stand Linux firewalls, I've never liked them and IPTables is just terrible. Yes I know there are wrappers around it now but it's still the default everywhere and still used by lots of other software like Docker. I'm using OPNSense now which is FreeBSD based instead of completely rolling my own but I love that it is still BSD under the hood.
One differing opinion I will offer is that I find NixOS to be the Linux distro most in the openBSD spirit despite it being very different from a UX and config management perspective. Alpine is interesting, but it has its own security and compatibility issues, especially around MUSL libc which I have had cause many strange downstream issues over the years, I just hit one recently in JVM GC caused by its memory allocation implementation. I've stopped using alpine altogether because of them.
Work: I need a simple easy to use system that I can configure to meet third party compliance requirements without jumping through hoops. It really excels when you can mostly use the base system there, maybe couple services. For example it's so nice to just have a couple pledge/unveil lines for example in a Go service.
Also super nice for "set and forget" style stuff. For example "I just need a HTTPS server with acme and SFTP". That's something you get out of the box with no third party packages (so everything vetted, pledge/unveil for everything, maintenance just running syspatch and sysupgrade), which is really nice.
Personal: Private mail server, family website, a quick and dirty "watching streams together" service I set up to watch stuff with people not in the same place as I am. prosody to have XMPP for friends and family.
I would NOT use it for "people throw stuff at you" use cases (Linux and FreeBSD do a far better job there). But I absolutely love it for scenarios where you want very very low maintenance. For example that private email server. I don't have time to do big upgrade plans, or "hardening" systems or reinventing the wheel. I cannot afford to do privately what I do in a day job or consulting (setting up or maintaining really rather complicated infrastructure).
I have done that many years with Debian, but the Linux world sadly is a big complex and complicated mess. That's great, when I get paid to deal with it, but annoying otherwise.
And I don't mean that bashing wise. I use Linux, I like Linux, but somehow there is a huge drive to overengineering and then building hacks and weird workarounds that become normalized until it's a proper job. Without wanting to start a flame war, but the whole Docker, Containers, Kubernetes, Helm, Orchestrators, etc. story is a lot of reinventing the wheel and a static executable like a Go service in a container, so essentially coming with a whole Linux distribution even though one never thinks about it that way is just really absurd. That's what executables, processes, etc. were invented for.
And since I've lived through the story and as mentioned make a limit, I understand how that came to be, but it feels like the industry took a wrong turn because it was cool and exciting and then (nearly) everyone decided to use that hammer for everything one could imagine to be a nail. And then the next layer came and the next and the next. But all of them doing things differently. And suddenly to have a Postgres cluster you need Kubernetes, and Helm, but also need to know both PG config and the orchestrator's config, etc.
It's a mess and the OpenBSD people somehow knew that decades before I did.
I’ve been using it on an old PC Engines router (great hardware, by the way! I wish they were still around.)
It ran for over 8 years without downtime, but I’ve had repeated problems in the last year or so.
I used the default partitioning scheme, which makes /usr tiny, and /var huge, and since it is a router, did not install X11.
At some point, they made x11 mandatory for auto updates. This is dumb, because all the upgrade tool is doing is untarring a list of tarballs. So, I had to perform partition surgery from the upgrade ramdisk to make room for X11.
Now, they made some ASLR relinking scheme mandatory, which makes sense, except the relink directory is 1.5GB (larger than the entire rest of the distribution, and far larger than the parts I voluntarily installed!).
For some reason the relink output files go in /usr, which, by default, won’t hold it at upgrade. It really belongs in /var, because it is not immutable, and also, there’s room there! So, I had to repartition the router from a rescue environment again.
They also removed the ability for ntp to sync on machines without cmos clocks, and the alternate config options don’t seem to work. That’s a bit more niche, granted, but my router hw is reasonably common for openbsd use and has that property. You can make it work by using a second utility to force clock sync at boot.
I like that they keep things simple, but they also recently pulled out any semblance of power loss safety for their file system. I’ve had to serial console in a few times to run fsck, which isn’t really the behavior I want from the home router!
They don’t have any way to setup DDNS in the base install, so you have to use a port or pkg. The port I chose was EOL’ed by upstream (ISC), so I’ll probably need to switch to dnsmasq as a dhcp server / dns server, which is fine, but those services are a significant fraction of the attack surface of my router. DDNS seems like a pretty simple thing to implement, and would be really high value for router use cases. Without it, I’d have to assign static addresses to everything on the LAN, then edit DNS records.
I think all this stuff is fixable, but wish they’d take the niche of “rock solid secure infrastructure” a bit more seriously. This used to be a nice “set and forget” weekend project but now it requires attention every few release cycles.
7.8 barely managed to fit in my duct tape and bailing wire partition layout. I’m probably going to switch to freebsd on a box with faster NICs when I finally get a > 1GBit internet connection (hopefully in the next year or so).
If I upgrade to 7.9, I’ll have to give up on using the openbsd hypervisor, since, with the partition scheme that the installer chose, there will no longer be a partition large enough to hold the download sets and also the vm image.
This is particularly frustrating because the boot drive is under 50% full. I’d just do “one big partition”, but they warn against that for good reason - it complicates manual fs repair at boot.
Anyway, I really like the project. It would be nice if they did a “fix common papercuts” release, since I doubt many users are as patient as I am.
If you are looking to install it, either use fewer partitions, or way over provision storage (I was 10x over provisioned at install, and the stuff I use hasn’t grown more than 10-20%) and also make sure you choose much larger partition sizes than recommended. This will add under $100 to your hardware cost, even with the storage shortages.
Backup, do a fresh install with new partitions, restore. You have to do this every once in a while especially if your partition sizing is from nearly a decade ago.
My one complaint about OpenBSD would probably be lack of resizable partitions. You can expand them, but only if you have free contiguous space and most of the time one partition starts where the prior one ends. It's rarely a problem in practice, as only /home and /var and maybe /usr/local tend to be subject to any guesswork, but it can bite you from time to time as in your case.
I've already done this twice for this box. Its disk is half empty, and the used space is 75% compounding useless bloat:
- 50% of the used space are package sets I never asked for.
- The stuff I did ask for is somehow 2x larger than it needs to be, since they don't randomize binaries in place.
- If they'd actually follow their own filesystem hierarchy standards, and stop using /usr as a build target (very bad things will happen if a crash happens in the middle of that! Why are we making lots of small separate partitions again?!?) then I could just make /var big. Then I would not have to repartition yet again after they introduce /lib/lolz/3gib or whatever in 2027.
Alternatively, if they had a journalling filesystem or still supported soft updates, then I could have one big partition, which would solve it once and for all.
Anyway, I'd argue "take the lan offline, backup the router, repartition and restore" isn't a planned reasonable maintenance task for a router. The fact that its so obviously easily avoidable is really frustrating.
Alternatively, if they just had a "which sets to install?" config option for auto-update (like they do for the OS installer!) then I wouldn't have to do this.
Yeah it sucks when partitions that were sized 8-10 years ago are no longer adequate. I've hit the "/usr is too small to complete an upgrade" trap myself. When that happened I rejected the installer's partition suggestions and made /usr substantially larger (this is also necessary if you're going to be building large ports, which also happens under /usr).
So far that has worked for me.
Some people would also argue that using an 8 year old device as a critical path in your LAN is a risk in itself. Taking routers down to do upgrades is pretty common in the enterprise IT world.
It’s not just the partition sizing though. The lack of DDNS and clock re-sync are really painful.
Similarly, if fsck -y is frequently required, maybe just run that way all the time instead of failing to boot, or fix the root problem. I doubt many sers are taking block level backups for forensic repair in case they need to hand assemble inodes.
Anyway, I wish them well. I want a simple, correct and rock solid OS for this sort of use case. The three pillars of computer security are confidentiality, integrity and availability. Hopefully they’ll focus a bit more on the latter two things than they have recently.
I needed to create a backdoor network-level KVM contraption to help my dad relocate some servers. tl;dr an office was closing down, he pulled the rack and stood it up in his basement. I mailed him a unifi edgerouter 4 that was reflashed to run openbsd. On boot it would create a vpn tunnel to a vps and basically expose a public WAN port to the rack. So it was in my dads garage on his Fios internet, but from a networking perspective it thought that it was in a Linode datacenter.
The ER4 has 3 ports: 1 was for the uplink, one exposed the WAN connection to the rack, and then the 3rd port became a client inside of the network. I could shell into it from home (he's on the other side of the country) and operate from the residential network and also the server network simultaneously. Worked well enough for a few weeks to keep access around until we could engineer a better solution.
Configuring OpenBSD was really quite simple and rewarding. No insane linux network stack / netplan / cloud-init / bs ... just a few conf files.
"Introduced a mechanism to manage CPU cores with different speeds in the scheduler. The sysctl(8) variable "hw.blockcpu" takes a sequence of 4 letters: S (for SMT), P (regular performance CPU), E (efficient CPU, generally 80% to 50% as fast), and L (lethargic CPU) which are even slower. Set this to select CPUs to kick out of the scheduler (SL by default). Currently works on amd64 and arm64."
I have to admit I am not entirely convinced about the merit of having slow cores on the cpu at all(big/little architecture). You don't want your tasks to be scheduled on them. And even for background tasks shouldn't it be better to have them complete faster for less power? To say nothing about what if they have different features. what happens when a process that wants to use cpu feature X(avx512?) gets scheduled on a cpu without X?
Openbsd took the quick and dirty shotgun approach here in disabling the slow cores. But is there even a good heuristic for scheduling jobs on them? The only thing I can think of is some sort complicated mechanism of putting manual tags in the executable or thread. A "this process is suitable for slow cores" sort of thing.
I was reading about this on on the lists, apparently a naive scheduler puts a process wherever and some new big/little systems have very slow little cores. This really hit recompiling code hard.
> And even for background tasks shouldn't it be better to have them complete faster for less power
Race to idle is only clearly beneficial for tasks that have a clear start and end. If a background task is sustained, responds to unpredictable events, or does small amounts of work and wakes frequently, the CPU's boost logic won't solve your energy usage problem.
> To say nothing about what if they have different features. what happens when a process that wants to use cpu feature X(avx512?) gets scheduled on a cpu without X
This idea has been proposed in the past, but isn't actually used on x86-64 or ARM. E-cores have the same instruction set as P-cores, so there's no risk of running into an invalid CPU instruction.
Truly heterogeneous instruction sets may come back in the future, though. So be on your toes.
It's a lock/mutex implementation that puts the blocked thread to sleep, usually via cooperative yielding to the scheduler instead of continuing to perform CAS operations on the lock continuously. Spinlocks have great performance when they're not heavily contended and the locks are held for short periods of time, but if either of those things are true the blocked thread can easily consume an entire CPU core while it's blocked.
I would really love to adopt OpenBSD but the one thing I can't deal with is the absence of journalized filesystem.
Just the idea not to be able to recover after a power cut and work is hard to accept to be honest.
I have been recently considering running it on a minimal Alpine ZFS host but I am not sure how much I can optimize the display experience since I do not think OpenBSD support QXL/SPICE.
Once you have workloads that can't tolerate a power cut + running fsck for a potentially long time, a battery backup becomes an excellent investment. I bought a UPS on eBay for cheap and my home server hasn't gone down since.
fsck is good. I have to hard reset my laptop a few times and I didn’t have corruption. Maybe a server has a different risk profile, but journalized systems are not file backup, which is what you should focus on.
Ah, losing the 2.4ghz USB dongle ... Sucks. Feel you. :-(
Wireless Earbuds/Headphones are a legit use case.
(Still use bluetooth with iPhone every day, sadly, still addicted to the convenience of AirPods ...)
But I've got decent wired headphones for my OpenBSD setup. bonus: never have to charge them. ;-)
Even more curious now: what do you use the Nintendo Switch controller for on your computer? Have you got it hooked up to play games on your PC?
Or do you use it for robotics or other I/O?
Switch controller gets used for flight simming, just as a simple analog input that I can take to the couch (or bed). I've also got a wired pair of my wireless Audio Technica headphones, but I'm not confident that my DAC (or Bitwig for that matter) would work as well on OpenBSD as it does on Linux.
For desktop use, I don't think I'll ever end up on OpenBSD. It might power my gateway router one day, but the cost/benefit analysis falls through on hardware like a laptop or gaming PC.
Firmware backdoors in wireless chipsets are a really big attack surface, and disabling wireless at least gives you the chance to monitor five eyes activity on ethernet.
That's too bad. I might need bluetooth on keyboard, mice, headphone/earbuds, etc. OpenBSD seems so nice, but right now it is limited to running as a server, and not a desktop, which could be considered a good thing, as it focuses on simplicity. However, I do wish it had more hardware support.
EDIT: Running openBSD in a VM might get me the best of both world, with hardware support on host OS (linux/win) and the benefit of running OpenBSD.
It wasn't security really, it was just the entire stack being so complex and poorly maintained that it became insecure. If someone wants to go back and do things right, they're free to do so
Congratulations for another amazing release! This one even comes with a song :)
I'm using it as a daily driver since Debian adopted systemd and it works great. I use it wherever possible: home router, laptops, obsda.ms vm, workstation, thin clients, etc.
With every release OpenBSD becomes better. Fully recommended to take advantage of old hardware too, like a fanless thin client bought for cheap from surplus.
I really love the no-nonsense approach I can't find elsewhere.
Sorry for the off-topic, but I wish our FreeBSD camp could roll back a little from this faux-corporate glass ball without soul and a font from the early 90s spaceship toy box, to Beastie and a stylish serif. What I was trying to say - I'm in envy. OpenBSD artwork is absolutely amazing!
Sweet! I’m just about to replace pfsense with openbsd on my router. Smoothly setting up ipv6 is a bit of a headscratcher atm, mainly because i’ve never had to understand it before.
I dual boot OpenBSD on it, and it's been doing fine. The out of the box experience is pretty bare although the default window manager cwm is surprisingly nice once you get to know it. Note that apmd, the power management daemon used to manage CPU speed and low-battery suspend, is not enabled by default. The high-DPI screen required some adjustments in Xresources (I haven't dared try a multi-monitor, mixed DPI setup).
NetBSD seemed okay to but I've only used it a little bit. It actually set up X pretty well for the screen using some built in script with heuristics to determine font size from the screen metrics.
No wifi driver for Framework 16. Was fun installing (and surprisingly quick) and playing around a little. But unfortunately that's a dealbreaker for me.
Let's see, System 76, previously Dell and Samsung.
All the pretty much the smallest and lightest I could find. So not fantastic, but good enough. For me, battery life is much lower on the list than "small and lightweight" and "works well with Linux".
Yes free from American restrictions. Because America law prohibits from giving out cryptography to outside countries so according to OpenBSD we outsiders have no luck in getting a cryptographically secure operating system except for OpenBSD
If I remember, it's still illegal to export to "rogue states," Iran and North Korea being the major two, and terrorist organizations. But I don't think anybody has been charged for it and there's reason to suspect it wouldn't hold up given the pgp ruling.
We can't really export anything to those "rogue states" anyway. Also, as backwards as NK can act in some contexts, I dislike the classification of them as a rogue state. The kims are pretty good at geopolitics and wouldn't do anything stupid or dangerous without a good enough reason to make its actions no longer "rogue". If anything, the US is closer to a rogue state currently with its rubber stamp congress and willingness to do whatever the orangutan in charge says
early 2000s so close enough. I know this because for a while, WEP was intentionally crippled in the US for a while because of the archaic encryption laws
Sidenote, does anyone remember a "click here to become an international arms dealer" esque site as a protest of our encryption laws or did I make that up. I swear I heard that somewhere
OpenBSD does a lot of things well, definitely punches above their weight. One underrated feature is their approach to releasing. No "When it's done" here. Like clockwork twice a year, they slow down, clean the shop, get their experiments in order and cook a release, a stable point in time. More projects could learn a thing or two from this.
BSDs are interesting projects. As I understand it there's a broad difference of them all doing things reasonably well but a) Free is general-purpose, b) Net is especially portable/many architecture and Open is security focused
9fronts site will always be one of my favorite place on the net. I don't like plan9 (architecturally it is amazing, I just am to bigoted to stay sane on its userland) but the humor is so my style of humor
FreeBSD is mainly server focused. There's been work on the desktop recently, but it isn't what FreeBSD devs are paid to focus on. To be fair to the people paying them, it's a damn good server OS.
Also, check out DragonflyBSD. It has a really nice filesystem and Dillon does good work
FreeBSD is focused on making a good, general purpose operating system. It just happens to be very good at being a server. It's also very good at being a desktop.
I have used OpenBSD as a desktop for 7 years. Though my usage and the machine were minimal. But I thoroughly liked it. I want to go back to it. One good thing is that if your hardware has some problems or about to have problems then installing OpenBSD will make your computer kernel panic. So I use it as a diagnosing tool for my hardware
I always wanted to get into bsd, especially openbsd. I like the idea of a more cohesive os.
But I don't really know what to use it for to get started. My desktop runs linux with steam for games. My AI server needs rocm drivers so ubuntu-server. My vps runs debian, maybe that one, but there is no DO image for BSD. Open for ideas..
OpenBSD for the layer where you need the highest security. We use it for hosting our Postgres clusters. You could easily use it for your VPS. There is a learning curve. But if you’re already comfortable with Linux you’ll pick it up in a few hours.
I am a diehard FreeBSD fan and I used it on my laptop for 20+ years, and dualbooted it for windows only for gaming.
I tried my best to get gaming going, even running Arch in a jail, but it's not great for gaming purposes. I was even virtualizing OpenBSD to use PCI passthrough for better wifi...
Today I am using Arch Linux instead of my dual boot setup. Is it perfect? Nope, but at least I can play Age of Empires 2.
I still use FreeBSD on my servers, obviously.
FreeBSD is great, but on the desktop, and especially on the laptop, there are some warts.
Cannot edit, again the easiest upgrade of an OS, I did kitchen chores during the upgrade. The network was a bit slow, but got my work done during the upgrade :)
OpenBSD 7.9 release artwork by Lyra Henderson
https://www.openbsd.org/images/PinkPuffy.png
https://www.openbsd.org/images/puffy79.gif
Release song is "Diamond in the Rough" - Composed & produced by Bob Kitella.
https://www.openbsd.org/lyrics.html#79
Apparel (t-shirts, so far): https://openbsdstore.com/
Interesting to see OpenBSD continuing to gain hardware support. I've been running it on a small home server for DNS/DHCP and the stability is remarkable. The man years of auditing really show.
Pretty much any OS would be just as stable if it's just serving DNS/DHCP.
As someone who has run DNS and DHCP servers... unfortunately, no.
Shit happens, and choices still do matter. Even if it feels it should be simple, Linux has a way.
My experience has been that Openbsd is rock solid, so are its implementations of the relevant server daemons.
> Even if it feels it should be simple, Linux has a way.
As someone who has run DNS and DHCP servers for over 30 years and continues to do so, this just feels like confirmation bias based on your personal anecdotes. If there's an issue, it's likely due to messy over-complicated distros. Alpine is no less solid than OpenBSD.
Nah, whenever I'm involved in a cloud cost audit, I routinely find boring unfashionable Ubuntu and RHEL servers someone forgot about with 5 year uptimes.
Going off of "data" from r/uptimeporn I can only conclude that Cisco makes the most stable software of all time.
"Interesting"
Is this an AI-generated comment
It was originally [flagged] and [dead]
It's a new account, and by default new accounts have their posts flagged/dead I think?
FWIW my guess is you're right - this user looks like a bot based on this comment and their other one; I've noticed that somewhat-vacuous praise for a post is a bot tendency. Although it's also a human tendency, so maybe too soon to tell. What a world.
> https://www.openbsd.org/images/PinkPuffy.png
> Apparel (t-shirts, so far): https://openbsdstore.com/
Interesting.
In the image you linked (PinkPuffy.png), the cat's hat says "security." In the OpenBSD store, the cat's hat reads "POLICE" on several of the shirts.
The artwork on the store may have been an earlier (non-final) version, or there's just simply multiple variations, which is usually the case for the t-shirt art.
Job Snijders works closely with the artists each release, and runs the store.
The images for the last two shirts appear to have gibberish on the hat indicating AI was somehow involved. https://openbsd.creator-spring.com/listing/openbsd-7-9?produ...
Edit: oops, bad eyesight led my brain to believe "no way this is legible text" when in fact it is. Needed a screen magnifier to read it clearly. Though the other items have police in place of security.
I don't see any "gibberish".
My bad. I have poor eye sight and on my first look the fonts appeared jumbled. On second look with a screen magnifier I can see it reads security while the others read police.
Will be interesting to see if Theo leans into AI ... and starts having AI generate the release artwork & songs.
With all the security issues constantly being uncovered in other Operating Systems - which will only accelerate with Ai - it’s time everyone considers OpenBSD. Their decades-long security-focus is second to none. We have fully converted from Ubuntu/Debian to OpenBSD. No looking back.
I tried OpenBSD recently and found it behaves very differently from other OS. The same code works on Linux/FreeBSD/Windows but has poor multi thread performance on OpenBSD, async socket stopped working after sending at high speed for few seconds. I am not saying there is anything wrong in OpenBSD, it is just different.
OpenBSD uses a Giant Lock model (simpler code) instead of the fine grained locking mechanism in Linux. And Linux has a some quirks and hacks to improve performance (instead of doing the slow, but correct thing). One example is the USB Gadget thing.
This is not wrong per se, but they also try to reduce/remove this giant lock as much as possible. If you see entries like "Unlocked socket splicing." in the changelog, then this is one more case where the giant lock is not needed and in which therefore all cores can be used.
It just takes time.
Is the code you ran on your OpenBSD available (e.g. on GitHub) for others to test? Curious what async issue you faced, did you report it? Or ask for help addressing?
I just switched to single thread and didn't try to fix the issue. Single thread is fast enough to me, it has throughput ~ 730 Mbits/s in a OpenBSD 7.8 vm on a 7th gen i7 linux kvm host.
https://github.com/infinet/rs-wgobfs/commit/c5e62796
If you care about security, why not consider Qubes OS? Related discussion: https://forum.qubes-os.org/t/qubesos-vs-openbsd-security/790...
If you really really care about security, then consider CHERI and CheriBSD
https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
Capability approach is just not practical and relies too much on security through correctness, which is unrealistic.
I was looking at that thread and honest question: how does Qubes OS deal with the binary blob issue? I would guess it is deblobbed to a certain extend according to [0]
But I couldn't find if they have a strict "no binary blob allowed" policy like OpenBSD.
- [0] https://doc.qubes-os.org/en/r4.3/user/troubleshooting/pci-tr...
They do not have a strict "no binary blob allowed" policy. Concerning VMs, they have a policy of minimal modifications: https://doc.qubes-os.org/en/latest/introduction/faq.html#wha...
The dom0 is based on Fedora and has the Fedora's policy for firmware blobs. See also: https://doc.qubes-os.org/en/latest/introduction/faq.html#wil...
Qubes OS uses the Linux kernel. Without wanting to start a flame-war and with all respect to Linux, it’s not even close. See: https://en.wikipedia.org/wiki/OpenBSD_security_features
The “kernel” in Qubes is arguably Xen rather than Linux, and that’s where the security boundaries are supposed to be defined rather than within VMs that may be running any OS. VM compartmentalization as a security mechanism is hard to compare to a more conventional Unix like OpenBSD.
It's not just Xen, it also relies on the hardware-assisted virtualization (VT-d), which is virtually unbreakable compared to anything else. Most Xen vulnerabilities do not even affect Qubes: https://www.qubes-os.org/security/xsa/#statistics
You misunderstand the Qubes' approach to security. You isolate your workflows into separate VMs, so that security of a single VM doesn't matter. For example, my secrets are stored in a dedicated offline VM. All kernel bugs in it are just not exploitable. I open my online banking in a dedicated VM, in which nothing else is ever opened. Which attack vector do you think can be used against that?
https://isopenbsdsecu.re/
(This site is extremely good and has fairly recent coverage, point-by-point, of all OpenBSD's mitigations. An important subtext to take to this is that OpenBSD has a reputation for introducing mitigations that exploit developers make fun of. Some of them are great, some of them less so.)
The slides are over 6 years old. The developers' attitudes haven't changed much, but are all of the arguments still valid?
I've followed this discussion here and there over the years and it always goes like this:
1) everyone makes fun of the mitigations
2) many even outright assert they can easily defeat and exploit OpenBSD
3) nobody provides a working PoC when asked to demonstrate how insecure the OS is
And somewhere in the mix there's also you and your usual blabber, also without any substantial examples of how insecure and exploitable the OS is. Always.
The site isn't the slide deck. Let's talk after you've read it?
I have now read all of the points in the mitigations section. Just like the slides, the commentaries to the mitigations willingly assert uselessness and imply a sense of absolute insecurity, but without specific or even general examples.
So I'm looking forward to your careful explanation of how insecure the whole thing is and how easily it can be dismantled. Because I really want and need to know. Let's talk.
Wait, what? No they don't. The author is an OpenBSD person and calls out several mitigations as clever and worthwhile.
No, the author isn't an "OpenBSD person".
Isn't this Joshua Stein? (I feel like I've gotten this wrong before.)
No, AFAIK the author is German and his nickname is stein (stone).
It's not, and you have.
Rats! Some day I'll remember this. (I am a fan both of JCS and of the author of this page).
Unfortunately the hardware support isn't there for many systems.
If I had to pick a BSD, it would be FreeBSD anyway.
Hey pjmlp (waves),
I know you've been an advocate for OSes and languages that are outside of the mainstream.
I finally got around to living in plan9...
My experiment, a social network for plan9 written in rc and some awk.
https://github.com/dharmatech/9social
Cool! Trying out new ideas is very good way to open mindsets, even if those systems aren't used regularly, they serve as inspiration for future improvements.
The video is kind of interesting.
Thanks for checking it out, pjmlp!
Ugh FreeBSD is so much nicer than modern Linux. It's hard not to love.
It has some pluses, I miss an updated version of "The Design and Implementation of the FreeBSD Operating System", but it is understable there are other priorities and putting such a book out is lots of work for very little money, given how much book authoring gives back.
Is OpenBSD actually more secure than Linux? I have not been able to find any data to support this—only some vague opinions.
The Data:
Compare the number of CVE vulnerability trends over time between Linux: https://www.cvedetails.com/vendor/33 and OpenBSD: https://www.cvedetails.com/vendor/97
It's not even close! It's nearly two orders of magnitude higher for Linux. This isn't anecdotal or “vague opinion” CVEs are facts.
You can ask the follow-up question: Why is that?
And there are many reasons. It could just be that Linux having more users/eyes means more bugs are surfaced ... But you need to dig deeper to understand why OpenBSD is so much more secure, the core team of OpenBSD proactively reviews the security of other OSes and when they learn something, they rapidly implement the feature/fix in OpenBSD.
Again, read: https://en.wikipedia.org/wiki/OpenBSD_security_features Many of the proactive security features OpenBSD has are not implemented by other OSes. And in the case of kernel-level Crypto, they won't ever be because US export restrictions.
> And there are many reasons. It could just be that Linux having more users/eyes means more bugs are surfaced
You really brushed that one off, uh? The ratio of linux devices to openbsd is quite literally a million to one. The ratio of tech companies invested in linux to companies invested in openbsd is roughly 50,000 to 1. The ratio of professional security researchers paid to find flaws in Linux vs OpenBSD is harder to quantify at the moment, but I think we can guess a trend here.
I can agree to a degree that OpenBSD takes security more seriously, and they have made very interesting design decisions to enforce their security model. But I entirely disagree that the number of "CVEs are facts" to back your opinion that it is superior.
> This isn't anecdotal or “vague opinion” CVEs are facts
No they aren't, they're data. Your source shows the amount of Linux CVEs in 2024 are an order of magnitude higher than the amount of Linux CVEs in 2023. Does that mean Linux became way more insecure in 2024? You imply it does, but that's obviously not true. What happened is that Linux changed how they report CVEs [0].
Just like your source doesn't say anything useful about the difference in CVEs in Linux, it doesn't say anything about the difference in CVEs between Linux and OpenBSD.
Lies, damn lies and statistics.
[0] https://www.suse.com/c/linux-kernel-cve-increase-suse-explai...
This announcement thread really isn’t the place to discuss or debate the data.
The OP stated they couldn’t find any data to compare the relative security of Linux vs. OpenBSD.
CVEs are independently, objectively verifiable and provable data. This is the dictionary definition of a verified “fact”. It’s not anyone’s opinion. You don’t have to like it or me.
Love you all.
Going by CVEs, Haiku is more secure than OpenBSD. Linux has had strong kernel-level crypto enabled by default on major distributions for years, see AF_ALG or LUKS.
On the wiki page you provided, the only thing that really stands out at the kernel level is KARL, which has a dubious utility: https://isopenbsdsecu.re/mitigations/karl/ It is not even up to date: strlcpy(3) and strlcat(3) were implemented in glibc 3 years ago.
AF_ALG does ring a bell.
US export restrictions? There are broad license exceptions since decades, so kernels like Linux are free distributable. Same would apply to OpenBSD.
which is canadian anyway
"Is Secure" is subjective.
I would be in favour to say that out of the box OpenBSD is more secure than Linux.
> I would be in favour to say that out of the box OpenBSD is more secure than Linux.
Also important to remember that diversity builds strength. Just as in biology, if all organisms are the same, they all succumb to the same virus.
I have a multi-layered firewall approach where some are Linux, some are OpenBSD, some are commercial. They'll all have bugs, but unlikely they all have the same bug.
You are correct; OpenBSD is secure by default. And it's not subjective at all.
The homepage of https://www.openbsd.org proudly states "Only two remote holes in the default install, in a heck of a long time!" if they didn't have the evidence to support the statement, the internet would have forced them to remove it by now. ;-)
Remote (exploitable) holes are the ones we all care about.
The key (and not saying it's bad, mind you) is that the default install has very few services installed, let alone running or open.
So even if Debian and OpenBSD ship the exact same web server, but Debian has it defaulted installed and on, but OpenBSD does not, then a remote exploit won't count against OpenBSD.
All OpenBSD services, including HTTP (httpd), SMTP (smtpd), and DNS (nsd, unbound, unwind), use privilege separation and sandbox themselves with pledge and either unveil or chroot. There's no extra configuration. And the developers dog-food these services; it's why they're in the base system.
How many Linux services use seccomp? Or chroot, mount namespaces, or landlock? If they do at all, it's usually imposed externally by systemd or docker, in which case they usually run with overly broad permissions because there's no integration with the specific application code, thus the AF_ALG exploits in containers. On OpenBSD services continue to narrow their privileges after starting up so by the time an external request is serviced they have only minimal access to syscalls and the filesystem, often only read/write/send/recv syscalls, and if open is allowed only the specific files and directories needed to service requests. Typically even the network-facing daemon accepting TLS connections doesn't have access to the private key--you simply can't do that by running a vanilla service application in docker.
Does OpenBSD have bugs? Of course. The question is, which environment has more trustworthy backstops? The Linux kernel provides all the facilities, but they're not used effectively, for many reasons.
Isn't that a good thing for certain use cases ? If you are building an appliance type thing (say a storage or networking device) then you would want something minimalist you can add only the necessary services on. And arent those the types of devices the BSD (in general) are used for ?
Less attack surface always equals less potential for bugs/flaws/exploits regardless of how good red teaming tools and workflows get.
Now obviously for other use cases Linux could be a much better option.
There was a time when Linux distributions shipped lots of things on by default; OpenBSD bucked the trend and did not. This is less of an issue nowadays.
People would never lie on the internet.
Given from what Anthropic says with Mythos: Yes.
I pointed plain old gpt 5.5 at openbsd and found plenty of bugs.
Sent patches for two just in "find".
Openbsd, like all other projects, needs a large scale LLM powered bug squash effort.
My recent experience: https://blog.habets.se/2026/05/Everything-in-C-is-undefined-...
> This was the most critical vulnerability we discovered in OpenBSD with Mythos Preview after a thousand runs through our scaffold. Across a thousand runs through our scaffold, the total cost was under $20,000 and found several dozen more findings.
Anthropic did that for OpenBSD.
https://red.anthropic.com/2026/mythos-preview/
I know.
I'm saying you don't even need Mythos to find bugs in OpenBSD. GPT 5.5 is SO much better than humans at finding these things.
The fact that we don't even need Mythos, or $20k (I just pay $24/month and this was one of my MANY uses), to find bugs in OpenBSD shatters the dream that there exists any human who can write C properly with enough expertise, dedication, and time.
> (I just pay $24/month and this was one of my MANY uses), to find bugs in OpenBSD
Bugs, or exploitable security vulnerabilities?
If the latter, have you reported them all?
As I mentioned in the post, I only did a brief exploration of OpenBSD in order to cheer myself up. I took some findings, confirmed them being true bugs, and ended there.
As I said in the out of bounds null termination write patch, I don't believe it's exploitable. I would have gotten a CVE, website, and logo then (kidding!). But it was UB. And one-byte overflows have in the past been exploitable by better sploit authors than me.
In any case, I reported that since I felt it was clear that OpenBSD folks would obviously care about it, exploitable or not.
Confirming these findings take time, even though I found GPT to almost always be correct. I will NOT report upstream until I understand the bug. I ain't no slop reporter. As I said in the post OpenBSD (and all other code bases) need a larger effort. The Mythos/Glasswing effort focusing on actually exploitable ones may be a good method for getting them fixed, without overwhelming projects with patches, even when the patches are correct.
I did confirm at least one more UB, and did consider whether to report that OpenBSD `find` reads `status` via `WIFEXITED(status)` without checking `waitpid()` for errors. This is UB since `status` is uninitialized. (https://github.com/openbsd/src/blob/ae684bfaed6cae797cd90e27...)
The reason is my previous experience with OpenBSD where the reply may be "<some standard> is wrong in this regard", and because they control their whole system, they don't care. E.g. in this case they may go "we build with GCC x.y.z exactly, and we know what actually happens in this controlled domain". This may be a bit unfair to them, but not by much.
GPT also flagged the extremely surprising behavior of running `cat -n file1 file2` if file1 doesn't end with a newline. And that `find /etc/passwd -execdir[…]` doesn't run the command. But maybe that's how they want it? I don't want to go through the whole thing for them to go "yeah we won't do that" again. So I think this project is for them. GPT is as available to them as it is to me.
Tangent: in running GPT against `cat` I learned that not only is `cat -n` not standardized, but it also behaves COMPLETELY differently than on Linux, if you provide more than one file.
It's not meaningfully more secure than e.g. Debian.
Their claim to fame ("only two remote holes in the default install in X number of years") is definitionally only valid for the default install in its default configuration which means: no httpd, no smtpd, no unbound, etc. etc. etc.
The default install isn't very useful, because it doesn't do a lot, and so "only two remote holes" or whatever isn't really saying much.
For example: there are still CVEs popping up: https://nvd.nist.gov/vuln/detail/CVE-2024-11148
Linux has more CVEs because it's orders of magnitude more popular. OpenBSD has appalling performance, and more or less nobody uses it, so there just isn't a large focus on auditing and fixing it.
It's a great research project, but I would not run it on my personal devices. Not because it's "insecure" but because the putative security benefits do not merit the shockingly poor performance.
> The default install isn't very useful, because it doesn't do a lot, and so "only two remote holes" or whatever isn't really saying much.
Thats not really true. Comes with spamd, pf, httpd, OpenSMTPD and others. Its actually one of the open source unix-like systems that packs more functionality out of the box.
Great firewall and VPN server. You can setup wireguard with just ifconfig.
Again: It comes with them on disk, but are they enabled by default? If not, then they are not covered by their "default install" boast.
I get your point, but GP is right: You said "Default install", not enabled by default.
The default install is actually very useful, and includes a lot, like parent said. Having run OpenBSD in the past, I found the their versions of things were often superior, at least for small setups (and some of them for large installs as well.. probably : )
I use it on my ~10 year old desktop as my everyday OS. Performance may be measurably worse on benchmarks, but I never notice it doing regular stuff as a user. It's fine.
Don't most people use something FreeBSD based for production use ? I was under the impression OpenBSD was more used for testing and security research.
For personal devices I'm not sure why anyone would run a BSD in the first place
Easy to install and upgrade, sane defaults, good documentation, lack of waffleburgers of complexity, so I'm not sure why anyone wouldn't run OpenBSD in the first place. Granted I put Windows in the unusable bin and it's been there for decades now and sounds like it is getting worse, what passes for Mac OS X these days is not so good given that you have to disable some security thing to properly kill the annoying and disruptive notification system, among other annoyances still being fueded with, and I gave up on Linux after trying to support that waffleburger in production for a year or two.
OpenBSD is absolutely a research OS and that's okay.
My understanding is that Netflix used to use FreeBSD to serve video, but I read somewhere they're no longer using it. Not sure how true that is.
Some game consoles like the Playstation run a modified FreeBSD as their OS.
No. (It's fine!)
macOS is BSD roots on top of Darwin
While true it doesn't answer why OpenBSD is considered more secure by default than Linux. Despite its BSD roots, macOS has had its share of CVEs:
https://www.cvedetails.com/version-list/49/70318/1/Apple-Mac...
That's not specifically OpenBSD, though. The BSD world is not the monolith that it was back in the 1980s.
True. No relevance to macOS and iOS.
With due mention to FreeBSD's jails, BSD's security image developed mostly from OpenBSD which is said to have gained its security focus due to NetBSD being so insecure that the NetBSD folks were able to hack into DeRaadt's forked OpenBSD.
Android's Bionic was based on or heavily influenced by OpenBSD's libc iirc, though.
No, not really. Linux has better options available and is significantly stronger when configured correctly. The OpenBSD approach ls largely based around eliminating bugs in the first place, but isn't as strong at limiting an attacker that successfully exploited a bug they missed or weren't responsible for.
> when configured correctly.
These are the operative words. With OpenBSD, you get this out of the box and everything just works. With other operating systems, you have to do a lot of the legwork that's already been done for you with OpenBSD and make sure you didn't break things with your configuration.
> These are the operative words.
These are words that when applied equally to Linux and OpenBSD, has Linux coming out ahead.
> With OpenBSD, you get this out of the box and everything just works.
With OpenBSD, out of the box you get a blank slate that really can't do anything, that you have to configure to do what you want, and currently can't be configured to be as secure as linux can be.
Sorry but that's simply not true. There are various cases where vulnerabilities didn't affect OpenBSD due to defense in-depth in OpenBSD.
OpenBSD has a pretty long history of eg. limiting attacks through compile time mitigations while making them more usable for every day use compared to specialized "high security" Linux distributions. This can also be seen in patches of third party software (in the ports (packages) system) that often have patches so the code can live with these limitations.
One example of such a mitigation is W^X. Implemented in OpenBSD in 2003, copied later by Windows, Linux and the other BSDs (incl. macOS).
https://en.wikipedia.org/wiki/W%5EX
More recently of course pledge and unveil were also added.
Also in 2003 OpenBSD was also the first mainstream (no research or test OS) that implemented strong ASLR that in 2005 was supported in Linux through third party patch sets.
For a list, see here:
https://www.openbsd.org/innovations.html
Many things were later picked up by Linux distributions, kernel patchsets, compilers, etc.
It really is true. OpenBSD focuses on auditing. In many cases they were not affected because of mitigations, but because they were just using a different stack. OpenBSD wasn't affected by regreSSHion for example, for basically the same reason Alpine wasn't.
OpenBSD didn't invent the concept behind W^X, and if you want to talk of 'copying', which I think is kind of silly personally, then PAX was first.
I'm familiar with the list of OpenBSD innovations, and in turn I would point you to https://https://isopenbsdsecu.re/ for a breakdown of their claims and marketing.
To this date OpenBSD doesn't have anything as simple as a proper ACL, let alone any type of MAC. They claim such systems are too complex, which is of course nonsense.
It's like I said - they focus a lot on preventing an attacker gaining access, but have little available to constrain attackers who DO get access.
> OpenBSD focuses on auditing.
This is partially true; there are numerous other things that are done for mitigation outside of this.
> there are numerous other things that are done for mitigation outside of this.
Sure, and I think they are mostly great, main problem being they just don't go far enough. Where's the namespace level isolation, ACL or MAC support? Is there a way to give a user append only ability for one file, while having write but not delete access to another, and delete to yet another? What's the maximum extent to which OpenBSD could have limited an attacker, had they been vulnerable to regreSSHion?
Namespaces are a joke under Linux compared ot 9front. The last exploits under bubblewrap ran the same. OpenBSD has OpenSSH pledge'd and unveil'ed.
Don't make the perfect be the enemy of the good. Just because they didn't stop escape via dirtyfrag doesn't make them useless let alone a joke. pledge and unveil are nice, but exactly how effective do you expect them to be against an ssh/sftp server? Maybe you have ssh configured so it can't manipulate user and/or system files, but that isn't typically common usage.
Openbsd makes a good stopgap.
The way forward is seL4[0][1].
0. https://sel4.systems/
1. https://microkerneldude.org/category/sel4/
Neat stuff, but this is not going to easily run the vast majority of open source software out there.
Not today, but it could tomorrow.
e.g. Genode's Sculpt[0] already bridges the gap via running Linux in a VM.
Even though they already have native webbrowser and can build software natively, it wasn't always the case.
0. https://genode.org/download/sculpt
What? How long did it take?
How long did what take? Learning the essentials of OpenBSD, budget 4-6hours. Switching over servers from Ubuntu, an hour for the first one then 10mins each after that. You can copy config with your favourite tools; most have ports for OpenBSD already. If you want to learn more in-depth, read: Michael W. Lucas Absolute OpenBSD, 2nd Edition: Unix for the Practical Paranoid. Highly recommend it as teaches many fundamentals most software engineers skip.
How many upgrades have you done so far? And how many kernel fixes?
Long time ago I maintained a couple of obsd servers, and the cost in time of upgrades and the (occasional) security fixes was substantial.
I still maintain a couple of servers, but if it wasn't because Debian makes it easier by automating most of it, I don't think I could do it.
Yet I miss my time with obsd. I'm very interested in your experience.
Edit: it was 3.6-STABLE. Things have changed since then.
They have binary updates by now. No more need to download the source from CVS and compile fixes.
You can update from one OS version to the next with manly only one command.
syspatch and sysupgrade have made things substantially easier these days.
>it’s time everyone considers OpenBSD
https://x.com/ortegaalfredo/status/2055362910415671459
When your super secure feature gets defeated by a symlink maybe it's not really time to consider it...
Sure, things are not better in the linux world but at least there's more eyes to fix issues there just because of the market share.
Note that this specific symlink was special cased because sandboxed programs still need to access timezones. Also note that you would need to be root to create that special cased symlink. It's embarrassing, but less catastrophic than it looks at first glance.
Running security-critical code as root is still a bad idea.
Your "evidence" for him to reconsider is a sandbox "bypass" that requires you to be root to set up the environment?
For my next trick I will demonstrate how to break into my own house to open the blinds by using my keys.
Security researcher theatrics will never not be funny.
Maybe I'm misunderstanding the video, but it looks to me as if the situation is:
You are root inside a sandbox. As root-in-the-sandbox, you create a symlink and this gives you the ability to escape the sandbox.
(Whether this is interesting or not depends on whether anyone actually tries to use the sandbox facility in such a way as to give root-in-the-sandbox privileges to untrusted people or code. I don't know enough about OpenBSD to answer that.)
OpenBSD doesn't do different user accounts inside vs outside sandboxes; if you're root in the sandbox, you're root on the system.
Also I tried the Dirtyfrag exploit under Bubblewrap for GNU/Linux. It lasted, but finally I got root with a simple 'su'.
unveil was designed and intended to effectively sandbox root when combined with sufficiently strict pledge permissions. I don't think this exploit would have effected any existing OpenBSD services, but sometimes services need to keep around processes with higher privileges than the network-facing process, yet you still want to sandbox them as much as possible. For example, sshd uses a special auth process, and that process needs higher privileges to be able to access the password database. On OpenBSD this auth process doesn't need root, but there may be similar cases where you want to use unveil with a root process for defense-in-depth. Suffice it to say, it would be foolish to only use unveil with such processes.
The bug here actually involved the intersection of unveil and pledge. IIUC, it was more a pledge bug that accidentally allowed bypassing unveil checks.
So what? You're still root. You're relying on a sandbox to plug a few voids while you still effectively held keys to the kingdom before said voids were plugged.
I hear this excuse daily from developers who insist on running all their docker containers as root "because we have to".
If you're relying on a sandbox as your first line of defense you've already lost the war.
I think the idea is to not run programs as root in the sandbox.
The parents tone wasn't warranted, but bugs like this could be more serious if combined with privilege escalation bugs in the sandbox.
Ideally, sandboxes should be like Vegas - what happens in the sandbox stays in the sandbox.
(I'm just speaking hypothetically here, I'm not knowledgeable about OpenBSD or it's sandboxes)
>Your "evidence" for him to reconsider is a sandbox "bypass" that requires you to be root to set up the environment
Can you help figure out where does it say unveil does not really work when root is involved?
You left a snarky comment, then paraded around a positively lame example as some sort of trophy.
Here's what I can figure out: you need root to set up the environment just so. It's a don't-care. The end.
So, a break out of chroot in a chroot jailed app would be a non-issue because I need root to set it up?
If you need root to set up the escape, then yes that is relatively uninteresting. Like, we know chroot can't contain root.
Thanks. It was not evident from the example whether root inside of the sandbox is necessary - I assumed creating arbitrary symlinks doesn't require any particular capabilities, and there's nothing special about the locations.
Though it's not clear to me now:
- why was this patched then?
- is the point about root that non-root wouldn't have access to passwd anyway?
OpenBSD doesn't have separate user accounts for sandboxes. These sandboxes are not linux-style containers, they're narrowed views of the full install.
If you're root inside the sandbox, you're root outside it. This exploit requires you to already be root.
But the issue of root and accessing outside of the sandbox is orthogonal, no? Even if you're logged in as XYZ, accessing XYZ's contents outside of the sandbox is still a breach and a problem. Or does this issue require actual root to manifest?
This path was special cased used to allow restricted applications to access time zone files, which are needed for time functions. Not any symlink will do, it has to be the specific one shown in the example exploit, or one of a small handful of others that were special cased for similar reasons. The place these symlinks live are owned by root. This is the same root user outside the sandbox as inside it.
So, yes, you need to have root on the box to set up this exploit.
I see, thank you for your time and patience spent to explain this. So there's no elevation, no general escape, and this got patched because it could possibly be used as a set-up-use-later backdoor style thing (such as dropping a setuid root binary somewhere in the OS). Yeah, not a thing I would use as an argument that it's a terribly insecure system.
>Here's what I can figure out: you need root to set up the environment just so.
I guess you just don't understand what unveil does.
Your arrogance is continued proof you could never comprehend the work that goes into building, releasing, and maintaining an entire OS, and your contributions will forever be limited to snarky negativity on message boards.
Anything on unveil and not about me?
If you think their code sucks to the point people should think twice about using it, I suggest you stop using OpenSSH immediately.
Please be sure to let us know when your better, more secure replacement is ready.
The big news for some of us is that Exim has been dropped from ports. Here is a good article about transitioning from Exim to OpenSMTPD:
https://nxdomain.no/~peter/time_for_opensmtpd.html
I tried using OpenSMTPD a long time ago, shortly after it came out, but things were not stable enough. I guess it is time to give it another go...
OpenSMTPD was substantially rewritten in 6.4 (2018). It is the best SMTP server for the majority of use cases. Unfortunately, the portable version has been weakly supported, so it's usually only OpenBSD users than learn how great it is.
I'm happy with it. Been running OpenSMTPd for many years at this point, on both OpenBSD and Linux, and I have no complaints.
I've also started using OpenSMTPD on linux machines when I need a simple MTA (which is to say, in almost all cases).
I really like OpenSMTPD; no nonsense and configuration feels rather modern compared to the legacy stuff that's out there.
Surprised exim was dropped from ports. It is not like it was ever in base. I guess the maintainer did not want to anymore.
We don't have to guess. There are several mailing list discussions:
https://marc.info/?l=openbsd-ports&m=177625153728067
I used it a bit, had it installed for a while on a G4 PowerBook (must have been early-ish 2000s). I like the no-nonsense attitude towards blobs, security focus. Overall the experience was very good. The bit of code I read was also written nicely. I'll always endorse it and should really install it somewhere again in the near future.
This is also the 60th release. Congrats team.
Anyone here using OpenBSD? If so, for what purpose?
I’ve always wanted to use NetBSD for an application for an embedded system / IoT device but never had the pleasure (yet!).
We use OpenBSD for our VPSes on Hetzner, bare metal (for security focussed clients) and older (but still good) hardware in our Home Lab. OpenBSD is excellent on older (no longer supported by Cupertino) Apple hardware. We have an Intel Mac Mini Cluster with near-perfect uptime. If you need to run any kind of server (Web, Mail, DNS, NFS, Database) where you need stability & security, look no further. Some learning curve, but totally worth it.
Have you tried such Openbsd installations vs FreeBSD? I forget the differences between OpenBSD and FreeBSD, so forgive the naivety. (I think NetBSD is more for embedded stuff, and Ghost and Dragonfly are more for conventional desktop use-cases if i recall correctly.)
I'm asking because i have not touched any BSD for over 2 decades...and I'm getting the itch to try some out...and was wondering if for server-type use cases (like you noted) whether OpenBSD is preferred over FreeBSD or the reverse, and why? Thanks in advance for any feedback you might provide!
FreeBSD is a heavier, more capable system, suitable for large servers. It's got its own virtualization platform (bhyve), an LXC-ish container system (jails), native ZFS, dtrace, Linux emulation, and a bunch more. It makes for a decent workstation and has pretty decent hardware support.
NetBSD is small and simple. It's a lot like an old-school UNIX. It makes a decent platform for small services. I run bind and dhcpd on a NetBSD machine. The source code is very pleasant to read. It uses the pkgsrc software repository. It's my preferred platform for writing POSIX code.
OpenBSD still carries much of the general feel of NetBSD and can fill a similar niche on a network, but the security focus stands out in their documentation, subprojects (OpenSSH, LibreSSL, OpenNTPD, etc.), APIs (see pledge(8)), and policies. It makes for a great firewall. I'd say it also requires the most know-how.
All of them have excellent documentation (especially compared to Linux distros) and the base system is developed alongside the kernel, giving you a very consistent experience compared to Linux distros where everything is developed in isolation. If you write C, it's worth keeping a BSD system around just for the manpages and to make sure you're not letting Linuxisms creep into your codebase.
Thank you, this helped alot!
> Linux emulation
Just to clarify. It's not emulation in the sense it's slower or something. They call it compatibility layer, which is better, but also nobody knows what it means.
This is simplifying a bit, but it's essentially "Linux is just a kernel" so the interface is just Linux syscalls, so the FreeBSD kernel when executing a Linux binary simply answers like Linux (so it has those system calls). How this is used in practice is that on your file system you have Ubuntu/RedHat/... "installed" (so the files and the file hierarchy are lying there) and you either directly or in a FreeBSD jail execute things in there or the binary you have.
I don't know how well it works in the present but in the past that means you could simply download the Unreal Tournament 2004 multiplayer demo or Enemy Territory or other games and just play them as if you were running Linux, 3D acceleration and all, without VM without real emulating, just the kernel providing what a Linux kernel would provide.
Also "heavy" is very very relative and subjective. You can totally have a tiny FreeBSD and a huge OpenBSD and one could argue OpenBSD is "heavy" because it comes with three window managers, an HTTP server, a full blown SMTPD server, ACME client and a ton of stuff that eg a server install of Debian or Ubuntu doesn't come with. But also if you run eg. ZFS things are heavy of course. FreeBSD has however had a time when it tried to strip a lot of stuff from the default install and make stuff either optional or make things available through ports/packages only.
And also there are surprises to be had with such overviews: Eg. your Lenovo laptop likely will give you a more "out of the box" experience on OpenBSD compared to FreeBSD with things like simple wifi setup, sound often doing the right thing (work, come out the right place, etc.) compared to FreeBSD. Also with stuff like HTTPD with ACME being available in a simple way after install I'd say OpenBSD is easier than FreeBSD.
FreeBSD to me feels a bit more like "it can be everything you want it to be". Ports and packages can be complicated if you just start out, compared to OpenBSDs "just use packages" stance. On OpenBSD things in my experience are more of a "it works or doesn't" and when it works often out of the box and/or with docs, while on FreeBSD it's more like it throws some tools into your direction you can build stuff (poudriere, jails, a build system with many options). So it's really cool if you want flexibility but a bit more like you have to figure out if it's possible and how. But that might simply be because of the use cases I used it for.
That said all of them are real general purpose systems, unlike eg. some Linux distributions. So it's not like "OpenBSD is for routers" even though it often seems like it. There are time when the GPU support is better on OpenBSD than FreeBSD's. But also FreeBSD has official NVIDIA drivers, so it's all not that clear cut.
I don't have much to disagree with there, only that any survey answer is the difference between complex things is going to be simplified. I'm thumb typing here and no one's paying me to write a book.
I will defend my "heaviness" argument, though. Sure, you can run OpenBSD on large hardware, but it's not going to be able to take advantage of it like FreeBSD can. Which makes sense if you think about it - FreeBSD optimizes for heavy workloads. Conversely, if you set up minimal installs, OpenBSD will be smaller. Again, that makes sense, since OpenBSD focuses on security over features (plus the only truly secure code is the code that doesn't exist). There's a lot of overlap in the middle, of course.
I wouldn't use OpenBSD for a NAS, and I wouldn't use FreeBSD for a diskless firewall. Not because they can't do those things - they just each have their strengths and weaknesses.
The "lightweight" nature of OpenBSD is a matter of perspective - if you are happy with OpenBSD's feature set, then it's a plus. On the other hand, FreeBSD has a lot of additional features, including ZFS, which may be of interest. The last I checked, FreeBSD was more performant in various benchmarks, particularly regarding multi-core performance.
FreeBSD has a bit more of a lax attitude historically to security[0] and seems to prefer being reasonably performant and "easy to use" (this is subjective, but they care about supporting packages outside of base very much, and bundle non-FreeBSD produced packages as part of their base).
OpenBSD on the other hand is perfectly happy to leave oodles of performance on the table for security. They were the first OS to completely drop Hyperthreading support for example, years before spectre/meltdown.
So with these things in mind, FreeBSD is a lot more performant.
[0]: https://vez.mrsk.me/freebsd-defaults
FreeBSD has the same roots as OpenBSD but the former has a “compatibility” focus whereas the latter has the security focus. Having a background in security, the choice was obvious for me. But each person/org should decide based on their needs. Haven’t had any issues running it on all major hardware (Dell, HP, Lenovo, Apple, etc) the UI isn’t as pretty as macOS on Desktop, but it runs Firefox & Chrome, etc. so you can do everything you need. If you have an older Lenovo or Mac lying around collecting dust, dive in!
There was FreeBSD and NetBSD. NetBSD supporting many platforms while FreeBSD supported just x86. There was some contention between NetBSD developers and Theo and crew left to create OpenBSD. They all more or less have common ancestry being derivatives of 386BSD.
Yeah, i knew there was some aspects of decendancy across the different BSDs.
And, I mentioned NetBSD for embedded stuff...but really, i *think* its that NetBsd is simply installed on tons of different hardware....so not only embedded....i kinda remembered that about NetBSD.
But, its the other BSDs - in particular FreeBSD vs OpenBSD - that i always forget the differences...but got it now. Thanks!
freebsd = utility
openbsd = security
netbsd = portability
freebsd: performance, features, drivers, software compat - closest to linux in utility & usability though unlike linux in execution
openbsd: safety for exposed services
netbsd: portable across many cpu & hardware platforms - big-endian powerpc sun, hitachi sh3 jornada, etc, easiest to port to a new arch
Can FreeBSD be stripped down to be more like OpenBSD security wise while still keeping the performance benefits ?
It can be customized just like linux where you can compile a custom kernel omitting unneeded features and then also ship a small userspace around it, and the core userspace tools are generally a little less feature rich than linux's already.
But it's not a matter of surface area that makes openbsd solid, it's the priorities while writing that affects how every little thing has been written over time.
You can write 10 different versions of a function that all work and are all nominally perfectly free of security gaps.
Yet they will all still be 10 different levels of robust. Some versions will fail as soon as some assumption is violated, and some make fewer assumptions and remain safe even when varying amounts and forms of "that can't happen" happens.
It's not just cosmic ray bit flips either, or a hacker trying to do power glitch attacks or rowhammer etc, stuff that makes the hardware violate it's promises. But stuff like a different developer updating something 15 years later who is not the original and does not realize every single facet of how it works and just how the current implimentation covers all possible edge cases, and so doesn't realize how their change opened up an edge case that was covered before. With fragile code, the new code simply has the new security gap until someone discovers it the hard way. With robust code, it's more likely to still be safe. The edge case maybe makes it fail to function, but not in a way that anyone can use productively.
Not that freebsd is exactly swiss cheese. These are all relative. I would and do rely on freebsd any day.
Oh this is a wonderful and succinct summary; thanks!
It's also superficial and wrong, and as bad as dividing people up by hair colour into blondes, brunettes, and redheads.
The way that the BSDs differentiate cannot be reduced in this way, not least because there is a lot of what Justin C. Sherrill (of the DragonFly Digest) calls 'cross-pollination' amongst the BSDs.
A case in point:
Superficially, and erroneously, one might observe that OpenBSD, NetBSD, and FreeBSD have nvi, and only DragonFlyBSD has nvi2. In fact there was a three-way fork of actual Bostic nvi, all of them making revisions and leaving the original behind, and then things got really complex with nvi2 taking from OpenBSD's nvi, and FreeBSD's nvi taking from nvi2; not even getting into the existence of nvi-m17n along the way and how there are nvis in base and nvis in ports. (https://news.ycombinator.com/item?id=48132452) One cannot divide the BSDs up into those that have nvi2 versus those that have nvi.
The split is complex in other areas, too.
Yes, you're not at all wrong! However my goal is not to definitively 100% know the exact differences between the BSDs...i merely wanted to seek out a quick/easy starting point (the very high level diffs)...so that i can start *somewhere* and hopefully avoid my paralysis by analysis. :-)
It is a generalization of the essentials, and not wrong.
You know even though I said the execution is unlike linux, in fact, there are many many details that are just like linux! What a freaking ignorant liar eh? There's like 100 things like that you could say. No wait, no way it's exactly 100. There's obviously some other number like 105 or 612 things like that. So superficial and wrong!
Actually that is mostly current HW compat. NetBSD would be I guess the one for legacy HW compat.
OpenBSD does support some older hardware already not supported by, say, most Linux distributions. As an example MacPPC has’t had support from most Linux distributors since IBM Power went little-endian, but OpenBSD runs fine on it.
NetBSD is, however, the gold standard for an OS that runs on just about anything. Their (maybe unofficial) slogan has been “Of course it runs NetBSD!”. Their logo has a flag in it because they “plant their flag” on so many platforms.
https://wiki.netbsd.org/ports/
Yeah, thanks that helps! Its the old convenience vs security balancing act :-)
100%. I put off learning/using OpenBSD for a decade until a breach at a client (we weren’t responsible for DevOps/SysAdmin) made me pick it up because I don’t have time to be a full-time Linux Sysadmin anymore. Just want the servers to run without having to think about them. Wish I’d done it sooner. Lost at lot of time on Linux, Docker, K8s, etc. that I could have skipped completely with OpenBSD. Our servers are an order of magnitude simpler now, just single services per VM and I sleep better. ;-)
> ...I don’t have time to be a full-time Linux Sysadmin anymore. Just want the servers to run without having to think about them...
Very salient comment there! And, while not the only reason for me, but what you noted is sort of one reason that's triggering the itch in me to go back to playing with the BSDs. Don't get me wrong, I still do love fiddling around with some areas of linux once in a while....but then, there are other uses/areas where i just want a server to do its thing, and for my maintenance to be a little less (at least less than some linux distros require). So maybe i'm not the only one? :-)
Yeah, time is finite and fleeting and the older I get the faster it seems to go!
As a teen I had infinite time to compile Linux and debug stuff. Now I just want to spend time with family/outdoors and not be stuck in a windowless room negotiating with a black box. ;-P
Its like you're reading my mind!!! lol :-D
OpenBSD is security focused while FreeBSD will remind you of older X-Windows workstations.
Thanks!
And, wow, do i miss the old X-window workstations...well, i should clarify that i LOVED those (I think they were Sparc?) workstations that ran Solaris or SunOS back in the day! Man, that takes me back some years...but i really loved those machines! :-)
OpenBSD supports sparc very well and is compatible with old sunos stuff (iirc). Unfortunately no 68k anymore (okay, technically there's a niche flavour of 68k that still is supported because of a very dedicated man in Japan)
> OpenBSD supports sparc very well and is compatible with old sunos stuff (iirc)
No 32-bit sparc anymore (only UltraSPARC, aka sparc64).
No SunOS compatibility (despite Theo de Raadt inventing it for NetBSD, before being copied by other BSDs).
https://marc.info/?l=openbsd-tech&m=161435521906992&w=2
> Technically there's a niche flavour of 68k that still is supported because of a very dedicated man in Japan
luna88k, while related, is not 68k.
https://www.openbsd.org/luna88k.html
Modern operating system booting on hardware that is closing in on 40 years old in just over three minutes, this is wild to see:
https://www.youtube.com/watch?v=btwiiZw3B2s
Kenji Aoyama truly is aligned with the best of the hacker spirit. As for getting your hands on a luna88k, I have no clue. The only thing I managed to find was a broken one that sold for ~USD 750 at an online auction.
If you're interested, you should check out Miod Vallat's Motorola 88k story.
http://miod.online.fr/software/openbsd/stories/m88k.html
One interesting bit of trivial is Luna-88k workstations were heavily used to implement CMU Mach (which would eventually be used by Apple).
I must've read about the sunos thing somewhere and imagined it still existed.
>luna88k, while related, is not 68k
I misremembered it as being similar to the relationship between the 6502 and the 65C816
It's worth mentioning at this point that one can still get (Open)Solaris descendent operating systems: OmniOS, SmartOS, and Tribblix. The latter still has SPARC in its installation guide.
* https://tribblix.org/install-sparc.html
Oh wow, that's pretty cool! Thanks for sharing!
Another part of my nostalgia with those old workstations (besides the core OS) was the desktop environment, i think CDE or motif or something like that. Something about the look and feel of that DE i always thought was cool!
What's the situation with Broadcom wifi on your intel macs?
We've run into instability issues with the newer Linux kernels (starting with 6.x, I think) and have had to stop upgrading.
I've just setup a new ThinkPad with openbsd. You just need to put the firmware needed on a usb stick, mount it and run one command, fw_update -p ./ It wasn't hard.
Ah, we have all connected via Ethernet. Side-stepped the WiFi issue. ;-) But have read of others successfully navigating it.
I use OpenBSD among Hyperbola GNU/Linux, soon to be rebased from a deblobbed OpenBSD 7.0 hard fork. IT's dumb easy to setup too. Also, I daily use nvi, oksh, oed (a portable ed for GNU/Linux) among Xenocara and CWM, and this way the environment it's almost the same as OBSD but with a GNU/Linux kernel.
(technically it's just a Linux kernel. GNU doesn't do any kernel work aside from deblob scripts)
Yeah, I'm aware of FSFLA and Linux Libre, but Hurd is not ready yet and it's being worked on with LLM's (something really anti-GNU, as it's propietary SAAS).
https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00100...
In the end Hyperbola BSD will be more free than OpenBSD and the former GNU maintainers themselves...
I don't really see the LLM use as anti-GNU. It would be no different if the code was written in a proprietary IDE with fancy code completion. GNU doesn't restrict contributors to using exclusively free software for their contributions (if they did, they likely wouldn't have gotten very far considering how much work apple did on GCC). As long as the license is free and GPL compatible, it isn't inherently non-GNU (though, they'd encourage you not to use a SaSS for your own sake)
Now, is LLM code in the hurd a good thing? No, absolutely not. Ignoring the licensing limbo of LLM output that still isn't settled , LLMs make pretty bad code often enough that I wouldn't trust it to work on something as niche and relatively undocumented as the hurd.
A local LLM with GPL compatible input and with options to properly tag the source with a full backtracking of the code? Maybe, but that's not what's happening, but massive license laundering.
I never said anything to the contrary, I agree 100%
I want to use OpenSMTPD so badly, but it doesn't have proper support for authentication via LDAP (at least, as far as I can tell). It insists on reading plaintext passwords from the LDAP server, rather than BINDing as the user in question.
I use it on my personal laptop, essentially because I like how slim and simple it is.
Packaging is simple, kernel development and upgrade is simple, etc. Also the kernel code itself is written in a style I like, it's to the point, no useless abstractions, no fuss. I prefer it even amongst other BSDs I tried (netbsd and free*lbsd/dragonfly).
It just feels nice to be able to understand most of your system. It's not as fully featured as Linux, but there is a sense of understanding your system that is refreshing. A bit like if you're on vacation in a small and cute village where life is mundane and calming. At least that's how I feel with it. Mileage may vary.
This.
A while ago I made some blog posts[1] diving into the source code of OpenBSD and FreeBSD (shameless self plug), but haven't had the time recently to write more.
Being able to understand the system, or at least being able to take a quick look when something doesn't work is very refreshing. Not to mention the outstanding man pages. Barely need to google things.
[1]: https://blog.wollwage.com/
I used to run it on a laptop too, but the battery life was shorter and the laptop ran noticeably hotter than under Linux, so I eventually switched back.
That said, OpenBSD feels unusually coherent (ej. check wifi connection from terminal). The whole system has a level of consistency that's hard to find elsewhere, also between other BSDs.
For pet servers, it usually fits perfect.
> I like how slim and simple it is.
I ran OpenBSD on my laptop 22 years ago. Back then, a full GUI environment with terminal, web browser, editor: 28MiB of memory for the whole operating system and user environment!
About 10 years ago we moved offices, and I was over checking out the new internet circuit and cabling in the office. The circuit was up, and I hadn't brought anything with me to connect to the network, but we had already moved some boxes of old stuff over.
I found a 10+ year old Dell Pentium III laptop in one of the boxes, installed OpenBSD to do some simple connectivity testing, and ended up with a full workstation install and using it for network monitoring and some other random stuff. It stayed in the network/server closet until we moved out of that building just a few years ago.
> there is a sense of understanding your system that is refreshing
That's why I used to run Slackware, and then foud Alpine to be the best - much better than Void or Arch IMO. Works well as a very minimal system, and I know everything very well because of it. It's an ideal approach IMO, the best of both worlds.
I run it. Home firewall, office desktops and laptops. It's pretty stable and I'm fairly familiar with it. Really simple if you know Unix. I hope it never goes away, not sure what I would replace it with. Linux is so complicated now, it's just too much for me to deal with
If OpenBSD dies (somehow, at this point so many things are maintained there (OpenSSH, LibreSSL, PF, Tmux, sudo kinda) that it'll always exist to a degree) one of the other BSDs will suffice. FreeBSD is bloaty but for the most part works fine enough
Yeah, I also use it because it is fairly low maintenance. There's the sysupgrade every 6-month, but it goes smoothly every time.
What software do you run on your desktops and laptops?
Not GP, but I mostly use: Firefox; Emacs; MPV; Keepass; calibre; xfe; mupdf;... Then a bunch of cli tools. There's a lot in base, so cli are mostly extra utilities like cmus, git, tig, ncdu,...
I would imagine that a lot of people who use OpenBSD on their laptops/desktops run a lean installation with one of the window managers in base (an ancient fvwm version, cwm which I find very nice and twm).
You can however have a full-fat desktop environment with xfce4 or gnome and applications like libreoffice, gimp, inkscape, audacity and so on if you wish. I've never tried KDE on top of OpenBSD base but I gather packages are in ports.
I think it is fair to say that the amd64 arch has good support. The i386 platform arch is on a 'best effort' basis these days which is understandable. I've never looked at the others.
SPARC is well supported (mostly because it's very good at finding bugs that wouldn't be big problems anywhere else despite not being 'correct') and big endian PowerPC (both 323 and 64) is fine, though hardware can be tricky since apple products tend to be so integrated that you can't really, say, replace a GPU because the support is poor
i wonder how gnome will be supported in the future on systems without systemd. heres a thread of someone beginning the process of replacing systemd with gnu shepherd: https://discourse.gnome.org/t/accompanying-non-systemd-distr...
My wife and I are building a wedding rentals company. I'm responsible for the digital part and building a Ruby on Rails app deployed to OpenBSD. The entire thing runs on a cheap Supermirco U1 server in a rack at our home. :-)
open-bsd will always feel like a safe pick for anything in regard to vault or key holding ; it's not appropriate to run anything CPU intensive - but it's a very appropriate system for anything that just need to boot up and hold some data ; eventually expose a network interface.
I use it. It's secure, and if your hardware is supported it mostly just works. A good unix experience if you're willing to learn its intricacies
I use it for my home router, a small home server, a personal VPS at https://openbsd.amsterdam and a development VM (mostly for testing BSD backends on portable software).
I wish I had an OpenBSD development laptop, but I don't have one right now.
Authoritative DNS (nsd) and email (opensmtpd) runs out of the box with minimal config on very low ram kvms. The documentation is fantastic, installation is easy; sysupgrade has been a big improvement, though I wish they'd slow the release cycle a little
I use it for home router, my laptop, several vms for various services, and on one vps I keep around should I need to quickly set something up. I keep a proxmox server for anything I can’t or won’t run on OpenBSD.
Been running it as my home router since 2.3. I had it on a server for a very short time when I used hardware RAID but I replaced that quickly with FreeBSD for ZFS once I could afford to replace that old Dell.
I ran it on my personal laptop for several years when I had one, but having a work laptop for these past decades I don't have much use for a personal laptop. I would probably run it again on a nice portable when I retire. It would be nice to focus on being creative on such a machine. Coding and drawing mostly. I will continue to use Linux in my recording studio though.
I've been running OpenBSD on my main laptop for about a decade, as well as on routers. It has the most consistent and well-designed interfaces of any modern *nix other than arguably macOS.
It is, by far, my first choice for a router/firewall. It has so many niceties for this, all well integrated OOTB, and you can deploy something top notch in no time at all.
I use it for my mailserver (thank you openbsd.amsterdam), for the gateway in my homelab, a dedicated OpenBSD VMD machine in my homelab, and on personal machines (Macbook Air M2, a Thinkpad X220 and on a T480 that dualboots OpenBSD/FreeBSD).
For mailserver I think it is the best option. And for Gateway, PF is just wonderful.
But even on my laptops I enjoy it. It is rock solid, and I have pretty much no complaints.
Web/SSH/mail server using the built in httpd, sshd and smtpd. Very happy with it.
And on my laptop, occasionally, to experience it in person.
Single tenant(and single core) tiny VMs with OpenBSD's VMM hypervisor and confidential computing through AMD-SEV.
It has been my daily driver for years.
Not really, but OpenBSD has been in my life for 25 years.
I used OpenBSD to create the firewalls for our LAN parties when I was at school.
The first shellserver I ran, on an UltraSparc IIi was OpenBSD, gave out accounts to my friends.
And then I used it as a firewall, both professionally and personally, for many years. Until the first Turris Omnia was released, and now I have retired even Turris for pfSense, which is FreeBSD I believe.
But the PF firewall in OpenBSD was superior, definitely to the syntax of IPtables.
To me Linux was a great server OS, and OpenBSD was a great FW/Gateway OS.
Runs well on my Lenovo T-490. I use this as my main non-Windows laptop.
Running OpenBSD 7.9 with KDE 6.6.4. Desktop usage.
My home router, firewall and VPN gateway is an OpenBSD box, Intel N100 with quad 2.5G Ethernet. To be frank, Linux has better support for fighting bufferbloat with FC-CoDel, but pf is so much saner than Linux firewalls it's not even close.
WiFi is handled separately by a Ubiquiti UniFi system, but I don't trust Ubiquiti not to exfiltrate data after their underhanded attempt to turn telemetry on a few years ago. OpenBSD WiFI is somewhat mediocre, but it has improved in this release with experimental support for WiFi 6 after years of being stuck at 802.11n.
The closest you will get to the OpenBSD experience on Linux is with Alpine Linux.
>so much saner than Linux firewalls it's not even close.
This is a big one for me. I've run openBSD and Linux custom boxes as SoHo routers and I just cannot stand Linux firewalls, I've never liked them and IPTables is just terrible. Yes I know there are wrappers around it now but it's still the default everywhere and still used by lots of other software like Docker. I'm using OPNSense now which is FreeBSD based instead of completely rolling my own but I love that it is still BSD under the hood.
One differing opinion I will offer is that I find NixOS to be the Linux distro most in the openBSD spirit despite it being very different from a UX and config management perspective. Alpine is interesting, but it has its own security and compatibility issues, especially around MUSL libc which I have had cause many strange downstream issues over the years, I just hit one recently in JVM GC caused by its memory allocation implementation. I've stopped using alpine altogether because of them.
I do. Multiple things:
Work: I need a simple easy to use system that I can configure to meet third party compliance requirements without jumping through hoops. It really excels when you can mostly use the base system there, maybe couple services. For example it's so nice to just have a couple pledge/unveil lines for example in a Go service.
Also super nice for "set and forget" style stuff. For example "I just need a HTTPS server with acme and SFTP". That's something you get out of the box with no third party packages (so everything vetted, pledge/unveil for everything, maintenance just running syspatch and sysupgrade), which is really nice.
Personal: Private mail server, family website, a quick and dirty "watching streams together" service I set up to watch stuff with people not in the same place as I am. prosody to have XMPP for friends and family.
I would NOT use it for "people throw stuff at you" use cases (Linux and FreeBSD do a far better job there). But I absolutely love it for scenarios where you want very very low maintenance. For example that private email server. I don't have time to do big upgrade plans, or "hardening" systems or reinventing the wheel. I cannot afford to do privately what I do in a day job or consulting (setting up or maintaining really rather complicated infrastructure).
I have done that many years with Debian, but the Linux world sadly is a big complex and complicated mess. That's great, when I get paid to deal with it, but annoying otherwise.
And I don't mean that bashing wise. I use Linux, I like Linux, but somehow there is a huge drive to overengineering and then building hacks and weird workarounds that become normalized until it's a proper job. Without wanting to start a flame war, but the whole Docker, Containers, Kubernetes, Helm, Orchestrators, etc. story is a lot of reinventing the wheel and a static executable like a Go service in a container, so essentially coming with a whole Linux distribution even though one never thinks about it that way is just really absurd. That's what executables, processes, etc. were invented for.
And since I've lived through the story and as mentioned make a limit, I understand how that came to be, but it feels like the industry took a wrong turn because it was cool and exciting and then (nearly) everyone decided to use that hammer for everything one could imagine to be a nail. And then the next layer came and the next and the next. But all of them doing things differently. And suddenly to have a Postgres cluster you need Kubernetes, and Helm, but also need to know both PG config and the orchestrator's config, etc.
It's a mess and the OpenBSD people somehow knew that decades before I did.
I use OpenBSD for my home server. Runs everything from httpd to a Minecraft server.
I’ve been using it on an old PC Engines router (great hardware, by the way! I wish they were still around.)
It ran for over 8 years without downtime, but I’ve had repeated problems in the last year or so.
I used the default partitioning scheme, which makes /usr tiny, and /var huge, and since it is a router, did not install X11.
At some point, they made x11 mandatory for auto updates. This is dumb, because all the upgrade tool is doing is untarring a list of tarballs. So, I had to perform partition surgery from the upgrade ramdisk to make room for X11.
Now, they made some ASLR relinking scheme mandatory, which makes sense, except the relink directory is 1.5GB (larger than the entire rest of the distribution, and far larger than the parts I voluntarily installed!).
For some reason the relink output files go in /usr, which, by default, won’t hold it at upgrade. It really belongs in /var, because it is not immutable, and also, there’s room there! So, I had to repartition the router from a rescue environment again.
They also removed the ability for ntp to sync on machines without cmos clocks, and the alternate config options don’t seem to work. That’s a bit more niche, granted, but my router hw is reasonably common for openbsd use and has that property. You can make it work by using a second utility to force clock sync at boot.
I like that they keep things simple, but they also recently pulled out any semblance of power loss safety for their file system. I’ve had to serial console in a few times to run fsck, which isn’t really the behavior I want from the home router!
They don’t have any way to setup DDNS in the base install, so you have to use a port or pkg. The port I chose was EOL’ed by upstream (ISC), so I’ll probably need to switch to dnsmasq as a dhcp server / dns server, which is fine, but those services are a significant fraction of the attack surface of my router. DDNS seems like a pretty simple thing to implement, and would be really high value for router use cases. Without it, I’d have to assign static addresses to everything on the LAN, then edit DNS records.
I think all this stuff is fixable, but wish they’d take the niche of “rock solid secure infrastructure” a bit more seriously. This used to be a nice “set and forget” weekend project but now it requires attention every few release cycles.
7.8 barely managed to fit in my duct tape and bailing wire partition layout. I’m probably going to switch to freebsd on a box with faster NICs when I finally get a > 1GBit internet connection (hopefully in the next year or so).
If I upgrade to 7.9, I’ll have to give up on using the openbsd hypervisor, since, with the partition scheme that the installer chose, there will no longer be a partition large enough to hold the download sets and also the vm image.
This is particularly frustrating because the boot drive is under 50% full. I’d just do “one big partition”, but they warn against that for good reason - it complicates manual fs repair at boot.
Anyway, I really like the project. It would be nice if they did a “fix common papercuts” release, since I doubt many users are as patient as I am.
If you are looking to install it, either use fewer partitions, or way over provision storage (I was 10x over provisioned at install, and the stuff I use hasn’t grown more than 10-20%) and also make sure you choose much larger partition sizes than recommended. This will add under $100 to your hardware cost, even with the storage shortages.
Backup, do a fresh install with new partitions, restore. You have to do this every once in a while especially if your partition sizing is from nearly a decade ago.
My one complaint about OpenBSD would probably be lack of resizable partitions. You can expand them, but only if you have free contiguous space and most of the time one partition starts where the prior one ends. It's rarely a problem in practice, as only /home and /var and maybe /usr/local tend to be subject to any guesswork, but it can bite you from time to time as in your case.
My point is that you shouldn't have to do this!
I've already done this twice for this box. Its disk is half empty, and the used space is 75% compounding useless bloat:
- 50% of the used space are package sets I never asked for.
- The stuff I did ask for is somehow 2x larger than it needs to be, since they don't randomize binaries in place.
- If they'd actually follow their own filesystem hierarchy standards, and stop using /usr as a build target (very bad things will happen if a crash happens in the middle of that! Why are we making lots of small separate partitions again?!?) then I could just make /var big. Then I would not have to repartition yet again after they introduce /lib/lolz/3gib or whatever in 2027.
Alternatively, if they had a journalling filesystem or still supported soft updates, then I could have one big partition, which would solve it once and for all.
Anyway, I'd argue "take the lan offline, backup the router, repartition and restore" isn't a planned reasonable maintenance task for a router. The fact that its so obviously easily avoidable is really frustrating.
Alternatively, if they just had a "which sets to install?" config option for auto-update (like they do for the OS installer!) then I wouldn't have to do this.
Yeah it sucks when partitions that were sized 8-10 years ago are no longer adequate. I've hit the "/usr is too small to complete an upgrade" trap myself. When that happened I rejected the installer's partition suggestions and made /usr substantially larger (this is also necessary if you're going to be building large ports, which also happens under /usr).
So far that has worked for me.
Some people would also argue that using an 8 year old device as a critical path in your LAN is a risk in itself. Taking routers down to do upgrades is pretty common in the enterprise IT world.
It’s not just the partition sizing though. The lack of DDNS and clock re-sync are really painful.
Similarly, if fsck -y is frequently required, maybe just run that way all the time instead of failing to boot, or fix the root problem. I doubt many sers are taking block level backups for forensic repair in case they need to hand assemble inodes.
Anyway, I wish them well. I want a simple, correct and rock solid OS for this sort of use case. The three pillars of computer security are confidentiality, integrity and availability. Hopefully they’ll focus a bit more on the latter two things than they have recently.
I needed to create a backdoor network-level KVM contraption to help my dad relocate some servers. tl;dr an office was closing down, he pulled the rack and stood it up in his basement. I mailed him a unifi edgerouter 4 that was reflashed to run openbsd. On boot it would create a vpn tunnel to a vps and basically expose a public WAN port to the rack. So it was in my dads garage on his Fios internet, but from a networking perspective it thought that it was in a Linode datacenter.
The ER4 has 3 ports: 1 was for the uplink, one exposed the WAN connection to the rack, and then the 3rd port became a client inside of the network. I could shell into it from home (he's on the other side of the country) and operate from the residential network and also the server network simultaneously. Worked well enough for a few weeks to keep access around until we could engineer a better solution.
Configuring OpenBSD was really quite simple and rewarding. No insane linux network stack / netplan / cloud-init / bs ... just a few conf files.
obligatory pic: https://i.imgur.com/Mkf9ckc.jpeg
"Introduced a mechanism to manage CPU cores with different speeds in the scheduler. The sysctl(8) variable "hw.blockcpu" takes a sequence of 4 letters: S (for SMT), P (regular performance CPU), E (efficient CPU, generally 80% to 50% as fast), and L (lethargic CPU) which are even slower. Set this to select CPUs to kick out of the scheduler (SL by default). Currently works on amd64 and arm64."
I have to admit I am not entirely convinced about the merit of having slow cores on the cpu at all(big/little architecture). You don't want your tasks to be scheduled on them. And even for background tasks shouldn't it be better to have them complete faster for less power? To say nothing about what if they have different features. what happens when a process that wants to use cpu feature X(avx512?) gets scheduled on a cpu without X?
Openbsd took the quick and dirty shotgun approach here in disabling the slow cores. But is there even a good heuristic for scheduling jobs on them? The only thing I can think of is some sort complicated mechanism of putting manual tags in the executable or thread. A "this process is suitable for slow cores" sort of thing.
I was reading about this on on the lists, apparently a naive scheduler puts a process wherever and some new big/little systems have very slow little cores. This really hit recompiling code hard.
> And even for background tasks shouldn't it be better to have them complete faster for less power
Race to idle is only clearly beneficial for tasks that have a clear start and end. If a background task is sustained, responds to unpredictable events, or does small amounts of work and wakes frequently, the CPU's boost logic won't solve your energy usage problem.
> To say nothing about what if they have different features. what happens when a process that wants to use cpu feature X(avx512?) gets scheduled on a cpu without X
This idea has been proposed in the past, but isn't actually used on x86-64 or ARM. E-cores have the same instruction set as P-cores, so there's no risk of running into an invalid CPU instruction.
Truly heterogeneous instruction sets may come back in the future, though. So be on your toes.
> Replaced the cas spinlock in kernel mutexes with a "parking" lock.
Anyone know what a "parking lock" is (and how it works)?
I couldn't find anything on the man pages about it.
https://man.openbsd.org/OpenBSD-5.5/lock.9
https://man.openbsd.org/OpenBSD-5.9/mutex.9
"Parking" lock is a reference to this:
https://webkit.org/blog/6161/locking-in-webkit/
Thanks!
Wow, this is from 10-years ago.
It's a lock/mutex implementation that puts the blocked thread to sleep, usually via cooperative yielding to the scheduler instead of continuing to perform CAS operations on the lock continuously. Spinlocks have great performance when they're not heavily contended and the locks are held for short periods of time, but if either of those things are true the blocked thread can easily consume an entire CPU core while it's blocked.
I would really love to adopt OpenBSD but the one thing I can't deal with is the absence of journalized filesystem.
Just the idea not to be able to recover after a power cut and work is hard to accept to be honest.
I have been recently considering running it on a minimal Alpine ZFS host but I am not sure how much I can optimize the display experience since I do not think OpenBSD support QXL/SPICE.
I would be curious if someone found a way...
Once you have workloads that can't tolerate a power cut + running fsck for a potentially long time, a battery backup becomes an excellent investment. I bought a UPS on eBay for cheap and my home server hasn't gone down since.
fsck is good. I have to hard reset my laptop a few times and I didn’t have corruption. Maybe a server has a different risk profile, but journalized systems are not file backup, which is what you should focus on.
I wish OpenBSD supported Bluetooth. Unfortunately, its absence is a deal breaker for me. I did use OpenBSD on the desktop it was great.
* https://www.openbsdhandbook.com/multimedia/#bluetooth-audio
Removed in 2014.
The sole set of wired headphones in my house is for my OpenBSD laptop.
Interesting! Curious which Bluetooth device(s) you can’t live without.
Naming a few peripherals on my desk that see regular usage on Linux:
- Kensington Expert Trackball (I lost the 2.4ghz dongle)
- JBL wireless earbuds/Audio Technica M40xs
- Nintendo Switch controller
Ah, losing the 2.4ghz USB dongle ... Sucks. Feel you. :-(
Wireless Earbuds/Headphones are a legit use case. (Still use bluetooth with iPhone every day, sadly, still addicted to the convenience of AirPods ...)
But I've got decent wired headphones for my OpenBSD setup. bonus: never have to charge them. ;-)
Even more curious now: what do you use the Nintendo Switch controller for on your computer? Have you got it hooked up to play games on your PC? Or do you use it for robotics or other I/O?
Switch controller gets used for flight simming, just as a simple analog input that I can take to the couch (or bed). I've also got a wired pair of my wireless Audio Technica headphones, but I'm not confident that my DAC (or Bitwig for that matter) would work as well on OpenBSD as it does on Linux.
For desktop use, I don't think I'll ever end up on OpenBSD. It might power my gateway router one day, but the cost/benefit analysis falls through on hardware like a laptop or gaming PC.
Makes sense. Great use of the Switch controller for flight sim! Sounds like you’ve got your system dialed in. ;-)
For others who cannot live without Bluetooth on their main machine, consider a USB Bluetooth adapter. see: https://man.openbsd.org/OpenBSD-5.1/ubt.4
Firmware backdoors in wireless chipsets are a really big attack surface, and disabling wireless at least gives you the chance to monitor five eyes activity on ethernet.
That's too bad. I might need bluetooth on keyboard, mice, headphone/earbuds, etc. OpenBSD seems so nice, but right now it is limited to running as a server, and not a desktop, which could be considered a good thing, as it focuses on simplicity. However, I do wish it had more hardware support.
EDIT: Running openBSD in a VM might get me the best of both world, with hardware support on host OS (linux/win) and the benefit of running OpenBSD.
It should be done in userspace, but then again, so should everything else[0].
0. https://microkerneldude.org/category/sel4/
You can often build generic dongles for pretty much anything on the cheap if that really matters to you.
E.g. I use the Seeed Studio XIAO nRF52840 for my BLE keyboard.
They did for awhile, but removed it due to complexity and security issues.
It wasn't security really, it was just the entire stack being so complex and poorly maintained that it became insecure. If someone wants to go back and do things right, they're free to do so
Sweet, I was just wondering when 7.9 would release. And with a song! We haven't gotten one of those in a while iirc
I always check their releases to get the song, like in other thread.. last song was 7.3
Congratulations for another amazing release! This one even comes with a song :)
I'm using it as a daily driver since Debian adopted systemd and it works great. I use it wherever possible: home router, laptops, obsda.ms vm, workstation, thin clients, etc.
With every release OpenBSD becomes better. Fully recommended to take advantage of old hardware too, like a fanless thin client bought for cheap from surplus.
I really love the no-nonsense approach I can't find elsewhere.
Sorry for the off-topic, but I wish our FreeBSD camp could roll back a little from this faux-corporate glass ball without soul and a font from the early 90s spaceship toy box, to Beastie and a stylish serif. What I was trying to say - I'm in envy. OpenBSD artwork is absolutely amazing!
They've made major progress on the WiFi front in this release, finally getting experimental WiFi 6 support.
A song released with it too! So much care for OpenBSD.
Nice! Had to lookup when one was last released, 7.3. https://www.openbsd.org/lyrics.html
Announcement mail: https://marc.info/?l=openbsd-announce&m=177919671915512&w=2
> Enabled IPv6 autoconf (SLAAC) by default.
Sweet! I’m just about to replace pfsense with openbsd on my router. Smoothly setting up ipv6 is a bit of a headscratcher atm, mainly because i’ve never had to understand it before.
I recently updated an older OpenBSD router and firewall and the amount of native IPv6 support right out of the box makes this an unbelievable breeze.
Nice. Would you mind explaining your current config?
How do the various BSDs run on framework laptops?
I dual boot OpenBSD on it, and it's been doing fine. The out of the box experience is pretty bare although the default window manager cwm is surprisingly nice once you get to know it. Note that apmd, the power management daemon used to manage CPU speed and low-battery suspend, is not enabled by default. The high-DPI screen required some adjustments in Xresources (I haven't dared try a multi-monitor, mixed DPI setup).
NetBSD seemed okay to but I've only used it a little bit. It actually set up X pretty well for the screen using some built in script with heuristics to determine font size from the screen metrics.
There's been a bunch of progress on FreeBSD, and OpenBSD isn't that much worse
No wifi driver for Framework 16. Was fun installing (and surprisingly quick) and playing around a little. But unfortunately that's a dealbreaker for me.
Power management, webcam, trackpad, accessories, etc tend not to be a good fit for niche BSD and Linux. Stick to desktop or server.
Trackpad? I've had OpenBSD on ~6 laptops, old and new, but the trackpad always worked fine
Do you disagree with my comment? Or just about trackpad?
huh? I've been running Arch exclusively on my laptops for at least 7 years
Thinkpad? Or dell?
How is the battery life?
Let's see, System 76, previously Dell and Samsung.
All the pretty much the smallest and lightest I could find. So not fantastic, but good enough. For me, battery life is much lower on the list than "small and lightweight" and "works well with Linux".
While I daily Linux on my workstation, OpenBSD is my favorite OS, by far, and I use it wherever it makes sense for me.
Direct link to the song so you can play in the browser: https://ftp.openbsd.org/pub/OpenBSD/songs/song79.ogg
the canadian OS :)
Yes free from American restrictions. Because America law prohibits from giving out cryptography to outside countries so according to OpenBSD we outsiders have no luck in getting a cryptographically secure operating system except for OpenBSD
That isn't a thing anymore iirc
If I remember, it's still illegal to export to "rogue states," Iran and North Korea being the major two, and terrorist organizations. But I don't think anybody has been charged for it and there's reason to suspect it wouldn't hold up given the pgp ruling.
We can't really export anything to those "rogue states" anyway. Also, as backwards as NK can act in some contexts, I dislike the classification of them as a rogue state. The kims are pretty good at geopolitics and wouldn't do anything stupid or dangerous without a good enough reason to make its actions no longer "rogue". If anything, the US is closer to a rogue state currently with its rubber stamp congress and willingness to do whatever the orangutan in charge says
>We can't really export anything to those "rogue states" anyway
Sure, but there are additional laws regarding cryptography, even in publicly available software.
"Rogue states" is a legal designation, we can both dislike it as much as we want but I doubt the US will change it's view
I think that pretty much ended in the 90s.
early 2000s so close enough. I know this because for a while, WEP was intentionally crippled in the US for a while because of the archaic encryption laws
Sidenote, does anyone remember a "click here to become an international arms dealer" esque site as a protest of our encryption laws or did I make that up. I swear I heard that somewhere
Developed at 4500ft elevation in the Texas of Canada, primarily.
Well it 40 below and I don't give a...
Neat that they're working on Intel's p/e/l core support. I was just comparing Linux and windows support history the other day.
I use openbsd as my server via openbsd.amsterdam - so much easier to maintain than a linux server for my personal sites.
Hey ... I had no idea OpenBSD had an official song. I think all distros (Unix and Linux) need an official song.
Agree. It's obvious some people are still having fun making operating systems!
I suppose that, ultimately, they all fall under the Free Software Song
https://en.wikipedia.org/wiki/Free_Software_Song
Release Engineering. Noun. See Also OpenBSD
OpenBSD does a lot of things well, definitely punches above their weight. One underrated feature is their approach to releasing. No "When it's done" here. Like clockwork twice a year, they slow down, clean the shop, get their experiments in order and cook a release, a stable point in time. More projects could learn a thing or two from this.
Agreed. I also like that code doesn't get committed without a quality man page.
Do we know if openbsd is one of the blessed 50 glasswing partners?
BSDs are interesting projects. As I understand it there's a broad difference of them all doing things reasonably well but a) Free is general-purpose, b) Net is especially portable/many architecture and Open is security focused
OpenBSD's primary purpose is to create artwork (https://www.openbsd.org/artwork.html), releasing an OS is a side project.
That's 9front where CSP, GeFS and the like are futuristic artwork, kinda like modern DaVinci. We are not ready yet.
9fronts site will always be one of my favorite place on the net. I don't like plan9 (architecturally it is amazing, I just am to bigoted to stay sane on its userland) but the humor is so my style of humor
Based on the CD covers I used v2.3 and v2.4. That's been a while. I might still have the CD sets somewhere out in storage with other legacy stuff.
FreeBSD is mainly server focused. There's been work on the desktop recently, but it isn't what FreeBSD devs are paid to focus on. To be fair to the people paying them, it's a damn good server OS.
Also, check out DragonflyBSD. It has a really nice filesystem and Dillon does good work
FreeBSD is focused on making a good, general purpose operating system. It just happens to be very good at being a server. It's also very good at being a desktop.
Subpar wifi performance compared to Linux(perhaps better now?) subpar bluetooth, etc, etc, hardly makes it a good desktop OS.
Passable yes, if you love it, but let's be realistic.
I love FreeBSD btw.
DragonflyBSD is a beautifully well done OS.
Especially their SMP model. Shame they didn't pick traction.
I have used OpenBSD as a desktop for 7 years. Though my usage and the machine were minimal. But I thoroughly liked it. I want to go back to it. One good thing is that if your hardware has some problems or about to have problems then installing OpenBSD will make your computer kernel panic. So I use it as a diagnosing tool for my hardware
> So I use it as a diagnosing tool for my hardware
Same, it's particularly good for troubleshooting older hardware too since most bog standard x86 parts are well supported.
If I have a random ISA/PCI/AGP/PCIe card that OpenBSD can't see or properly initialize, it's probably an issue with the card.
I always wanted to get into bsd, especially openbsd. I like the idea of a more cohesive os.
But I don't really know what to use it for to get started. My desktop runs linux with steam for games. My AI server needs rocm drivers so ubuntu-server. My vps runs debian, maybe that one, but there is no DO image for BSD. Open for ideas..
OpenBSD for the layer where you need the highest security. We use it for hosting our Postgres clusters. You could easily use it for your VPS. There is a learning curve. But if you’re already comfortable with Linux you’ll pick it up in a few hours.
FreeBSD would work well for your purposes, it has a really good hypervisor and linux abi compatibility
I doubt it.
I am a diehard FreeBSD fan and I used it on my laptop for 20+ years, and dualbooted it for windows only for gaming.
I tried my best to get gaming going, even running Arch in a jail, but it's not great for gaming purposes. I was even virtualizing OpenBSD to use PCI passthrough for better wifi...
Today I am using Arch Linux instead of my dual boot setup. Is it perfect? Nope, but at least I can play Age of Empires 2.
I still use FreeBSD on my servers, obviously. FreeBSD is great, but on the desktop, and especially on the laptop, there are some warts.
The main differences between OpenBSD, FreeBSD, NetBSD and DragonFly BSD
https://unixdigest.com/articles/the-main-differences-between...
Time for an upgrade :)
Cannot edit, again the easiest upgrade of an OS, I did kitchen chores during the upgrade. The network was a bit slow, but got my work done during the upgrade :)
ang benchmarks against state of the art?
It depends. You can expect a 5 to 15% performance hit depending on the task. In OpenBSD, security comes first and performance comes second.
Congrats on another successful release, OpenBSD team! Happy user since the 4.x days.
i use it and its secure
[flagged]
I wonder why they didn‘t spend 20 minutes to make that web page work better with smartphones.
Works fine on my phone. Maybe it's you.
On my phone there is text to the right of the image, forcing horizontal scrolling
Oh god, the horror!