systemd: A Quick Recap
Historically, the startup sequence in a Linux system was a replica of the initialization system that was introduced with System V Unix (SysV). The SysV init system adhered to the Unix philosophy. When people refer to the Unix philosophy, they usually reduce it to the well-known soundbite “Do one thing, and do it well.” And that thing was to start as the first process and then start other processes. It also culled zombies now and then.
SysV init did its job well enough, but it didn’t do it too efficiently. It started processes serially, one after the other. There was no parallelism. The design bottle-necked the throughput. This was more or less masked by the speed gains of modern hardware, and it’s not as if booting a Linux computer took an interminable age. But yes, technically, it could have been made more efficient.
As with everything else in Linux, the users had a choice. Alternatives were available. Competent users could configure their Linux computer to use a different init system, one that started processes in parallel and worked the way they liked.
Some of the options were:
Upstart: This was an initiative developed by Canonical that went on to be adopted by the Red Hat family of distributions, including Centos and Fedora. Upstart is no longer in development. runit: This is an independent, cross-platform project that runs on the FreeBSD and other BSD derivatives as well as on macOS, Solaris, and Linux systems. It has been adopted as either the default init system or one of the install-time options on several Linux distributions. s6-Linux-init: s6 is a replacement for SysV init that tries to address the serial nature of SysV init and remain true to the Unix philosophy.
systemd is another replacement for SysV init, but it includes a whole lot more. It has modules that manage physical devices, user logins, network name resolution, and much more—it is made up of more than 70 binaries and over 1.4 million lines of code. By comparison, SysV init for Arch Linux amounts to less than 2,000 lines of code. Clearly, systemd has well and truly abandoned the Unix philosophy. And not only that, it commits the further heresy of completely ignoring the Portable Operating System Interface (POSIX) standard.
The systemd arguments are some of the most heated I’ve ever witnessed in an open-source community. (And that’s saying something.) The equally vociferous pro-systemd and no-systemd camps aren’t the only people involved, of course. I speak to a lot of people who don’t even know that systemd is a thing as well as plenty of others who have heard of it but don’t know enough details to form an opinion one way or the other. Frankly, they don’t care. They just want stuff to work.
If you’re unsure whether you’re on a systemd-based distribution, run the ps command on process ID 1.
If you see “systemd” in the response, then clearly, you’re using systemd. If it says something else—typically “init”—then you’re not.
RELATED: Why Linux’s systemd Is Still Divisive After All These Years
Philosophy, Architecture, and Engineering Quality
Different people object to systemd for different reasons. For some, it’s the disregard for the traditional Unix philosophy. While it isn’t an obligatory dogma, it is the “Unix way.” And it’s a way that has stood the test of time: Small utilities that can be piped together so that their output becomes the input of the next process in the pipeline is a core part of what gives Linux its feel and character. It’s what makes it particularly suitable for quickly cobbling together creative solutions for one-off or short-lived requirements.
Others queried the design decisions behind systemd, the “software architecture.” Why include all of that functionality that has nothing to do with booting a system? If those other elements needed updating or improving, do just that. But why integrate the whole lot into one massive, interlinked suite of applications?
Concerns have been raised about the systemd developers’ cavalier attitude toward bug fixes in general, and toward Common Vulnerabilities and Exposures in particular. The more lines of code you have, the more bugs you need to deal with. When those bugs are security-related and have their own CVE number allocated to them, then you needed to deal with them yesterday.
Whatever the reason or reasons behind your wanting to leave a systemd-based Linux distribution, the question is, where do you go next? Perhaps you want to try something completely new. You might look forward to learning the ins and outs of a new distribution. On the other hand, you might have neither the time nor the appetite for yet another learning curve. You want to get back up and running as fast as possible on a system that feels as familiar as it can.
The Debian Family: Devuan
If you use Debian or one of the myriad Debian-derivatives like Ubuntu and its entire tribe of relatives, it makes sense for you to check out Devuan. Devuan is a fork of Debian, so almost everything will be familiar. The default shell is Bash and the package manager is apt. Devuan was forked from Debian in 2014. It’s solid and stable and has a thriving community.
If you prefer GNOME as your desktop environment, you’ll have to do a bit of extra work. GNOME isn’t offered as a desktop choice during the installation. MATE, Cinnamon, XFCE, and others are available, but GNOME will have to be manually installed once you’ve got your system up and running.
GNOME has some dependencies on systemd components, namely, the udev hardware device manager and the logind login manager. Replacements for these have been created by the Gentoo Linux developers.
eudev and elogind allow applications with hard dependencies on systemd to operate as though systemd were installed. Anti-systemd purists object to that, too, arguing that pandering to software that coded in hard dependencies to systemd is almost as bad as running systemd.
The choices of init system on Devuan are SysV init or OpenRC.
The Arch Family: Artix Linux
Arch and Manjaro users might want to take Artix Linux for a spin. Artix is a fork of Arch that builds upon the Arch-OpenRC project. Its first release came in 2017.
The Arch Wiki contains instructions on replacing systemd with OpenRC, but it’s not officially supported. Likewise, since OpenRC support was dropped from Manjaro, there’s no Manjaro-derived distribution that’s systemd-free.
So if you want to stay in the Arch-universe, you need to choose an Arch-based fork like Artix that uses a different init system. Artix certainly delivers on that front. During the installation process, you choose one of three different init systems. The choices are OpenRC, runit, and s6.
All of the expected desktop flavors are available, such as Cinnamon, MATE, XFCE, and more. There are also versions in testing that support GNOME and the i3 tiling window manager.
The package manager is pacman. Of course, you can use that to install pamac, yay, or any of the other Arch User Repository (AUR) helpers. The default shell is Bash.
It’s everything you like about Arch without systemd.
Red Hat and Fedora: PCLinuxOS
The systemd project is a Red Hat initiative. The main systemd developers are Red Hat employees. It seems that to many in the Linux world, anything that comes out of the “corporate” Linux camps—Red Hat, Oracle, Intel, Canonical, for example—must automatically be distrusted.
systemd has been described as—among other things—nothing more than a plot by Red Hat to shape Linux into something that suits their embedded operating system needs. If Red Hat needed a distribution tailored to embedded systems, it would be easier by far to just create one. You don’t need to convince Arch, Ubuntu, and OpenSUSE to follow suit.
Of course, with Red Hat being the whole reason systemd exists, you’re not going to find a Red Hat derivative without systemd. So whatever you move to is going to feel new and different. But if you at least want to stick with a distribution that uses the Red Hat Package Manager (RPM), you should review PCLinuxOS.
The PCLinuxOS project started in 2003 as a fork of now-defunct Mandrake Linux just before Mandrake became Mandriva. The first release of PCLinuxOS appeared in 2007, so it predates systemd by a long way.
While PCLinuxOS does use “.rpm” files, it manipulates them using its own package management software, apt-rpm. This is modeled after the apt-get command from the Debian world. A modified version of synaptic is also provided that works with “.rpm” files instead of “.deb” files.
PCLinuxOS uses SysV init and provides a choice of Plasma, MATE, and XFCE desktop environments during the installation. There are a few “community remaster” editions that provide other desktop environments, including GNOME. The default shell is Bash.
Fire up Some VMs
The best—and only way, really—to see whether you are going to get along with a Linux distribution is to try it out. The easiest way to do that is in a virtual machine. It leaves your current Linux installation untouched. You can install and try out as many Linux distributions as you like until you find the one you think you’d like to try. VirtualBox is perfect for this.
When you’re ready to install your new distribution, make several backups of your current installation and then—and only then—install your new Linux.
RELATED: Beginner Geek: How to Create and Use Virtual Machines
