Ask Slashdot: Practical Alternatives To Systemd? 533
First time accepted submitter systemDead (3645325) writes "I looked mostly with disinterest at Debian's decision last February to switch to
systemd as the default init system for their future operating system releases. The Debian GNU/Linux distribution is, after all, famous for allowing users greater freedom to choose what system components they want to install. This appeared to be the case with the init system, given the presence of packages such as sysvinit-core, upstart, and even openrc as alternatives to systemd.
Unfortunately, while still theoretically possible, installing an alternative init system means doing without a number of useful, even essential system programs. By design, systemd appears to be a full-blown everything-including-the-kitchen-sink solution to the relatively simple problem of starting up a Unix-like system. Systemd, for example, is a hard-coded dependency for installing Network Manager, probably the most user-friendly way for a desktop Linux system to connect to a wireless or wired network. Just this week, I woke up to find out that systemd had become a dependency for running PolicyKit, the suite of programs responsible for user privileges and permissions in a typical Linux desktop.
I was able to replace Network Manager with connman, a lightweight program originally developed for mobile devices. But with systemd infecting even the PolicyKit framework, I find myself faced with a dilemma. Should I just let systemd take over my entire system, or should I retreat to my old terminal-based computing in the hope that the horde of the systemDead don't take over the Linux kernel itself?
What are your plans for working with or working around systemd? Are there any mainstream GNU/Linux distros that haven't adopted and have no plans of migrating to systemd? Or is migrating to one of the bigger BSD systems the better and more future-proof solution?"
Unfortunately, while still theoretically possible, installing an alternative init system means doing without a number of useful, even essential system programs. By design, systemd appears to be a full-blown everything-including-the-kitchen-sink solution to the relatively simple problem of starting up a Unix-like system. Systemd, for example, is a hard-coded dependency for installing Network Manager, probably the most user-friendly way for a desktop Linux system to connect to a wireless or wired network. Just this week, I woke up to find out that systemd had become a dependency for running PolicyKit, the suite of programs responsible for user privileges and permissions in a typical Linux desktop.
I was able to replace Network Manager with connman, a lightweight program originally developed for mobile devices. But with systemd infecting even the PolicyKit framework, I find myself faced with a dilemma. Should I just let systemd take over my entire system, or should I retreat to my old terminal-based computing in the hope that the horde of the systemDead don't take over the Linux kernel itself?
What are your plans for working with or working around systemd? Are there any mainstream GNU/Linux distros that haven't adopted and have no plans of migrating to systemd? Or is migrating to one of the bigger BSD systems the better and more future-proof solution?"
Re:Hmm (Score:5, Interesting)
PolicyKit specifically can be compiled to use consolekit instead of systemd for session tracking.
Except that, last I heard, Lennart is also the maintainer of ConsoleKit, and he has officially declared it dead in favor of systemd-logind. Seriously, the reason everyone choses systemd is because it's just better. And as a former Gentoo dev with a good knowledge of openrc, systemd is one or two levels above.
Comment removed (Score:5, Interesting)
I really don't see what is the problem here (Score:4, Interesting)
I've pinned systemd in apt to -1 (so it won't ever install on my machines). So far i didn't have any problem. Debian will continue to support sysv for years and years, and in that timeframe this silly systemd fad will have passed away, and people eventually regain their minds and (hopefully) balls.
This "inevitability" horse shit is that: horse shit. Linux is equally useful without systemd, provided you have a mininum of experience.
Re:Accept, don't fight, systemd (Score:5, Interesting)
That Oracle dislikes something isn't a condemnation. It's more nearly a recommendation.
That said, I'm dubious about systemd. I almost understand how to use init. OTOH, I prefer the interface of the pre-grub2 grub to the current one. I assume that there must be SOME benefits to the change, but I haven't found any. I expect to end up feeling the same way about systemd.
Re:Hmm (Score:5, Interesting)
I am extremely suspicious of so many folks with 3 digit IDs coming out strongly in favor of the inevitability of systemd.
I strongly dislike systemd and Pottering and I am shocked that Linux is evolving in this way. It seems like a concerted and coordinated effort. It seems like someone is driving a poison dagger deep into the heart of Linux.
I would be interested in hearing why exactly you are in favor of giving up the *nix way? Is "one or two levels above" really worth it when it costs so much more?
Re:Accept, don't fight, systemd (Score:4, Interesting)
You are wrong, and fundamentally wrongheaded.
"If there are things you don't like about it, trying to use an alternate init mechanism is only going to cause you personal grief that will likely only increase in severity over time as it gets harder and harder to retrofit software packages to use other init systems as systemd further embeds itself into the Linux software world."
And if we accept your advice we ensure that catastrophe. No thanks.
"If there are things you don't like about systemd, you should write up coherent bug reports or feature requests, and get them in front of the right people (once gain, someone jump in here and say who these people are and how to get these types of requests out there, I actually don't know). Or better yet, make the improvements to systemd yourself if you are capable of doing so."
This advice does not fit the situation at all. Bug reports and feature requests? You do not fix a fundamentally mis-specified and mis-designed program with bug patches and requests for even more misfeatures!
"Your goal should be to improve both systemd itself"
This makes no sense whatsoever. I dont want to 'improve' it I dont want it period. Init works great. It's not broken, dont fix it.
"By hook and by crook, systemd has become the standard way"
Negative. Init is the standard way. What's happened is that the number and visibility of the deviationists has increased. Popularity along is not sufficient to change a standard.
"If systemd is so onerous to you that you can't use Linux anymore"
Huh? Cant use linux? WTF are you talking about?
I am pretty sure that Linus has no plans to integrate this trash into the kernel. And if he did that would just mean it's finally time for a fork.
Re: Accept, don't fight, systemd (Score:5, Interesting)
When it takes over file system mounting, including hiding most mount points
I can see how this is annoying, especially when you don't know what is going on, but mounting filesystems is an integral part of the startup process and therefore should be managed (in part) by systemd. It was manged using the old sysV scripts too btw, so it is consistent as far as init systems go. The difference with systemd is it actually knows what a filesystem is and that it is different from a service, so it can manage and monitor them accordingly. What this means is that filesystems associated with booting (root, swap, dev, ...) are now systemd entries instead of /etc/fstab entries. Once you realize this, it is not that hard to manage. And /etc/fstab does still work, of course, for filesystems you want to manage yourself. There are reasons you might want to create systemd entries for those too, though. Automounting, for example, is handled much better with systemd than the old autofs route that we had to use before.
and breaking silently if there are perfectly valid mounts in there which it happens not to like
That is either a bug, or possibly a conflict. Again, I can see how it is annoying, but if you have an /etc/fstab entry that wants to steamroll a systemd entry, it is understandable that systemd will try to stop that from happening. The correct fix in that case would be to edit the systemd entry to match the changes you are trying to make with the /etc/fstab entry.
When it takes over system logging
So, systemd doesn't just start/stop services, it also monitors them and can be configured to take certain actions depending on what happens to a particular process. So, needless to say, logging is kind of inherent to the whole thing. Correct me if I'm wrong, but I don't think it "taking over logging" is your real objection, but rather the way in which it does its logging. Instead of splitting things into separate text files that are managed by their respective daemons, systemd collects all this information and stores it in a standardized, indexed way within its own file. This is a design decision, and with all design decisions there are tradeoffs. In this case you are sacrificing the ability to just cat/grep individual text files for the ability to filter and have other processes able to monitor the log files, as well as some benefits for auditing and security. I definitely prefer text files because I don't manage complex scenarios, but I can also see how journald is critical for certain enterprise infrastructure. If you don't like journald, you can install syslog-ng. You just have to make sure it doesn't trample on journald (ie: it has to listen on the journald socket instead of /dev/log). I believe CentOS 6 is configured this way (journald+syslog-ng), so it is not that unusual or hard to do.
Re:Accept, don't fight, systemd (Score:4, Interesting)
Your statements are more prescient then I think you realize.
It IS kind of like the Borg; there is kind of like a "hive mind" in open source; whatever the most people think should happen, is what will happen. There is no central authority to dictate that anything other than what the majority wants should happen.
In this case, it's pretty clear that, since all the major distros have accepted systemd, that it's been accepted by the majority of users and become the de facto standard. There seems to be alot of momentum behind it.
I could of course be wrong; maybe it just looks that way, and maybe there is enough of a seething hatred underneath the covers for systemd that it will be ousted soon. But in the meantime, what are you going to do? Just hope, pray, and wait for that to happen? Why not try to improve the thing instead of complaining about it hoping it will go away?
An alternative to my suggestion that people accept systemd and learn to use it, and work to improve it to make it better, is the suggestion that you "take to the streets" and actively fight against systemd rather than accepting it.
You can suggest that to people if you want to; it's just that I don't think it will work and I think those people will waste their time and energy. And I won't suggest to people that they should waste their time and energy on something, especially something that has no moral or ethical implications and is just freaking OPEN SOURCE SOFTWARE that we can all change for the better if we want to.
Re:Accept, don't fight, systemd (Score:5, Interesting)
The problem is: A *tiny* init process won't be able to offer the *exactly same* functionality. The functionality has to come from somewhere, it does not fall from the sky: Some code needs to implement it.
If you want to keep PID 1 tiny then you can implement the actual functionality in separate processes. You now have two or more process and now you need code in the tiny init process that makes sure the controlling processes are getting started (and restarted). Remember: Those daemons provide the actual functionality, so PID1 can not depend on that to start those daemons in the first place.
You need code that facilitates a communication channel between the processes. You need code to lock out processes that are not meant to talk to your tiny init process. You need a protocol that the init process speaks and that allows it to be remote-controlled. All of sudden that tiny process is no longer tiny and your architecture is much more complex than it would be otherwise.
That complexity requires you to add more code to mitigate communication failures, to synchronize data structures between all the different processes that need access to them, you need to be careful not to introduce race conditions between those processes. In the end you end up with a pretty big init process and a bunch of big and nearly equally critical daemons surrounding it. I do understand where the systemd guys come from: Keep the architecture simple, and put absolute minimum amount of code into PID1 to provide the functionality they want. That makes the overall system less complex and easier to reason about, which is good for security and robustness.
Read the code, it is actually pretty ok.