domenica 17 novembre 2013

It's just an init system

The recent debate for the choice of the default init system in Debian has tickled my curiosity to know more about the current situation of init systems and at the same time has led me to form a certain opinion on this matter, which I'm going to share here. It should be noted that I'm currently employed by Canonical (I take the opportunity to underline that the opinions expressed here are just my personal ones), and while this might have had some influence on the forming of my opinion, in all honesty I claim to not have noticed any of that — though indeed I'll leave the verdict to you, if you'll be patient enough to read the whole post.

From the little knowledge I have of these init systems, I'll start by saying that I like Upstart (and I'm a satisfied user of it), as well as systemd and OpenRC. I find the design of Upstart to be elegant, modular, and the implementation could be set as an example for students of what good code is. On the other hand, when in 2010 I first read about systemd from Lennart's blog, I was almost blown away: it seemed to me that every detail had been considered to make the booting phase as efficient as possible, and I was looking forward to its development. And I should state very clearly that — despite not having yet tried it — I now believe that all promises were met, and that systemd is an excellent init system. As for OpenRC, I know really little about it, other than it's out there, it works, it's maintained and is in progress of being ported to FreeBSD.

That said, my wish is that Debian goes with anything but systemd. And that of course is not limited to Debian, but I wish the same for any distribution which is pondering a choice for the init system. Why so? As I said, systemd is an excellent init system, it's used in several distributions, and I would be very happy if other init systems took inspiration from it for all the good stuff it has to offer. My concern is better expressed by quoting Lennart himself:
I believe ultimately this really boils down to this: the Linux userspace plumbing layer is nowadays developed to a big part in the systemd source tree. Ignoring this means you constantly have to work with half-baked systems, where you combine outdated components which do not belong to together into something that in many facets might work but is hardly integrated or consistent. Or to put this another way: you are at a road fork: either you take the path where you use the stuff that the folks doing most of the Linux  core OS development work on (regardless if they work at Red Hat, Intel, Suse, Samsung or wherever else) or you use the stuff Canonical is working on (which in case it isn't obvious is well... "limited").
This text, turned into the opposite perspective, excellently summarizes the danger that comes with going with systemd: entering a road which hopefully continues in green and flowery fields, but from which it will be very very difficult to escape, should you want to. The more distributions go with systemd, the more the Linux world will be tied to it. The code of udev was merged into the systemd project last year, and Kay Sievers (the udev maintainer) assured that "the udev built from the systemd source tree will stay compatible with non-systemd init systems for a long time". How long? It seems just logical that the more distributions use systemd, the less effort will be spent to make udev usable outside on non-systemd systems. And, as Lennart wrote, it's not just udev. Already now logind requires systemd, and tomorrow it could be cgroups, kdbus, Wayland and what not. But if it's true that I like systemd, why am I complaining? How could this be a bad thing? We should simply all switch to the solution that currently is the best one, which in the opinion of many is systemd, and forget worrying, fighting and (more concretely) spending time in maintaining other init systems (and related plumbing stuff).

Well, the reason is that we don't know where the currently flowery road will lead us to. Could it lead to some bad place? If you think of a future where nearly everyone will be walking on this road, well, the bad case is really unlikely: there is a solid company behind the project (Red Hat), and possibly the greatest developers that have been worked on Linux. The fact that almost everyone will be using systemd should simply make it stronger and better. Just look at the Linux kernel.
However... we would still be locked on a road. This is what the text I quoted above says, after all: if you get out of the road, you lose logind (with GNOME as of now, and possible other DEs will follow), kdbus, udev, maybe even Wayland. More precisely, you don't lose them, but you'll have to come up with a system which offers all the equivalent required functionality. It's not impossible, but it would demand a great amount of work. And here I guess that even the most patient of my readers will have asked this question for the third time: "but why the hell would I want to jump off this road?".
Because you still can, as of now. You can write a better udev. You can write a better logind. You can write a better init system, a new one, you can even start from scratch, as a hobby project. You can write it in Go. You can innovate, you can come up with some revolutionary idea (as in some ways was systemd when it was conceived). Once all the Linux plumbing layer is tied together, changing stuff will be much more difficult — especially if you are a single individual with great ideas but limited time to implement them. Contributing changes upstream is not always easy, and it becomes more difficult as the complexity of the project grows. Not anyone can afford develop a new feature in a branch, and keep it in there until it's ready to be merged, rebasing it and solving merge conflicts every other day, for months. And it's likely that the more revolutionary your idea is, the deeper and more disruptive your changes will be, to the point that keeping them in a branch would be impractical. This is why I wish that the components which form the software stack remain separate: because you might want (or need) to replace them. You don't like Upstart? Fine, use OpenRC. OpenRC sucks? Fine, use something else. But in the future you won't have this choice with systemd, and probably with any other component of the Linux plumbing layer, once it's become part of a single entity.

I liked it when systemd came out. And I want such a change to be able to happen again.

Etichette: ,

2 Commenti:

Anonymous Anonimo ha detto...

Your argumentation is faulty. Advances in a field will always lead to more complex solutions that are harder to get into when entering a field. If one would follow your line of argumentation it would go like this for the kernel world

"The GNU/Linux kernel is far too complex, rapidly developing, and covers far too much functionality for a person to person to change it and although I like it very much I can only recommend everyone to use the BDS kernel or GNU/HURD."

Of course it will be harder to overcome systemd when its time has come (some time in 30 years maybe, just like with SysV init), but it is still FOSS, you can take the code and fork it and reimplement parts of it. Of course this will surely be more complicated in a more highly integrated environment, but it is too difficult today for a few persons to undertake today (see eudev), so we are not loosing anything anymore. If you want to have a modern system you have to concede, that no single person can understand all the parts by her- oder himself.

28 novembre 2013 16:08  
Blogger Alberto Mardegan ha detto...

I would not say that. The Linux kernel is monolithic, but it doesn't include things that don't belong to a kernel. The problem I have with systemd is that in the same project you have a few things that have little to do with an init system.
That said, I would certainly be very happy if one day the Linux kernel developers decided to define a stable API for kernel drivers (at least for a few types of devices), so that the same drivers could be used on other kernels. However, I understand that that would be very difficult, because new hardware comes out everyday, and having to stick to a stable interface could be quite hard. So I fully understand why they don't do that, and I don't blame them.

My point is: it's already difficult to replace a component like udev (as you pointed out), and replacing a component such as init system + udev + networkd + kdbus etc etc. will be even more difficult.

This might sound like a joke, but what if one day Linux and systemd became an inseparable entity?

28 novembre 2013 22:43  

Posta un commento

Iscriviti a Commenti sul post [Atom]

<< Home page