Title: Why I use OpenBSD

	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.