jjacky.com

A few years back, as I wanted to switch OS and enter the world of Linux, I needed to pick a distribution (or first, figure out what makes a distribution, what sets one apart from another).

Did some research, downloaded and tried a few ISOs, but quite honestly this wasn't a deciding factor in the end. No, what really helped me make up my mind was doing a bunch of reading, learning the "principles" of a distribution.

And the reason I eventually went with Arch Linux, was what's known to Archers as The Arch Way, which is said to "illustrate the principles and philosophy of Arch Linux."

The Arch Way: the principles and philosophy of Arch Linux

It was what attracted me to Arch, and I certainly haven't regretted it since. I've been pretty pleased with my experience so far, and as one could have expected, thanks to those principles & philosophy, Arch is the perfect distribution for one who wants to learn about his system.

Now I want to talk about certain changes that occurred, and yes, I'll talk about systemd. But let's preface this right now: this isn't about systemd, it is about Arch, and whether the two projects are "compatible."

This will not be about what you think of systemd: whether you like it or not, whether you think it's the greatest thing since sliced bread, or will be the end of GNU/Linux distributions as we know them, doesn't matter.

systemd is what it is, and I believe what it is isn't a good fit for Arch Linux. Plenty has been said about systemd, why it is great, or why it is a move in the wrong direction. My personal opinion is of the later, but I believe this isn't relevant.

The Arch Way mentions simplicity and code-correctness over convenience as some of its core principles, as well as being user-centric instead of user-friendly; And I feel that ideally this wouldn't only apply to how Arch packages software, but also in the choice made in which softwares to package.

This is particularly important for core element of the system, especially if only one will be officially supported. With only one init system to have official support, picking a solution that shares the same principles seems like a good thing.

No questions when you know your system...

Let's say you install a brand new system. One thing that I liked with Arch, is that there were questions one needed not to ask oneself. For example, you didn't need to ask yourself, and research, whether or not there was an sshd running or not.

Why not? Because you knew already: either you took the time and did the work, either you installed and configured an sshd, or there wasn't one. Because if you haven't done the work, certainly no one else has done it for you; it is your system, you are not just a user, but the administrator. So, you were given "complete control and responsibility over the system."

You don't need to ask whether there's a firewall active or not, because again either you set it up, or there isn't any. No question, no uncertainty. This is the Arch Way.

Now of course systemd isn't gonna install an sshd behind your back, but did you know that there was a tmpfs mounted on /tmp even though you never asked for it? It's not in your fstab, you didn't ask for this anywhere, but systemd did it. Now you can turn it off, I'm sure the systemd enthusiasts will be happy to explain how easy it is to create an aptly-named symlink to /dev/null to disable it, but that's missing the point.

And if you put files in there, be aware they might be removed after a while, because there's a thing called systemd-tmpfiles-clean that will take care of it. Again, you didn't have to set it up, it's done for you, it's the systemd way.

I for one am very happy I first came to Arch Linux, and installed it, back when there was a BSD-like init system still in place. Not because I have some love for a central rc.conf file, or because I dislike systemd and its symlinks in half a dozens places or so, but simply because back then it followed the Arch Way:

• it was simple, clean code path that one could look at to figure out what would happen, when and why. Try to do that with systemd, and you'll see how much complexity is at play here. And the more it goes, the more it does, the more complex it grows.

• it was user-centric, you had to set something up for it to be. There might not have been pretty user-friendly tools to list services with colors or the last lines from related logs, but you were the one to clearly decide what would run and when. If you didn't asked for dbus to start on boot, it wouldn't. If you didn't ask for a tmpfs to be mounted on /tmp in your fstab, there wouldn't be one.

I mentioned the installer earlier, I mean I didn't really but let's pretend I did: back in those days of BSD-like init system, Arch had an installer; Nowadays, it doesn't.

If you're familiar with Arch, you know this wasn't motivated by coming up with a solution that would be simpler, or more in line with the Arch Way, it was simply that the project was unmaintained and no one willing to step up and invest the time & work needed to keep it up-to-date, and a replacement deemed simpler - at least to maintain - was used instead.

