OpenBSD As A Linux Desktop Replacement
I recently tried out OpenBSD as a possible answer to recent Linux engineering. I thought I’d share my notes here on my results, from a beginner’s and Linux user’s perspective. (I tried FreeBSD briefly before as well.) If you’ve used OpenBSD more extensively on the desktop, your feedback on any of this is welcome too – I’d like to know what you think of my opinions, you being a longer-term user.
OpenBSD is a bit of a leap from Linux – not everything will be familiar, but it is UNIX-style, so some things feel the same. It was my thought that if OpenBSD desktop is ready, it might be worth the investment to go there directly, rather than fighting systemd and such in Linux distros. I’ve liked what I read about some of OpenBSD’s approaches to security. They ship a very simple, locked down, code-reviewed system, to which you add components. They don’t use SELinux or other similar technologies (which I think is wise), so they take a simpler approach. Compared to FreeBSD, which seems to be more open to systemd (you can see FreeBSD lead developers acclimating their users to systemd already, and trying to turn it too into a mobile thing), OpenBSD seems to be rejecting it thus far.
If you’re fairly familiar with setting up Linux systems, you can try out OpenBSD in a day, including reading some docs. The FAQ is a good place to start – seems to be their install manual. While OpenBSD is well-known for being meticulously documented, I find introductory documentation and explanation lacking. Simply put, it’s a bit difficult to figure out what the hell they’re talking about at times, because they make so many assumptions. There’s also a horrible lack of hits on Google for questions/problems compared to Linux. With the forums rumored to be intolerant of entry-level quesions, I suspect you’ll be largely on your own. Getting a decent book on OpenBSD is probably a good idea if you plan to use it seriously.
Yet the install is fairly simple. The boot CD just asks a few questions, and to most you can press Enter for the default. The tricky part is partitioning. The OpenBSD partition is split into slices with something called disklabel. So they basically use partitions within partitions. On my first install, when I told it not to use the whole disk, but to let me edit the MBR (partition table), it ran fdisk. I set a 10G partition to type A6 (OpenBSD), set the boot flag, and updated the MBR. So far so good.
Next it layed out the disklabel setup for that partition, breaking the partition into 5 or 6 slices with mount points (/, /tmp, /usr, etc). But later when I tried to install a few X apps, I ran out of space in /usr. Clearly their default partitioning for a smaller space is not well done. So I did the installation over, and chose a custom layout. It put me into disklabel, where I deleted all the slices except the root filesystem (/). (Also be careful not to delete ALL the slices, because some seem to refer to other partitions on the drive – just delete the ones with mount points.) Saving changes, it continued with the installation okay. This way the whole root filesystem is in one slice. It’s okay to do this (slightly less secure as they explain in the FAQ), and later you can repartition if you know how you want the space shared.
So basically the partitioning requires a little adjustment and reading, and use of fdisk and disklabel. They could improve this with a few simple typical setups – how many variations are there really for most users? Either you do a whole disk install, or just want it on a smaller partition. Also, I updated the MBR boot code in fdisk, making the system boot directly into OpenBSD, but you can also tell grub to boot a BSD partition.
Next it boots into an xdm login (if you told it to boot into X in the install). I pressed Ctrl-Alt-F1 to get a root prompt, create a user, and add some software.
The package manager is easy and simple, and they recommend using packages (versus ports, which create packages from source, similar to gentoo or Arch). However, they have an odd release method, which I’m not sure works well, and which their FAQ explains poorly.
The ‘release’ branch is what they release every six months, and is never updated otherwise. It quickly accumulates security advisories. These are corrected in a ‘stable’ repo. But the ‘stable’ repo is only available as source (ports), not binary packages. People generally recommend that you start with ‘release’ and manually patch bugs as needed. They claim you learn the system better doing this.
So there’s no packages branch comparable to Debian’s stable, where security fixes are added. That is clearly something missing, as evidenced by the fact that a third party now offers pre-built packages for the ‘stable’ branch. The ‘release’ branch is already open to a serious Xorg bug that lets a normal user run arbitrary code as root (Red Hat is doing a great job – and notice how OpenBSD too is susceptible to their ‘bugs’ through Xorg). So you pretty much need to run a manually patched ‘release’ branch, staying attuned to security notices, or run the full ‘stable’, building everything from source (or third party packages).
There’s also a ‘current’ branch, and this is rolling release. It’s packaged in binary ‘snapshots’, similar to Debian unstable. But I didn’t immediately see any instructions on how to switch to using ‘current’ – there seem to be a few manual changes required. Some people do say they use ‘current’, but it’s also considered a more advanced use. You also have to update the whole system, you can’t just update pieces and expect it to work. So using ‘current’ looks more maintenance intensive as well, and may require more experience.
The update/upgrade path seems primitive too – more manual steps required. Generally it all seems geared to servers that want stability while being able to patch minimally.
All of that said, the package/ports system does seem clean and simple, as does OpenBSD overall. Longer-term users seem to like their ability to maintain their system, so I suspect once you get used to it, it works well. It may require more knowledge, but it also doesn’t change much. Overall I’d say it looks usable.
So I installed some packages:
pkg_add openbox dillo geany nano roxterm geeqie gnash gimp \ libreoffice vlc mpv imagemagick htop jhead smplayer file-roller \ gnash claws-mail filezilla pdnsd bash pcmanfm firefox xchat
A few things I couldn’t find in their packages: deluge, gftp, flashplugin-nonfree, and spacefm
Adobe Flash is pretty much unavailable, unless maybe you get into some i386 linux emulation for it. Hard to find answers on how *BSD users handle this, but the preferred methods seem to be to use programs that download videos so you can play them in mplayer, or to use HTML5 on Youtube (see Firefox’s ‘All HTML5’ plugin). Yet while HTML5 works for me in Linux, it just showed a black box in Firefox on OpenBSD. Nor would Gnash work – it locked up Firefox with network errors in stderr. So in my brief attempts I didn’t find any in-browser support for Flash sites.
I also found that Firefox ran more slowly, and programs seemed to start slowly. Overall the system didn’t seem fast. This seems to be a known issue of OpenBSD on the desktop (some attribute it to scheduling).
Another issue I encountered was my laptop hard drive powering down every 1 or 2 seconds. Linux had this problem too, but there is no hdparm or sdparm for *BSD. The closest I found was atactl, and I eventually solved the problem like this:
atactl sd0 apmset 253 # use 127 to 253 for no standby
I didn’t actually try openbox, I just logged into a plain X session and started some programs from xterm. PCManFM did run, but did not show any devices. After inserting a USB stick to try playing a movie in mpv, I realized I didn’t know how to mount the USB stick, or even what its device name would be. So I never got to try that.
As far as a possible port of SpaceFM to *BSD someday, it looks promising. SpaceFM depends on only glib, gtk, and udev (and inotify in the kernel, but I did see gamin on OpenBSD, and SpaceFM can use gamin instead of inotify already). udev code would have to be removed from the build, and there is no HAL either. To show and detect device changes, it might need to do some polling for something like sysfs, not sure. But with SpaceFM’s Device Handlers and overall design, I think it would make an excellent conversion to a BSD file manager. Also, people were saying there is no Brasero, so what will they use to burn, but SpaceFM can be used as a burning app. That and other automation, as well as its few dependencies, makes it a good candidate for a *BSD port.
Hardware seemed to be detected well in OpenBSD – and it has a good reputation for this, in some cases better than FreeBSD. My ATI video seemed okay and required no initial tweaking, though I didn’t see it play any video. (Nvidia is less supported on BSD, from what I read. That’s seems true on Linux too.)
Overall, OpenBSD looks like it’s usable for my purposes, minimally. It doesn’t seem quite ready for full-featured desktop use unless you’re willing to keep things very simple, have more limited web, and limited software choices (but still quite a few – you’ll have a lot of Linux there with you). I also have some speed concerns, but the laptop I tried it on isn’t very fast.
OpenBSD reminds of some of the earlier versions of Linux I tried a few decades ago, before it really became Ubuntu-easy to install and maintain. It’s also similar to Arch Linux, yet with less software and less information available.
I read that many of the OpenBSD developers actually use other OSes for their desktop – even among them it’s not the most popular desktop OS. If true, that also means they don’t optimize it for that (because they simply won’t encounter the issues). Plus it is designed for servers.
I also tried FreeBSD some time ago, and that is similar. My impressions are that somewhat more software is available for FreeBSD, there are more Linux-like forums for discussion, there is more on Google when you have a problem. I think more people are using FreeBSD on the desktop. However, FreeBSD developers also seem to be more accepting of Red Hat’s engineering, Adobe Flash (a security nightmare we’re all better off without, except that they have made it hard to avoid), complex and poorly reviewed things like SELinux, and other questionable choices. OpenBSD on the other hand seems to avoid the Red Hat camp actively and wisely.
Having given OpenBSD that initial try, I have decided that it’s still a candidate, but that it seems a little too primitive on the desktop yet, and that I would be giving up quite a bit without getting much in return, in terms of my needs. It also means learning new BSD filesystem tools, backup tools, porting my file manager, and other differences between BSD and Linux.
So now I’m thinking that a good systemd-free Linux distro may be the more usable and convenient route for now, maybe keeping an eye on OpenBSD development for longer-term. I think my next stop is going to be Gentoo. I tried Gentoo a few years ago, and I liked it overall. The USE flags setup can be a bit much for the newcomer (I wish they would choose some reasonable defaults). I also had a problem with momentary hangs of the whole system, which is really annoying. This appeared to be a possible scheduling issue. Hopefully that won’t recur. I also had problems with my Brother laser printer driver, but I see they have some new ‘overlays’ for similar printers, so maybe that will be improved. (I’ve decided not to make the printer a critical issue.)
I liked what I saw of the Gentoo community in response to systemd, with eudev, etc. They seem to have many genuine contributors, flexibility, and a policy that allows it, so I think that will be a boon in countering some of the upcoming power plays in Linux.
While BSD looks promising, there is a lot of software and work that has gone into Linux, and it seems unfair to have to dump it all just because of things like systemd. Maybe with something like Gentoo’s flexibility it will be possible to move it forward on another track. Gentoo also has good security protocols, so I look forward to trying it out again.
If you’re looking for systemd-free Linux distros, there’s a large list at Without systemd.
UPDATE: Speaking with a few OpenBSD people in email, I can clarify a few things which I didn’t find to be clear in the FAQ. In OpenBSD, the OS is not part of the ports or packages systems, unlike in Gentoo or Arch, for example. The OS is built separately from a CVS tree, manually. Or patched manually. Or, you install or reinstall the system using the install ISO (or manually extract the files). That is also how you switch from release to current – you must reinstall. Software is updated via ports (like Gentoo) or packages (like Arch).
Also, OpenBSD was not as vulnerable to the Xorg bug I mentioned because it doesn’t run Xorg as root! In fact it runs it with even less privs than a normal user. Great work there!
And, according to one person who seemed to know, OpenBSD developers are commited to using OpenBSD on their own desktops, because they want to improve it. FreeBSD is where they tend to not use it as much on their own computers. That’s encouraging to hear.
Overall, I probably gave a more negative impression of OpenBSD than I intended. In general it looks good in many ways, even on the desktop. Probably comparable to Arch or Gentoo in terms of setup and maintenance challenges. I’m still weighing it, and I think it’s worth getting to know.
Sorry, the comment form is closed at this time.