More than 10 years since its introduction, systemd can still irritate some Linux users. Turns out I’m not one of them. Although I test distributions without systemd, I will probably still regularly use systemd-based distributions. These are some of the reasons.
SysVInit had to disappear
Out with the old, in with the new
When system first appeared in the early 2010s, many Linux users wondered why a revision of the boot system that Linux had used was necessary.
The old system, System V Init or SysVInit, had its roots in the 1980s. In the 80s, Unix systems were used differently than modern machines. Unix was mainly used on large minicomputers and powerful workstations. SysVInit starts services sequentially, which can increase boot times. Laptops were rare at that time. USB didn’t exist and peripherals were generally only added and removed between boots. The system configuration typically did not change during its runtime. Once the system was up and running, it usually stayed up for a long time, so boot times were not an issue. Hardware changes on shared systems occurred rarely and were also more of a “one-off” experience.
Traditionally, if you added a piece of hardware, even something like an external drive, you had to shut down and reboot the system. SysVInit was also complicated, with shell scripts corresponding to “runlevels”. This approach proved inadequate as Linux became more widespread. With modern machines, you can plug in a USB drive or move between Wi-Fi and wired networks with a laptop. systemd can respond instantly to such “hot-plugged” hardware.
It’s a testament to the strength of the idea of Unix-like operating systems that core components can be replaced as needed.
systemd is here to stay
A better startup system will appear eventually, but not anytime soon
While systemd was first emerging, there was more debate and competition over what would replace it. The debate became so heated that some Linux distribution developers gave up the stress of the constant stream of invective from Linux users.
For better or worse, using a mainstream Linux distribution means using systemd. The documentation will mention it, and if you’re looking for support, if you run into any problems, it will probably involve using the systemctl utility.
Because systemd is so integral to the way modern Linux distributions run, most major distributions are unlikely to replace it unless they have a good reason.
This would not be a far-fetched scenario. If you were using Linux in the 2000s, you might have thought that the SysVInit system would last forever. If you didn’t like it, you can use one of the BSD.
Maybe someone will create a different boot system, one that Linux developers think is better. My money would be on whatever the BSD developers cook up to replace their own old boot system. I imagine it would end something like the release of macOS, which also influenced systemd.
For many Linux distribution developers, systemd seems to be at least a “good enough” option. In many forms of engineering, including software engineering, you have to make trade-offs when designing things for the real world rather than trying to build the absolute best solution.
systemd works for me
It is reliable and intuitive.
One reason I’ll tend to stick with systemd-based distributions is that I’ve never had problems with systemd. The “works for me” answer can be irritating when faced with problems with Linux, but I have no complaints about my own use.
I prefer systemd to the previous method. I was never entirely comfortable with SysVInit, with its need to manage shell scripts and runlevels. I cringed every time I saw documentation on how to enable and disable services, even though it was something I rarely did on desktop systems since most of them were configured with what they needed to run out of the box.
When I need to enable, disable, start or stop services, I simply run a quick systemctl command. That’s all it takes.
As a user who only starts and stops services sometimes, despite the supposed overhead of systemd, I find the systemctl command easy to understand.
I recently installed Arch on a virtual machine. I had to enable some services, since Arch is more hands-on than other Linux distributions. All it took was a few systemctl commands.
If systemd is good enough for Arch Linux…
Confirmation bias? I don’t mind
One thing that finally swayed me in favor of systemd is that Arch Linux had switched to it. Arch already has a reputation for targeting sophisticated Linux users by giving them more control over how their system is configured. You can choose which partition tool and boot loader, as well as the desktop environment, or even install a desktop environment.
when I found an old forum post from one of the developers from 2012, linked from the Arc WikiI studied the case presented by the developer. The developer cited the ability to know everything that was happening with the system, the ability to detect hot-plugged devices, the modularity, security and sandboxing features of systemd, as well as the cross-platform development of the systemd project.
According to Arch Wiki, one of the guiding lights of distribution is “pragmatism”:
Arch is a pragmatic rather than ideological distribution. The principles here are just useful guidelines. Ultimately, design decisions are made on a case-by-case basis through developer consensus. What matters is evidence-based technical analysis and debate, not politics or popular opinion.
Arch Linux has always struck me as a “Unixy” Linux distribution with its focus on text-based configuration and the amount of control it gives users. If the Arch developers could see the merits of systemd despite its supposed “bloat”, I thought it was worth taking a serious look at systemd. Any lingering apprehension towards systemd disappeared. This may seem like an authoritative argument, but the Arch development team has earned my trust thanks to their results.
Process management is a small part of my Linux usage.
I don’t need to get to work
The boot system may be an important part of Linux, but for me, it’s mostly behind the scenes. I rarely interact with it directly outside of the systemctl command.
While it could be that starting programs throughout the day and closing them could be considered process management, for the most part, I think I can count the number of times I’ve interacted directly with systemd to manage processes via systemctl on one hand. On a desktop distribution, it would probably be once or twice.
I check the logs from time to time, as any user should. systemd binary logs have also been controversial, but the diaryctl command it is easy to use. Many of the logs in Ubuntu seem to be mirrored in the /var/log directory, so I can examine them with a normal text editor.
free systemd distributions don’t impress me much
And I have tried many distributions.
The fact that systemd is in the background is one of the reasons why distributions that are promoted as systemd-free Don’t impress me that much. I’ve explored a few recently, like EXEGNU/Linux and Obarún. Distribution creators are free to install or not install whatever they want in their distributions.
When I evaluate distributions for HTG, I try to take the position of an ordinary user, not that of a Linux hacker who has strong opinions for or against systemd. User experience matters more than what’s under the hood.
A distribution will have to go up or down depending on everything else it has. Some distributions offer a unique experience, such as the retro GNU/Linux EXE designs.
Sometimes change is good
While the original System V startup system worked well for many years, changes in the computing world eventually made it obsolete in an increasingly mobile and online world.
There could be some concerns about the size of systemd or the alleged dominance of Linux development by Red Hat and its parent company, IBM.
The world changes, computer hardware changes, and operating system software changes with it. Operating systems have to serve users and run their programs. They have to evolve with what their users do with them. They cannot be museum pieces.
