BSDs are very tightly integrated. The entire OS is very consistent and 'correct', down to the tiny and pedantic details like putting things under /usr that are usually installed in /bin, because that's the way it's supposed to be. (Ex. `/usr/local/bin/bash`)
Think of it like reading Wikipedia, no matter which page you read it seems like it was written by the same person. That's the kind of consistency that OpenBSD intends to create.
The base shell, ksh, is at /bin/ksh.
You probably know that but I just felt like being pedantic this morning :).
The MirBSD Korn Shell also descended from pdksh, and it can be found here:
http://www.mirbsd.org/mksh.htm
I don't know about the feature differences and code quality between these two; they both implement most of ksh88, and a small amount of ksh93.
I prefer mksh when I need something more than a POSIX shell.
It's an interesting idea, and while I feel bash is absolutely 'good enough' to be part of the base system, I wouldn't want zsh or fish part of my base system - so it's then a matter of opinion whose shell is bloat and whose is essential. So I respect their decision to not include bash in the base image - it's meant to be uncompromisingly lean and simple.
$ ls -l /bin/bash /bin/dash /bin/mksh
-rwxr-xr-x. 1 root root 964536 Nov 22 2019 /bin/bash
-rwxr-xr-x. 1 root root 113536 Nov 5 2018 /bin/dash
-rwxr-xr-x. 1 root root 296192 Jan 27 2018 /bin/mksh
https://www.irif.fr/_media/rencontres/pps2018/regis-gianas.p...
I would say that mksh implements 80% of bash functionality in much less space, and closely follows ksh88; mksh is also licensed such that Android uses it as /bin/sh.
Apple has switched from bash to zsh. I don't know the motivations for this, but preferences for shells wax and wane. BSD doesn't include bash (in base) more because of license than code quality.
POSIX seems to be all that we can agree on, but I do wish that standard could grow; it's stuck in the '70s.
GPLv3 vs BSD or MIT license. I lived zsh anyway, switched some of my BSD shells to it afterwards.
I don't like the fact that you have no way to clear the history buffer if you've accidentally dropped a password at the prompt. Bash has history -c. I don't have shared history enabled, you could unset that and it'll stop segregating.
Anyway, zsh is a lot more versatile and familiar than tcsh for instance, so it's almost always my go to shell on FreeBSD as /bin/sh is quite limited, but also miles ahead of the Debian shell regarding features.
Don't get me wrong, I was a BSD user for many years (FreeBSD 3.5-5.0) but I don't think that's enough reason to switch.
I am still running ubuntu on laptop and will switch when the next install is a thing, but I am running freebsd on server for years now and while i tremble on each update for the laptop, I dont for freebsd, even when updating from 12.x to 13.x.
Based on years of experience on both operating systems. I was surprised only once when freebsd made change where the base network settings weren't by default copied into fibs (you wont encounter this... probably ever) and even then I needed an hour to figure what the change was.
On the other side, I no longer count the nasty surprises the linux distributions played on me (like /etc/resolv.conf being overwritten by systemd resolv, just as trivial change). My laptop is unbootable for a year as they messed something regarding the order of zpool import (bpool being imported before rpool - probably a race condition) so i have to import it manually or it doesnt boot, while I have freebsd zfs root for ~10 years and it never failed me.
Details like that made me insecure about linux. And on the other side, made me highly secure about freebsd.
I think that (again, this is subjective, speaking only for myself)...
I... trust... BSD... guys. Based on experience.
I... dont trust linux... distributions. Based on experience.
But it might just be me.
Not sure the teething process has finished there, but I share the sentiment.
What bothers me that the old way is still there (/etc/resolv.conf) while it is being generated by systemd. I can accept the change where the dns information is stored. Fine, it is no longer the same file, I dont care. While on the other side, if I get parallel mechanism, that is keeping the old, this is really an annoyance. That is hard to identify.
The ZFS has nothing to do with systemd and I havent even touched stuff like jails/lxc, byhve/kvm, memory consumption, quality of code,... as I have said it, it is subjective and it is about trust into operating system. Linux distributions dont have it. They blew it just too many times. BSD didnt.
It is hard to be objective there, just try the BSD. And please do report your findings.
If it doesn't sound compelling to you, that's okay too, Linux is great. But I do think focusing on the consistency of design really is the best high-level summary of the difference between Linux and OpenBSD.
Am I actually wrong about that? Is there some declarative configuration system I should be using, which I've simply never heard of?
I wouldn't be entirely surprised if OpenBSD works too, I might spin up a VM and see...
[0] https://github.com/NixOS/nix/issues/3280
I’d be really interested in seeing a variant on top of openbsd that has a comparable declarative layer. If anyone knows of such projects, please share!
In the BSD context, consistancy is that human effort has been put in to get the userspace to look similar. Similar behavior of command line tools, similar documentation, similar configuration, etc.
It looks like you're talking about consistancy of packages across installs, which is a totally different issue.
I'm less familiar with OpenBSD but it is similar in terms of prioritising being a cohesive operating system and docs. Some design choices the team have made for reasons such as security make the system feel sluggish by modern standards, even compared to other BSDs. You might get a lot of mileage out of it if you enjoy old school C programming and reading the source code for coreutils libraries.
This is one of the areas where OpenBSD really shines. Their documentation is really good. FreeBSD is also quite good, but I've been consistently impressed with OpenBSD's docs since 2.5.
Linux distros can't reach the same level of quality due to being less cohesive at the base, though they do make up for it with quantity. You can search for most Linux issues and find an answer.
This speaks to the need for non-coders taking part in open-source projects.
Unfortunately, we don't live in an ideal world, so I rarely get to spin up OpenBSD outside of that due to a number of reasons like a lack of filesystems for interoperability (USB media) and firmware drivers (got to be specific in the hardware you buy for it).
For me the coolest thing about OpenBSD is it’s the simplest OS that is still of practical use (i.e., not counting ones that are purely for research or education). So if you’re curious about how any part of the system works, it’s easy to just dive into /usr/src and figure it out. It’s also entirely configured via simple text files rather than some opaque systemd monstrosity.
https://wiki.archlinux.org/title/systemd-networkd#network_fi...
But simple i would not call it...compared to bsd ;)
The vast majority of users control wpa_supplicant indirectly through NetworkManager, so it's not widely known that it can be configured using simple text files. But it can! On Arch linux, the default config file location (for network card wlan0) is: /etc/wpa_supplicant/wpa_supplicant-wlan0.conf.
iwd is similarly straightforward to configure using text files. Using the CLI front-end is typically a nicer experience, since you get to pick the SSID from scan results and you get quick feedback if you mess up the password. But if you want to do it manually, just create one file per wifi network (containing SSID, password, etc) in /var/lib/iwd/.
I tried finding similarly named files, to no avail. Knowing the notorious ADHD of the systemd developership, I wouldn't be surprised if this file is moved, renamed, and uses a different format every six months.
http://manpages.ubuntu.com/manpages/focal/man5/systemd.netwo...
or
find / -name '*.network'
But yeah, BSD's would have them at one place -> /etc ...linux-distro standardization is a terrible mess.
EG Debian's systemd fork puts it in /lib/systemd/network/ (and lots of other network files in /usr/lib/systemd/network/).
/etc/apt/apt.conf.d/
Once you figure out how to set it up then the audio just works. That is a killer feature compared to the situation I had to deal with when I was doing Debian on the desktop.
One area to consider as a happy Debian desktop user is using OpenBSD as a router OS. PC Engines (I have no affiliation to them) makes a very nice router called "Alix" and OpenBSD works well on it. Previously, people were installing it on Soekris routers before they went out of business.
OpenBSD's firewall pf is by far my favorite, and it and OpenBSD have a lot of nice networking features and tools to tinker with. It's free of blobs (in the default install), free of known bugs (in the default install--but generally your router will work well with only the default install), and configured to be reasonably secure by default. The documentation is also frequently praised.
How many other modern, full-fledged, well-maintained and open code OSes run in 32 Mb of RAM?
...and I love it! Documentation is generally excellent, readable, and centralized. There are only a dozen or two processes running on a fresh system without much of anything installed, and idle CPU usage is the zeroyist zero I've ever seen for a server OS. The directory structure in `man hier` is actually used, and it feels like the surface area of what I have to learn to be proficient is sooooooooooo much smaller. It's not perfect (home and end keys don't work consistently) but definitely a breath of fresh air.
Plus, many programs (ezjail, for example) integrate tightly with ZFS, which is also awesome. I know linux finally got quality ZFS support but BSD (along with solaris) are OG
Plus, now I am learning a great deal about how MacOS is built.
Funny enough, I have a DJ controller (Pioneer XDJ-XZ) that uses BSD for its operating system. So it seems to be a great embedded audio OS as well!
If you want to use it on the desktop, you can use it for basic surfing or 90s video games. I’m using it for fun mainly. There is no jails / docker / virtualbox so I don’t use it for coding.
OpenBSD isn’t really a desktop OS, desktop users typically use FreeBSD because there are many more packages. FreeBSD is a completely different OS.
With recent versions of chrome/firefox and 3d acceleration on amd/intel graphics, you're not limited to "basic surfing".
The only reason I can think of that you would say that is that perhaps you do e.g. have an NVIDIA card (why...) and thus you're stuck with no accelerated graphics.
(Having said that, my needs might be atypical.)
Edit/ps: last I knew, it had something like 10_000 binary packages available, in addition to the base system.
Why? You have PPSSPP, Dolphin, maybe some current-gen emulators, and lots of sourc ports. And fnaify for Mono games.
1. ZFS -- by far and away the best filesystem there is. (A hella partisan take but try it out and you'll likely fall in love like the rest of us did)
2. The handbook. The handbook is gold. It's up there with some of the best documentation available.
3. Less fragmentation. The BSDs have 3 main derivatives: NetBSD, OpenBSD, and FreeBSD. (There are others but these are the main)
4. If you like LXD then you'll love Jails.
5. The BSD license. (If being the most free means something to you. I kind of like it but maybe this isn't a selling point.)
6. Can be rolling or used in an LTS fashion. It's rather easy to track -current all the time or just stick with a stable release and do periodic binary package updates.
If you want to use it as a daily driver, you're probably going to run into some headaches. That being said, if you're willing to put in some time, learn a little bit and forgo some software here and there, you certainly *could* use OpenBSD as a daily driver. One really cool thing about OpenBSD is that the OpenBSD devs use the OS as their daily driver.
You'll likely keep hearing about how good the OpenBSD man pages are. I always thought this was a weird thing to mention and make a big deal about. But holy crap, the OpenBSD documentation is amazing. Reading it has definitely made my own documentation at work significantly better.
The downside? There are a couple. The biggest two are that, 1) you're not going to find a lot of the software you might normally use; and 2) The performance is not great and battery life is not very good.
This all depends on the hardware you bring to the table. A random Acer laptop with a questionable ACPI table is probably going to have problems, but a previous-gen Thinkpad X1 should be great because that's what the devs use.
> you're not going to find a lot of the software you might normally use
This really depends on your use cases – I can do most of the development I want on my OpenBSD laptop. But there are some gaps, absolutely.
> The performance is not great and battery life is not very good.
Harder to argue this one. It's getting better release by release, though :)
My only sort of complaint in regards to FreeBSD is actually ZFS. Not that it's not fantastic, or that it shouldn't be there. ZFS does however clearly comes from Solaris, and there have been no effort to make the ZFS command line tools feel more BSD like.
Changing the tooling around ZFS probably isn't a great idea, but coherency has clearly taken a backseat to features in this case.
Right, because ZFS is a foreign piece of software that runs on other operating systems. At that point you are better off keeping those tools coherent with other ZFS implementations. This is a good compromise.
There's a modest amount of precedent for this kind of thing.
0: lvcreate(1M) from HP-UX 11i https://nixdoc.net/man-pages/HP-UX/man1/lvcreate.1m.html
NB: Not on OpenBSD.
What does this refer to in this context?
If you install everything from sources directly, or directly from upstream vendors, you may get inconsistencies, but if you install everything from your Linux distribution, you should get reasonable consistency, just as if you install everything from your BSD distribution.
ps: another instance, albeit not a BSD strength either, would be data format, every output is different, I, like a few people too wanted some json as pivot representation to cut the thousands of papercuts, that kind of uniformity is what I expect from "system"
ps --libxo json
Are you a software engineer or CS student? If so, I'd say that OpenBSD really shines in code simplicity, clarity, and consistency. This is also a matter of taste. What drew me in initially was the quality and consistency of the kernel source code, consistent high standards in documentation, and the design of system interfaces and libraries.
I like being able to answer my own questions and I find that easier in OpenBSD than in Linux. Sometimes I sit for hours and simply flip back and forth between documentation and code exploring how things work. I feel that this level of consistency and availability of information within the system feed creative urges on my part.
I like to write code and I feel like I have an easier time doing that in OpenBSD than Linux (again, a matter of tastes.) This is in large part because my workflow tends to happen at the terminal.
I would be surprised to find that VSCode, Slack, Discord, and other electron-y applications can be made to work in OpenBSD at all... maybe they do, but I've never felt the need to try, so if they don't I'm fine with that.
I think OpenBSD is well adapted to a specific kind of user and a specific kind of problems. If you're paranoid, or a developer, or just like the terminal window, or prefer design consistency over broad compatibility and feature variety, you might find that you really enjoy using OpenBSD.
By all means, give it a spin if for no other reason than to learn about a thing that's out there that a bunch of people enjoy.
If OpenBSD is not for you, that's okay too. I don't think that the user base, developers, or community have ever been looking run campaigns aimed at growing the popularity of the system. For me that's a good thing, the developers seem less prone to chasing the next thing that will expand their share in a market, and are more focused on making a thing they want to use - which translates well for me. YMMV.
But if you want to try out something else, clap your hand and start installing, why?