Title: Why I use OpenBSD | |
Author: Solène | |
Date: 16 November 2020 | |
Tags: openbsd life | |
Description: | |
# Introduction | |
In this article I will share my opinion about things I like in OpenBSD, | |
this may including a short rant about recent open source practices not | |
helping non-linux support. | |
# Features | |
## Privacy | |
There is no telemetry on OpenBSD. It's good for privacy, there is | |
nothing to turn off to disable reporting information because there is | |
no need to. | |
The default system settings will prevent microphone to record sound and | |
the webcam can't be accessed without user consent because the device is | |
root's by default. | |
## Secure firefox / chromium | |
While the security features added (pledge and mainly unveil) to the | |
market dominating web browsers can be cumbersome sometimes, this is | |
really a game changer compared to using them on others operating | |
systems. | |
With those security features enabled (by default) the web browsers are | |
ony able to retrieve files in a few user defined directories like | |
~/Downloads or /tmp/ by default and some others directories required | |
for the browsers to work. | |
This means your ~/.ssh or ~/Documents and everything else can't be read | |
by an exploit in a web browser or a malicious extension. | |
It's possible to replicate this on Linux using AppArmor, but it's | |
absolutely not out of the box and requires a lot of tweaks from the | |
user to get an usable Firefox. I did try, it worked but it requires a | |
very good understanding of the Firefox needs and AppArmor profile | |
syntax to get it to work. | |
## PF firewall | |
With this firewall, I can quickly check the rules of my desktop or | |
server and understand what they are doing. | |
I also use a lot the bandwidth management feature to throttle the | |
bandwidth some programs can use which doesn't provide any rate | |
limiting. This is very important to me. | |
Linux users could use the software such as trickle or wondershaper for | |
this. | |
## It's stable | |
Apart from the use of some funky hardware, OpenBSD has proven me being | |
very stable and reliable. I can easily reach two weeks of uptime on my | |
desktop with a few suspend/resume every day. My servers are running | |
24/7 without incident for years. | |
I rarely go further than two weeks on my workstation because I use the | |
development version -current and I need to upgrade once in a while. | |
## Low maintenance | |
Keeping my OpenBSD up-to-date is very easy. I run syspatch and pkg_add | |
-u twice a day to keep the system up to date. A release every six | |
months requires a bit of work. | |
Basically, upgrading every six months looks like this, except some | |
specific instructions explained in the upgrade guide (database server | |
major upgrade for example): | |
```shell commands with a # for commands as root | |
# sysupgrade | |
[..wait..] | |
# pkg_add -u | |
# reboot | |
``` | |
## Documentation is accurate | |
Setting up an OpenBSD system with full disk encryption is easy. | |
Documentation to create a router with NAT is explained step by step. | |
Every binary or configuration file have their own up-to-date man page. | |
The FAQ, the website and the man pages should contain everything one | |
needs. This represents a lot of information, it may not be easy to find | |
what you need, but it's there. | |
If I had to be without internet for some times, I would prefer an | |
OpenBSD system. The embedded documentation (man pages) should help me | |
to achieve what I want. | |
Consider configuring a router with traffic shaping on OpenBSD and | |
another one with Linux without Internet access. I'd 100% prefer read | |
the PF man page. | |
## Contributing is easy | |
This has been a hot topic recently. I very enjoy the way OpenBSD manage | |
the contributions. I download the sources on my system, anywhere I | |
want, modify it, generate a diff and I send it on the mailing list. All | |
of this can be done from a console with tools I already use (git/cvs) | |
and email. | |
There could be an entry barrier for new contributors: you may feel | |
people replying are not kind with you. **This is not true.** If you | |
sent a diff and received critics (reviews) of your code, this means | |
some people spent time to teach you how to improve your work. I do | |
understand some people may feel it rude, but it's not. | |
This year I modestly contributed to the projects OpenIndiana and NixOS | |
this was the opportunity to compare how contributions are handled. Both | |
those projects use github. The work flow is interesting but | |
understanding it and mastering it is extremely complicated. | |
OpenIndiana official website | |
NixOS official website | |
One has to make a github account, fork the project, create a branch, | |
make the changes for your contribution, commit locally, push on the | |
fork, use the github interface to do a merge request. This is only the | |
short story. On NixOS, my first attempt ended in a pull request | |
involving 6 months of old commits. With good documentation and | |
training, this could be overcome, and I think this method has some | |
advantages like easy continuous integration of the commits and easy | |
review of code, but it's a real entry barrier for new people. | |
## High quality packages | |
My opinion may be biased on this (even more than for the previous | |
items), but I really think OpenBSD packages quality is very high. Most | |
packages should work out of the box with sane defaults. | |
Packages requiring specific instructions have a README file installed | |
with them explaining how to setup the service or the quirks that could | |
happen. | |
Even if we lack some packages due to lack of contributors and time (in | |
addition to some packages relying too much on Linux to be easy to | |
port), major packages are up to date and working very well. | |
I will take the opportunity of this article to publish a complaint | |
toward the general trend in the Open Source. | |
* programs distributed only using flatpak / docker / snap are really | |
Linux friendly but this is hostile to non Linux systems. They often | |
make use of linux-only features and the builds systems are made for the | |
linux distribution methods. | |
* nodeJS programs: they are made out of hundreds or even thousands of | |
libraries often working fragile even on Linux. This is a real pain to | |
get them working on OpenBSD. Some node libraries embed rust programs, | |
some will download a static binary and use it with no fallback solution | |
or will even try to compile source code instead of using that | |
library/binary from the system when installed. | |
* programs using git to build: our build process makes its best to be | |
clean, the dedicated build user **HAS NO NETWORK ACCESS* and won't run | |
those git commands. There are no reasons a build system has to run git | |
to download sources in the middle of the build. | |
I do understand that the three items above exist because it is easy for | |
developers. But if you write software and publish it, that would be | |
very kind of you to think how it works on non-linux systems. Don't | |
hesitate to ask on social medias if someone is willing to build your | |
software on a different platform than yours if you want to improve | |
support. We do love BSD friendly developers who won't reject OpenBSD | |
specifics patches. | |
# What I would like to see improved | |
This is my own opinion and doesn't represent the OpenBSD team members | |
opinions. There are some things I wish OpenBSD could improve there. | |
* Better ARM support | |
* Better performance (gently improving every release) | |
* FFS improvements in regards to reliability (I often get files in | |
lost+found) | |
* Faster pkg_add -u | |
* hardware video decoding/encoding support | |
* better FUSE support and mount cifs/smb support | |
* scaling up the contributions (more contributors and reviewers for | |
ports@) | |
I am aware of all the work required here, and I'm certainly not the | |
person who will improve those. This is not a complain but wishes. | |
Unfortunately, everyone knows OpenBSD features come from hard work and | |
not from wishes submitted to the developers :) | |
When you think how little the team is in comparison to the other majors | |
OS, I really think a good and efficient job is done there. |