Notes on operating systems I've tried
I've tried and researched a lot of Linux distributions in search of two goals:
1. One to recommend to newcomers to Linux.
2. One I'd want to use myself.
I'm a software idealist - I don't want to use an operating system that isn't the best designed one. Where practicality and design quality conflict, I seek a balance, because I realize practicality is the point of it all, and I'm not an OS dev, but I want to support and encourage good architecture and also I think using it helps me grow wiser about software.
Here are my notes on the ones I've tried or researched. When I say things like "broken install process", I mean that when I tried it, I ran into things that were clearly releng mistakes, such as the installer telling me to run a command that doesn't exist. Take this with a grain of salt as these are one person's experience, often after only a small period of use.
Anything Debian-based (incl. Ubuntu, Mint)
Reputation: stable, user-friendly
Init system: systemd
Tried: Ubuntu years ago, Mint in 2020 summer
- Development headers are in separate packages from corresponding libraries, a huge pain for anyone who does development in C-family languages. (I don't even do development in C-family languages, but the occasional need to compile a program from source is enough to make me abhor this.)
- Packages are often years out of date.
Reputation: fork of Debian that switches out systemd for sysvinit. Everything else from Debian applies.
Tried: 2020 summer
- Broken install process: live environment's README referred me to nonexistent commands. I got it working anyway.
- Apparently supports OpenRC as an init system option now, but not default?
Init system: systemd
Tried: 2020 summer (only on server)
- Separate -devel packages, like Debian.
- Good package manager. Colored output and ability to get more detailed info on uninstalled packages than other package managers allow.
CentOS is derived from Fedora (through Red Hat), so it's much the same except its packages are outdated as hell.
Reputation: DIY for advanced users
Init system: systemd
Reputation: Linux/BSD hybrid
Init system: runit
Tried: 2020 summer, multiple times.
- Uses ZFS in user space to get around the license issues.
- I haven't been able to get Sway working.
- Package manager hell. Just running normal install and uninstall commands produced a broken system that I could not fix.
- Trident exists as a desktop installer.
Reputation: DIY for advanced users, nightmarish install process
Init system: OpenRC (others supported)
Tried: years ago (mentor helped with install); no first-hand recent experience.
- Package manager is written in Python which I don't like (I like Python but not in my package manager)
Init system: sysvinit
Tried: 2021 on desktop, currently use on server
Reputation: secure, lightweight
Init system: OpenRC
- Uses musl libc, which is argued to be better than glibc but means binaries compiled for glibc won't work.
- Packages are split into several sub-packages like *-dev and *-doc
- On desktop, I had a ton of trouble getting dual-booting working with Artix, and couldn't get Alpine to recognize my trackpad or sound.
- Has served me well on server (Linode).
Tried: 2020 summer - present.
Reputation: Arch without systemd.
Init system: choice of OpenRC, runit or s6. I've tried OpenRC and runit.
- Due to the three init system options, packages with service files are separated into variants like `thing-openrc`, `thing-runit`, `thing-s6` and just `thing` which is only the program itself without a service file. This makes it a bit cumbersome to figure out exactly what you need to install, but the service versions pull in the main package as a dependency, so it's not too bad - and in the end I think it's more elegant to have the service files separate from the program itself.
- There are desktop and manual installers. The guide for the manual installation is really unclear about partitioning, but once you know what to do, it works. At least it isn't years out of date.
- Package manager supports colored output and protected packages but they need to be configured. (Same package manager as Arch so I assume this applies there too, but I didn't put it there because I don't know for sure.)
Tried: unknown year - 2020 summer.
Reputation: the go-to BSD.
Init system: BSD init
- Unlike Linux, FreeBSD separates stuff that comes with the base system from user-installed stuff. User-installed stuff goes in `/usr/local`. It seems to be done in the name of safety, but I mildly dislike it because it overemphasizes the arbitrary selection of what's shipped with the distribution.
- More fringe than Linux; lots of things support Linux but not FreeBSD or take manual effort to make work. This was one of the main reasons I started looking into Linux.
- Sound system is OSS instead of ALSA. I've heard positive opinion of OSS, but it unfortunately makes it very difficult to record speaker output.
I now explain my preferences when it comes to init systems.
I don't have much personal experience with systemd. My negativity from it pretty much comes from hearsay, but well-sourced hearsay. Two in particular:
Randy Westlund's critique
This is someone I know and consider pretty reliable, and he's balanced too - not an anti-systemd zealot.
The Suckless critique
I wouldn't consider them a reliable source on this, but they link the systemd patch notes on every criticism for proof. Read some of the list. It's horrifying.
Works well enough, but service files are extremely cumbersome.
Colored output. Service files are concise.
Runit has fewer lines of code than OpenRC, which attracts me, and I also like the way it leverages the filesystem instead of reinventing it. For example, services are "enabled" by symlinking them into a certain directory.
I like a lot of things about runit, but there are two issues I have, might be solvable but I don't know how:
- There is apparently no logging by default? Jeez this is horrible. I have to stop a service and run the command manually to find out why it's failing. And it's not easy to set up either: you apparently need a separate log process that communicates with the main one via a pipe, you can't just say "log to this file".
- There's apparently no way to start a service "one time only". It has to be enabled (set to run automatically at boot) to be run at all.
Legacy standard. I don't know much about it, but the prevailing opinion seems negative.
A few other things I explain about my preferences:
- I do not have a stake in rolling release vs point release.
- I want binary packages so things don't take forever to install.
subscribe via RSS