▲ 170 points
back
98 comments
Why isn't OpenBSD more widely used? I only know what I read about it, but:
* If I was building a system where UI and broad hardware and software compatibility weren't an issue (for example, if I were building an appliance or IoT device), an exceptionally secure, stable, reliable, open, well-maintained and well-documented OS would be wonderful.
* If I was building a Unix server with those specs, why not?
* Why aren't Google's, Amazon's, Yahoo's, etc. server farms running on OpenBSD? How about iOS? (Android needs broad hardware compatibility.) Are there essential power or system features that Linux or FreeBSD has and OpenBSD lacks?
As it's not that widely used, I suspect there are considerations or problems I'm overlooking, or maybe the advantages aren't as large as I think. It's hard to believe it's all politics or personality conflicts.
I've been deploying OpenBSD in production since the 2.x days (late 90's, an example machine was a recycled 486 with a PCI and ISA 10Mbit/s ethernet cards).
While it's possible to use OpenBSD as a general purpose server or desktop, that's not where it's strength lies.
It tends to excel as a firewall or router for the under 1Gbit/s crowd that has Unix sysadmin experience - basically, appliance applications where it would function in the same role as a Cisco or Juniper router device.
OpenBSD's leadership has a goal of pushing the security envelope, and force positive change on the rest of the Unix ecosystem, which it's succeeded in doing in many ways.
OpenBSD's leadership focuses on clean and correct code, not necessarily on security. Of course, that leads to security though.
I've used it as my main work desktop for years.
What problem does pf have after 1Gbit/s?
From my usage:
* There is no supported upgrade path from stable release to stable release.
* If you want regular updates to to packages, you need to be running current.
* It has much better driver and power management support than FreeBSD, but not as good as Linux, and is painfully slow in some contexts due to the various areas where technology is lagging: - SMP - Filesystems
* They've done the work to make the latest version of Gnome Shell run, but it doesn't perform well, and is not close to the experience on Linux with identical hardware.
You can upgrade from -stable to next -release, then to -stable, ive done it for years.
https://stable.mtier.org/ offers package and base binary updates for the present release.
The popular perception is that they build it for themselves with what they want in an OS and don't give a shit otherwise. Hence, a significant gap between what most want and what it is. It's mostly a difference in focus and philosophy that won't win a popularity contest.
There are technical limitations as others have noted. The attitude and focus, though, I think is what kept OpenBSD in their own niche.
Indeed, OpenBSD is great at what it does and like Slackware on the Linux side, it isn't for everyone but it certainly is awesome in its own right.
The only technical limitation I've run into as far as using it as a daily driver OS, is that it can be a bit slow even on very fast hardware. It's simply not optimized for desktop use, though it is certainly usable with a few tweaks. It's great for older hardware too, where the speed issue is relative. In fact, I've found it to be a perfect fit for a couple of old laptops in my collection.
It has many technical limitations that I'm aware of. Large TCB, less fault-tolerance, supports less COTS hardware than Linux, less automation software, less multicore, desktop as you mentioned, weaker in virtualization, no mandatory controls on apps, less integration with cutting-edge security tech (eg CheriBSD, SoftBound)... could be more but that's off top of head.
Harder to say whether it's easier to bring OpenBSD to where competition is on these or to bring competition's code to where OpenBSD is, esp as some safety/security tech makes that less relevant. Hard to say...
Regardless, it's a high-quality UNIX that's worth having around. I'm glad to see them improving in areas where it's weaker while not throwing away strengths like some projects would.
> In fact, I've found it to be a perfect fit for a couple of old laptops in my collection.
I recently inherited an old-ish laptop (I don't know the exact year it was built, but it has a Windows Vista sticker on it, so 2007-2009, I guess) and decided to install OpenBSD on it, mainly because I have always wanted to give it a try on real hardware as opposed to a VM.
I was pleasantly surprised to find that all the pieces I care about (sound, video, wifi, ethernet, ...) Just Worked(tm). That was nice. More heavyweight applications like Firefox or Clementine slow the system down substantially, but otherwise it runs nicely.
If only the other UNIXes (commercial or free) valued the code correctness and safety as they do. :)
I agree. Especially FreeBSD as it kicks ass in terms of features and general stability. I think them pausing for a week out of every month or even a few days to audit plenty of critical code & do bugfixes wouldn't have set them behind much. Maybe incorporate more mitigation tech out of OpenBSD, grsecurity, etc while they're at it.
Matter of fact, I can prove it with an example [1] that predates OpenBSD's approach while succeeding in market at least while under good management (sighs). Used a combo of good design, OS features, and code quality to achieve reliability most still haven't beaten. Coding approach, which I'm focusing on here, was to alternate between developing features and fixing bugs with tests (esp regression) run on weekends while developers were off. One week build stuff, tests on weekend, one week fixing by priority, rinse, repeat. That simple. OpenBSD took it further with security focus and systematic audits but this basic method produced robust and marketable code. So, what's other commercial players' excuse? ;)
[1] http://www.itec.suny.edu/scsys/vms/ovmsdoc073/ovms_archived/...
> a significant gap between what most want and what it is
I've heard this, but what exactly is missing? Do you mean features such as a hypervisor?
Mentioned a few here:
> Why isn't OpenBSD more widely used?
For many of the scenarios you listed, it really boils down to peer pressure.
People who make decisions know that Linux is Good (TM). Convincing them that there is a better alternative for <this particular project> requires them to grasp technical concepts that they simply don't grasp.
And then you have a lot of programmers who know that <this operating they used> is Good (TM). Convincing them that there is a better alternative for <this particular project> requires them to have some broader, often theoretical understanding understanding of things, so that they can compare approaches and judge which one is better for a particular task. A lot of them don't have it; it goes against their belief that there is an operating system that is Good (TM). In fact, they'll go to incredible lengths to ensure that any operating system is like their Good (TM) operating system.
As far as IoT goes, though, hardware and software compatibility is always a problem. Most of them are built on tightly-closed SoCs. You're stuck with whatever the manufacturer wants to support, and that's usually Linux. I guess that partly boils down to the fact that, back when manufacturers started looking into this free operating systems niche, fitting Linux in 4 MB was a lot easier than fitting any BSD. But at the moment, why they'd jump (often imperfectly) through GPL's hooks is beyond me.
> It's hard to believe it's all politics or personality conflicts.
You poor soul :-).
> As far as IoT goes, though, hardware and software compatibility is always a problem. Most of them are built on tightly-closed SoCs. You're stuck with whatever the manufacturer wants to support
Aren't most IoT products custom built and therefore the designer chooses the specs? I know that choice is limited to realistic availability, but some hardware that runs Linux also can run OpenBSD - I would guess that applies to IoT too, but maybe not ...
Why are you typing "(TM)" after "Good"? I've seen other examples of this. Phrases like "A Good Thing! (TM)" or "Good (TM) Distribution". What does it mean?
OpenBSD is lagging behind in terms of "power features." I believe there is no ZFS, no D-trace (or any similar probe-based kernel trace tools), and that SMP performance is not as good as FreeBSD or Linux.
There is no journaling filesystem of any kind. BSD Fast File System (FFS) is what you get. fsck can take a while if your systems goes down hard.u
I would think Java is also a stopper, the JVM is pretty big on server side(linux) stuff and the BSDs are second class citizens in this regard.
Performance is the power feature that's missing imho.
Just go bench any amount of disk I/O or memory based benchmarks.
It's sort of reasonable to find sysadmins who really understand Linux and its intricacies and how to deliver performant and reliable services on top of it.
People with similar command of less popular OSes are even harder to come by.
I disagree, in my experience as a OS engineering manager it is both cheaper and more effective to hire BSD people. There are a lot _more_ mediocre Linux people, probably even in smaller cities, but the really good ones are highly contested and you have a hard time getting them. Sweet spot is to go remote with BSD people.
To hazard a guess, in no particular order:
* proprietary software. Yes, sometimes you need to run it. It's built for Linux but not for OpenBSD.
* hardware support. OpenBSD is better than it used to be, but it's still not as good as Linux.
* apt/dpkg. There's just so, so much more prepackaged software available on Linux. (I miss Debian/kFreeBSD...)
But primarily, I think, it's solely due to Linux network effects --- people learn Linux because Linux is everywhere so people learn Linux. There's just more people and more knowledge around. Which means that if you're porting an OS to a new platform, you go with Linux because you know that the skills are available, and probably a lot of the functionality is already there, and there's a bunch of different userland stacks that will already just work on it, etc, etc.
GNU/Linux is considerably easier to use for non-professional administrators. Especially well battle-tested distributions like Debian and derivatives.
For example, if you want to deploy a Rails application, you can find working ‘init’ files for Debian & Co. easily. If you use FreeBSD, you have to write your own init files. It’s not hard but might be one or two hours of work for someone familiar with *BSD before you get them to work correctly.
Then you have docker on linux. FreeBSD added docker support in June 2015 and according to their website is not production ready. OpenBSD doesn’t support docker. For small dev teams supporting their products or for bigger teams which work with micro-services docker is heaven-sent. It allows you to run the exact same configuration on the server, out of the box by just mapping a few ports.
Likewise, there are many tutorials, howto’s, etc. which make it trivial to setup a HA-Proxy under Linux. But if you need to setup CARP+HAST under FreeBSD you have to go through the official documentation - which is top quality material - and find your way from there. It’s not a 10-minute copy/paste thing.
Add to that a rather elitist culture e.g. BSD is designed, Linux is grown - roughly translated as ‘we are engineers, you are hackers’ which in many cases is not far from the truth and you have an explosive mixture which renders BSDs obsolete.
That said, I find strange the fact that so many corporations choose to support GNU/Linux over BSD in terms of driver development or funding, given that the BSD license is way more permissive. This was the reason Linux picked-up early on and became way more popular than BSD among hacker, but when corporations jumped-in, they didn’t choose BSD, they went with linux. I am not sure if this was a data-driven decision or it was just a matter of technical people in decision-making positions have a lot more sympathy for Linux than BSD.
At this point in time, GNU/Linux has clearly won the race. However, if someone would ask me to setup a ‘secure’ mail-server, file-server, whatever without specific requirements (e.g. docker, LVM, etc.) I’d probably go with BSD.
> That said, I find strange the fact that so many corporations choose to support GNU/Linux over BSD in terms of driver development or funding, given that the BSD license is way more permissive. This was the reason Linux picked-up early on and became way more popular than BSD among hacker, but when corporations jumped-in, they didn’t choose BSD, they went with linux. I am not sure if this was a data-driven decision or it was just a matter of technical people in decision-making positions have a lot more sympathy for Linux than BSD.
Linux was already showing a bit better momentum by the time corporations starting contributing.
Also I suspect some of it came down to legacy Unix vendors (IBM, HP, SGI, Sun etc) deciding that if they were going to contribute to open source projects, GPL was actually preferable to BSD. IBM didn't want their contributions ending up in Solaris and Sun didn't theirs ending up in AIX etc. Maybe the same with competing hardware vendors and drivers too.
The advantage of not being used as much as something like Linux is you can avoid external pressure to add fad features and bloated crap to the system.
With regard to business's using openbsd, I am currently using openbsd for my private server on Digital Ocean, and have thought it would be a good platform for a small business to use.
Less features than Linux, still written in C with the same Unix security model and thus not fundamentally more secure.
There is of course the advantage of being more obscure and thus less likely to be exploited, but most people probably consider desktop Linux obscure enough and companies usually don't care about such security mitigations.
While I agree 100%, they at least try to review all C code and provide safer APIs instead of the usual ones
For example they clearly state that one should use fgetln() instead of fgets().
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/...
Of course, that won't fix the issues with using C, but the mentality at least is more security oriented.
What we really need is something like Midori reaching production. It would surely cost less money than all the Windows Phone restarts.
I run Linux at work because I have to. I run OpenBSD on my personal servers and deskstops/laptops because I like it.
This is really good news because now I can move my VM host to OpenBSD.
OpenBSD is a clean simple user friendly OS.
Good to see they finally compromised on this. A few more here and there we might see OpenBSD start getting more traction. They can maintain their quality difference if they make the right compromises rather than every compromise. Interesting to see what choices they make from here.
Is this really a compromise?
OpenBSD has happily run as a guest for a long time now, with various virtio drivers being added some time ago. Solutions like virtualbox and xen reach far into the system and are still a no-go on OpenBSD.
vmm on the other hand is a very literal OpenBSD implementation of a hypervisor. Minimal cruft means very little device emulation, virtio support only etc... The code is simple and readable[1], as opposed to other monstrosities.
I would take a punt and guess that the reason OpenBSD hasn't had a hypervisor is that a) all of the current solutions were inappropriate, and b) nobody had the time/effort to implement an appropriate one.
[1] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/...
Well, there's this famous 2007 statement by Theo de Raadt that many took to mean OpenBSD would never, ever play this game: https://marc.info/?l=openbsd-misc&m=119318909016582
I'm going on what an OpenBSD supporter or developer... not sure which... said to me in a prior discussion here. I brought up Theo's rant against x86 virtualization. Others showed up to clarify a bit. One posted a video interview where Theo pretty much said they hadn't cared about that and some other things that the market was big on. However, that they'd finally need to adapt and pay more attention to such stuff, esp virtualization. Now, there's a VMM.
So, given prior conversation, I thought of their recent efforts to do what they were against or not interested in to be a compromise between how they wanted it and what OpenBSD needed for more use in market. The first of hopefully many which might bring more coders and capabilities to the project.
Here's the original announcement, with answers to a few frequent questions.
Make it clean and fast and you'll have a compelling secure host OS for VMs.
One problem that would be good to address (and maybe it is) is making it really hard to dump the memory of a VM. We don't have homomorphic encryption yet, so right now if you dump a VM you own any secrets it holds. So at the very least this should be made as hard as possible on production VM hosts.
What does making it hard for the host to dump vm memory buy you? It seems like if the host wants, there's virtually endless things they can do. iow, you have to trust the host.
Agreed. If you own the host, you win. The point is to make it difficult to own the host from within the VM, not vice-versa.
Things are not insecure or secure. Things are secure to varying degrees; nothing is perfectly so and few things are totally not. (... and anyone who claims anything is totally secure is delusional.)
Making it hard buys you some resistance to less skilled attackers. Since skill tends to obey a power law distribution, this is most attackers. Make it as hard as possible and you get more and more protection from more and more attackers, and so on.
Your average attacker doesn't know enough to bust out x86 assembly language to inject root code into the kernel and dump a VM's RAM. So make it so you have to do this, and you've ruled out your average attacker. The average attacker will only 'dd' the VMs' disks, which if they've encrypted data at rest will not get them the crown jewels. But make it easy to dump VM RAM and you've exponentially increased the damage from the average attacker (due to power law distribution of skill).
right now if you dump a VM you own any secrets it holds
Unrelated to OpenBSD but related to VM security from administrators - https://4sysops.com/archives/shielded-vms-in-windows-server-...
This is not very useful, it is a security policy change. The previous post mentioned homomorphic encryption. This is a method of performing computation on the cipher text. If this were implemented, then you could potentially create VM's where even in the event of a hypervisor compromise, dumping the plaintext memory of guests is not possible.
If you can take a memory dump of the host sytem, you can from that devise the encryption key for the disk encryption with the M$ solution to this issue.
There's Intel SGX which give secure enclaves through hardware, could probably do unreadable VMs.
No, or at least not in the traditional sense. SGX is strictly CPL 3, i.e. user mode. You could plausibly stick a unikernel inside.
homomorphic encryption exists. It's just slow, though it depends on what you consider slow: https://github.com/shaih/HElib
When should we expect this to run on bitrig ?
Has bitrig seen much uptake? Genuinely curious.
I remember reading about it when it was started, but haven't heard much about it lately.
I don't know about the uptake, but I have seen patches making their way back to OpenBSD from BitRig.