Slashdot Mirror
Ask Slashdot: Practical Alternatives To Systemd?
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?"
Whether you love, hate, or are ambivalent about systemd, I think you have to accept it at this point. 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.
If there are things you don't understand about systemd, you should read as much as you can to try to figure it out for yourself, and if you can't, you should write up coherent questions and post them in the appropriate forum for help (what is the appropriate forum? I don't know - someone jump in here and help me out. I personally often have no idea where the best place is to ask questions about things like systemd).
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.
Your goal should be to improve both systemd itself and your knowledge of how to use it to the point where it is something you are happy to use, not work around it. By hook and by crook, systemd has become the standard way of doing many things in a typical Linux system and it's time for all of us to just accept that and to make forward progress. It's too late to try to work against systemd; it's time to "embrace and extend".
If systemd is so onerous to you that you can't use Linux anymore, then I guess BSD is a possible solution for you. But who knows, maybe BSD will eventually adopt systemd as well?
PolicyKit specifically can be compiled to use consolekit instead of systemd for session tracking (this is actually the default, you have to explicitly compile policykit with systemd support).
Unfortunately this is kind of the downside to binary based package management. Either PolicyKit has to be modified to support both as configurable options, probably involving a maze of symlinks and wrapper scripts, or separate policykit-systemd and policykit-consolekit packages have to be provided.
If Debian has decided to to go with systemd, this is probably going to be a common issue on that distro, as when given the option of compiling something with it, they probably will.
Aside from joining us over on the gentoo side (open-rc is life but using something else is easier as it's just a use flag for most packages), or maintaining your own sizable collection of custom-built packages, don't know what to tell you!
I wish people who wanted windows would just stick to windows instead of infecting linux
And now I use NetBSD.
systemd also has its own NetworkManager wanna be in the making as well. I also dislike this.
For shameless plug I currently maintain dhcpcd which does your DHCP, IPv4LL, IPv6RS and DHCPv6. Other nicities like carrier detection, SSID and ARP profiles, routing preferences all come as standard. All in 155k. For kicks there is even a basic GTK+ system tray notification widget that also talks to wpa supplicant to allow wireless network selection and password entry.
It isn't just the boot. Lennart now calls it "Core OS" and he means it. NetworkManager was crap, admit it. After years it still couldn't do everything the software it replaced did but it no longer matters. Latest systemd now even nukes it and replaces it with a all new Core OS replacement that won't work. Which is part of the pattern of destruction that defines Pottering's way of working. PulseAudio is still mostly broken and that was his first project that got any widespread attention. Guy is leaving a trail of destruction wherever he goes and for some strage reason he being allowed to go everywhere.
with Gnome and other bits for my liking. This is like PulseAudio. It's not that good and it seems everyone is adopting it. The issue with FOSS is the desire for change that is too quick rather than fixing what works. LILO, for example. While GRUB is great, LILO worked fine for me and in fact, it still used by many distros. FOSS has become bloated like its commercial counterpart.
Recently I installed the still-in-alpha Haiku OS because I miss BeOS (still). The entire OS installed in less than 2 minutes. Talk about *fast*. It it were not for the lack of decent software, I would make the move today. Haikuware does have some great software, though. BeOS was awesome and kept it simple. Written from the ground up to remove the mistakes traditional UNIX and Linux were/are still making.
There are significant numbers of people who understand it just perfectly and have valid criticisms that are not bugs.
http://ewontfix.com/14/
The systemd team has pissed of Torvalds:
https://lwn.net/Articles/59368...
Additionally, they repeatedly deny that anyone should have a text log for any reason, dismissing criticisms as 'just hook in syslog *too* as an *optional* thing'. Basically systemd discards decades of sensibilities ecosystem to 'do it better', while throwing out the baby with the bathwater (ditching modularity and portable log data and such).
It's not just that 'if you don't like it, fix it'. People don't like the very fundamental aspects of the design that the systemd did *on purpose*.
XML is like violence. If it doesn't solve the problem, use more.
PA actually seems to work great lately. At this point Windows has bad support for Bluetooth headphones, while in Linux it works great.
RMS must be grinning, Linux has finally implementes Emacs as its startup system.
Your immediate recourse is, indeed, to try and sample the *BSD offerings. Their rc.conf approach I find a lot simpler to deal with than sysv's kludgy linkfarming ever was. It works very well without imposing all sorts of requirements on the rest of the system.
But the problem is political, and so the solution isn't technical. On the political side, I'm highly annoyed by the approach that resulted in this damage, but it's actually endemic in the linux world: Identify problem, then go berserk on the over-re-design-engineering like you're deliberately aiming for a strong case of second-system effect. One (and my pet-) example is the "better replacements" to their broken ifconfig, incompatible with everyone else (and three mutually incompatible attempts down the road there's no end in sight), but there are many more. The latest batch just have taken the previous failures to new heights of technically working incompetence.
What is new-ish is that the damage is spreading, in the sense that by design systemd is linux-only yet now various programs that previously worked on Unix in general are starting to depend on it. Apparently a certain bunch of influential people in the linux-sphere want to become their own vendor-lock-in-enabled bubble, to be the next redmond. This is... not good.
There really is very little recourse other than starting your own lobby war to stop the bunch. Because the problem is mostly politican, the technical side is but a symptom, almost a sideshow.
Without political pressure, soon linux will be akin to macosx, except with poorer code quality and less unified design: Technically some Unix-heritage, in practice it's its own thing, incompatible with the world. So if you'd like a Unix, your route is to *BSD. If not, you can stay and put up with the slowly mounting pile of crap of which systemd is but one thing, if possibly a tipping point-inducing thing. The *BSD people will still have to find some sort of answer, and soon, or they'll have to decide that everything depending on systemd+friends will be a lost cause anyhow and find alternative software with similar functionality, for the current crop no longer works outside of this brave new linux.
Slackware is an alternative mainstream Linux distribution which does not use systemd. Instead of systemd, it uses a combination of custom rc scripts and sysvinit. If Slackware ever adopts systemd as the default system init, they would likely lose most of their user base.
If you really must avoid systemd, then Slackware is probably the way to go. Alternatively, FreeBSD/PC-BSD are prettly much safe from ever getting systemd. For now you could stick with Debian Stable or Ubuntu LTS, both of them will run for years on the older init systems. So, really, you are pretty safe from systemd for at least three to five years, even in the Debian/Ubuntu corner of the Linux ecosystem.
But, really, you might ask yourself why go to all the trouble? Is it a philosophy issue? Is it just hating change? Is there something technical causing problems with your computer that is caused by systemd? A lot of people claim to hate it, but rarely give any practical reasons. Sure, there are plenty of philosophical issues with systemd (and lots of personal issues where its developers are concerned), but take a good long look at why you don't like systemd before you try to avoid it.
Im currently running Gentoo. it offers systemd as a package and ive even run it a few times with success. What it offers, along with uefi, is a chance to drastically speed up the boot process but at a cost to the Linux ethos of 'do one thing and do it well.' Im just as conflicted, and seeing as i work in a RedHat shop i fear ill have to start using it eventually. TFA from sporkbox in the summary highlights the major pain points of systemd quite nicely but the other problem it poses is the homogenization of linux and what that means to numerous Linux community members personally. Linux used to be about choice, but so many distros are systemd/gnome/networkmangler now that its almost horrifying. I get that a unified platform is the key to a 'year of the linux desktop' but the sense of alienation and loss that systemd imparts is very palpable for many of us.
Back on topic though, Gentoos commitment to choice means you can run OpenRC. Its a fine time-tested alternative to SystemDoEverything and while your coworkers might be confused by it, at least you wont have to hack through binlogs for ages to fix a problem in it. You're best not trying to hack out systemd or any of its dependencies in distros like Fedora or Ubuntu as theyre basically so intrinsic to the OS as to render it useless if removed.
Sorry i cant offer more closure for the issue, I hope someone in the thread can though. For me i worry in another ten years ill be deploying machines that are exclusively systemd, quietly muttering the free software lyric, 'You'll be free, hackers, you'll be free.'
Good people go to bed earlier.
And I wish people that want Linux to stay frozen would just stop upgrading or move to a system that sure to stay in 1970.
depinit. written by richard lightman because he too did not trust the overcomplexity of sysv initscripts and wanted parallelism, it was adopted by linux from scratch and seriously considered for adoption in gentoo at the time. richard is extremely reclusive and his web site is now offline: you can get a copy of depinit however using archive.org.
using depinit in 2006 i had a boot to X11 on a 1ghz pentium in 17 seconds, and a shutdown time of under three. depinit has two types of services: one is the "legacy" service (supporting old style /etc/init.d/backgrounddaemon) and the other relied on stdin and stdout redirection. in depinit you can not only chain services together for their dependencies but also chain their *stdin and stout* _and_ stderr together.
that has some very interesting implications. for example: rather than have some stupid system which monitors /var/log/apache2/logfile for security alerts or /var/log/auth.log for sshd attacks, what you do is run sshd or apache2 as a *foreground* service outputting log messages to stderr, chained to a "security analysis" service which then chains to a log file service.
the "security analysis" service could then *immediately* check the output looking for unauthorised logins and *immediately* ban repeat offenders by blocking their IP address, rather than having to either poll the files (with associated delays and/or CPU untilisation) or have some insane complex monitoring of inodes which _still_ has associated delays.
also depinit catches *all* signals - not just a few - and allows services to be activated based on those signals. richard also had a break-in on one system, and they deployed the usual fork-and-continue trick, so he wrote some code which allowed the service-stopping code to up the agressiveness on hunting down and killing child processes. this also turned out to be very useful in cases where services went a bit awry.
basically the list of innovations that richard added to depinit is very very long, in what is actually an extremely small amount of code. i simply haven't the space to list them all, and no, richard was not a fan of network-manager either.
btw you might also want to look at the replacement for /bin/login that richard wrote. it was f****g awesome. basically what he did was use gpg key passphrases as the login credentials.... and ran gpg-agent automatically as part of the *login*. i have never even seen a PAM module which does this trick. it would be awesome to do the same trick for ssh as well.
it's fascinating what someone can get up to when they have the programming skill and the logical reasoning abilities to analyse existing systems that everyone else takes for granted, work out that those sytems are actually not up to scratch and can write their *own* replacements. it's just such a pity that nobody seems to have noticed what he achieved.
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.
How right you are: https://www.google-melange.com...
I would trust OpenBSD systemd replacement over the original any day.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
"First, I have to ask, what is wrong with systemd?"
It's a massive, complicated, and very poorly behaved substitute for a simple, robust, and well behaved program. And it's not just a regular program, it is (if used as intended) a critical system component that will take your entire system down when it goes wrong.
If it were just a bad program, that's no big deal in and of itself, there are plenty, you just avoid them. But these people are not hackers, they have a marketing engine and are aggressively attempting to push themselves into a position where it WILL become impossible to avoid them and still use many new programs. That's beyond offensive. That's an attack on the Free Software ecosystem itself.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Uh.
What?
I remember I used to have these horrible connectivity problems with it, which turned out to be a result of a "feature" wherein it couldn't be used with a wifi network with a non-broadcast SSID, because it would scan for broadcast SSIDs, not see the one it was trying to be connected to, and turn the connection off. I spent a month or so trying to get it to use a WPA2 VPN and eventually gave up and went to wicd.
I have never previously heard anyone describe NetworkMangler in any positive terms whatsoever, let alone suggest that it was in some way "friendly".
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
I like how people automatically assume change == good. Maybe I'm getting old, but it seems to be a young person thing (as is the rewrite everything from scratch mentality).
Change is change. It can be good, it can be bad. I'm not an expert on such things, but from everything I've read, the change to systemd is bad. And it seems to be a bad change in much the same ways the examples of change you gave (Metro, Unity, etc.) have turned out to be bad.
The Unix philosophy has always been to do big things by using little pieces. To violate this philosophy is not necessarily bad, but it would seem like trying to fit a round peg into a square hole. Sure, if you hammer it in hard enough, the thing will fit. But your square hole might have trouble fitting square pegs through afterwards, and your wooden board might crack after you fit more things through the hole irrespective of shape.
I'd have used a car analogy, but the best I could come up with is using the wrong kind of motor oil, which when put that way, doesn't seem quite as severe as the systemd problem.
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
Systemd COULD be a good thing if it would stick to starting up the system. It should START udevd, not BE udevd. It should START dbus, not BE dbus. It should be trivially easy to do any of:
Switch from systemd to SysV, switch from SysV to systemd, use systemd but honor the SysV init scripts. With a bit of work fron the systemd folks, it should even be fairly easy to use SysV and have it start systemd to monitor select daemons.
Do that and every single objection would go away immediately.
What's wrong with it? Here's my starting list and I'm sure I'll think of more....
- Binary Logs: Sorry, but there is no advantage to not being able to easily look at a log file.
- Failure to Log to the Console: There is nothing more frustrating than watching 5 screens of "Failed, use journalctl to blah, blah, blah..." come by when you know that your root filesystem isn't mounted read/write. There went *ALL* your debug information.
- Failure to Drop to a Shell When It Breaks: If my boot is broken,I want a shell. Not a hang. There's a way to force it to go to a shell, but that's before it does *anything* so you don't get to debug the failure, you get to guess what the failure might be and see if you can debug *that*.
- No way to see WTF it's doing: There's supposedly a command to make it tell you what order (and presumably what'll happen in parallel) things are going to start in. However, if you use that command as root, it tells you not to run it as root. If you do it as a normal user, it doesn't have permission to read all the files to tell you what it's doing.
- Races: I no longer have any idea what order things are starting in. I've had a cluster where everything worked fine. Until the a week and a few reboots later and then it occasionally failed. Don't even start to tell me that "I must have my dependencies wrong". I *KNOW* they're wrong. But I have no tools to help me figure out what "right" is. Plus, have you looked at how many unit files systemd starts on a normal system? I can't hold that much of a graph in my head. With SysV init, unless I turned on some weird parallel mode, everything starts in the same order every time.
- Complexity: I'm not a professional sysadmin. I'm a developer who has to maintain development systems (as well as personal systems) part time. If I worked with systemd every day, I'd probably be able to figure out ways to make it work for me. But I don't. SysV is just shell scripts. I *DO* deal with *those* every day so it's pretty easy to debug.
- Complexity, Part 2: The previous version of init essentially had no bugs. Ok, I'm sure that's not really true but they sure didn't surface very often. Since the results of your Process #1 dumping core are catastrophic (ie, a kernel panic), ideally that process should do as little as possible. That is *CLEARLY* not the design philosophy of systemd. Further, it consumes a decent amount of RAM and the more RAM you consume, the more likely (statistically) you are of hitting a memory error.
- YACL (Yet Another Config Language): Ok, so this is really a minor complaint but I get to learn yet another way of writing config files.
- Filesystems: SysV init tended to mount local filesystems *very* early in boot (some of that broke when udev got involved, but you could usually hack around that) and network filesystems not long after. I'm not entirely sure where systemd mounts filesystems, but it breaks *HORRIBLY* if you move some of the files needed by a service onto a filesystem that's not a "normal" filesystem. I'm sure there's some way to set all the dependencies to make that work, too, but see above, I have no f'ing way of figuring out what should depend on what.
From all outward appearances, the developers have *no* interest in fixing much of any of those complaints. The whole "debug on the kernel command line" fiasco is a pretty clear indication that they "don't play well with others". In the end, I'll see what Slackware has or maybe move (back) to the BSDs.
Go Badgers! -- #include "std/disclaimer.h"
> How long until all of the software packages that BSD wants to use require so much work to retrofit to use a different init mechanism that they just throw in the towl and accept defeat?
Keep in mind that *BSD is not alone. There are other GNU/Linux distributions that avoid it. Gentoo are among the distributions working on things like eudev (so you can keep on using udev without systemd).
9/11: Never forget it was a false-flag operation
systemd is just an inferior version of launchd.
Yes, that's almost a factor of 10.
"First of all, each script is code."
That is a feature, not a bug. I *want* my scripts to be code. That is why they are scripts-
"Second, no script is aware of any other scripts presence"
That is a feature, not a bug. The UNIX way is to do one thing, and do it well. That is how the init scripts should be constructed. Anything else is a failure in design.
"Third, a typical shell script is >100 lines of block logic to implement the equivalent of "service start"."
Which is perfectly fine, as the parameters (if any are needed) are gathered at the top, easy to find and commented. But usually none are needed as they are in the config file for the service.
Thus, these arguments are either neutral or work against systemd. None show systemd to be in any way better. It's a monolithic lump which has no place in a UNIX style system.