At the time, many complained about the lack of an actual installer, asked for it to be brought back, and so on. I for one thought it was a positive change. It surely can be "scarier" to new users, especially if they're not familiar with Arch or even Linux, but once you've moved past that initial reaction, it's all good.

The new scripts come, as always, with great documentation on the wiki, and are exactly aligned with the Arch Way: providing tools to put you in control. And installing your system that way isn't that hard, it's a few commands to type instead of choices to make in a menu, but it's about the same, only better.

Better because it forces you to know what's going on, and what needs to be done and set up. I'd say you can't go though an installation now and not know what pacman is, but I'm sure you could before. I believe it adheres even more to the Arch Way than the old installer did.

This change, and the change for systemd, are - to me - going in opposite directions. The former puts the user even more in control, providing tools and letting one decide and set things up. The later "takes away" control for providing more user-friendly interfaces, and comes with pre-established choices that one don't even need to know about, until one finds out about them and need to disable them.

Other principles: Openness & Freedom

The Arch Way also states that "by keeping the system simple, Arch Linux provides the freedom to make any choice about the system. You can use the bootloader you want, the DE you want, if you even want one.

All of that remains true, except that more and more packages are now systemd-dependant. So even if you want to use another init system - noting that unlike with DEs or bootloaders, there will only be one in the official repos - you'll probably still need to have systemd installed, and some packages might need to be recompiled to get rid of that dependency altogether.

And it doesn't stop there, because while the systemd developers claim it is getting adopted by lots, they work hard on forcing it. I don't doubt they have technical reasons to justify that logind requires systemd as PID1, as they'll push for other projects to require logind, for technical reasons of course.

But in the end, all it does is reduce choice for most users. It doesn't go along with the beautiful idea of openness & freedom as described in the Arch Way.

Now imagine you're writing an init system, and you want daemons to have a way to tell said init system/service manager that they're ready. Because knowing a service is up is easy (yes, there might be some major over-simplifications here, but it doesn't matter for what I'm trying to say): process was launched, we have its PID, it is up; But when will it be ready?

You could create an API specific to your init only, and push on upstream projects so that they use your API, because you have the man power to do so, and soon we have, say, PHP that can let systemd know when it's ready. But of course it's via systemd-specific API so it won't work with any other init system, and to build PHP you need systemd, even though why such a portable general-purpose scripting language would have a dependency of any kind of an init system is beyond me.

Or. Or you could have asked for daemons to send their data (to let know they're ready) by simply writing to a given file descriptor. That means any upstream project could do that without the need for any new dependency, because writing to a file is something they should all be able to do already. And creating a pipe and reading an fd is a pretty generic, portable thing that could be implemented in about any other init system out there.

So you could have done it so it benefits the entire ecosystem, so all init systems could benefit from it, and daemons could easily add support for it, and it would work for any and all init systems supporting it.

But that's not the systemd way. Instead they do systemd-only APIs, they want to have one big thing that does more and more, and I'm sure there'll be technical reasons for udev to add support for kdbus, and then to require it (one way or another), which will likely lead to udev requiring systemd as your PID1. Not a bright future of openness & freedom if you ask me...

So whose system is this again?

As Judd Vinet, the founder of the Arch Linux project said: "[Arch Linux] is what you make it."

That is a great thing, one that is still true today, but I believe that it becomes harder and harder with the adoption of systemd as only official init system. And seeing how things evolve with systemd, it will only get harder.

This may be great for people making distributions with another user type in mind, people who want nice, easy things to use and aren't interested in knowing how it works or how to configure things to one's specific needs/preferences. It feels to me that wasn't Arch, or its goals.

systemd developers (which include Arch devs as well, as least via Tom Gundersen in the linked post) have ideas for the future for sure, I'm just not sure I share the same visions they do, and I certainly don't like the way they push for it at the expense of everything else.

It feels to me that isn't the Way of Arch, that Arch was targeting the competent GNU/Linux users, focusing more on being user-centric than user-friendly, giving you tools to build your system the way you want, not forcing on you someone else's vision. And that's what I liked, and why I picked it. But as it goes, I wonder: has Arch lost its Way?

I'm sure many, starting with Arch developers, will disagree. But in the mean time, I'll look for a way to use a different init system myself, to begin with.