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:Accept, don't fight, systemd (Score:3, Informative)
Don't hold your breath that BSD will adopt systemd. Maybe FreeBSD, but they are basically Linux flavoured BSD anyway. But the _serious_ 4.4BSD based systems just don't see the need, and are happy with the few lines of code that makes up a safe init.
I wrote OpenRC (Score:5, Informative)
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.
Re:Accept, don't fight, systemd (Score:4, Informative)
Also, Lennart Poettering has noted he doesn't care about support anything !Linux, even if someone else maintains the code.
Too much integration (Score:3, Informative)
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.
No... (Score:5, Informative)
There are significant numbers of people who understand it just perfectly and have valid criticisms that are not bugs.
http://ewontfix.com/14/ [ewontfix.com]
The systemd team has pissed of Torvalds:
https://lwn.net/Articles/59368... [lwn.net]
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*.
Re: How does it affect me? (Score:4, Informative)
PA actually seems to work great lately. At this point Windows has bad support for Bluetooth headphones, while in Linux it works great.
Slackware (Score:5, Informative)
depinit (Score:5, Informative)
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.
Re:Accept, don't fight, systemd (Score:5, Informative)
Solaris has it's own abomination called SMF. Good luck debugging network problems on Solaris without a GUI unless you're experienced with SMF. I use Solaris only to maintain my open source projects (I value portable code), and I _hate_ dealing with the system. So convoluted.
The system with the most straightforward configuration and init system, IMO, is OpenBSD. It's soooooooo nice. The only major change in nearly 15 years has been the move to an rc.d/ (init.d-style) startup script directory. Contrast that with number of convoluted changes in Linux administration over those past 15 years, and it seems like a miracle.
If SMF and launchd (OS X) are any indicator, I'm definitely going to hate working with systemd.
(NOTE: I haven't used Slackware since the 1990s, so maybe it's remained stable all these years, too. For Linux I tend to only use Debian and Ubuntu.)
Re:No... (Score:2, Informative)
The ewontfix.com/14 article is full of factual errors and was rebunked several times by more knowlegable people. And Linus is pretty easy to piss off, what does that prove?
"If you do not like it, fix it" is still valid. Systemd did up the ante, so it is indeed more work to provide a complete replacement of systemd than it was for systemd to replace sysv init. But then systemd would indeed be poor if it did not provide benefits over previous implementations.
What really amazes me is that people ranting about software starting to depend on systemd does so just to annoy them personally. That is completely stupid: The software depends on systemd since it solves real problems that software used to be facing. When a wide group of developers sees value in using systemd, then maybe reading up on it (past the point where you go "oh, we never did it like that before") might be warranted?
Re: Accept, don't fight, systemd (Score:5, Informative)
Never used SMF, but systemd is quite a bit better than launchd. The configuration files are all plain text. The major difference from a configuration point of view is that instead of writing a script, you just specify executable information, dependencies, sockets, etc, in a config file. That's it. Doesn't seem like such a big deal to me and in many ways seems quite a bit better than sysV.
Re: Accept, don't fight, systemd (Score:5, Informative)
The configuration system for daemons that systemd has is an enormous leap forward over the old shell scripts. If systemd would stick to be an init system, it would not be such a problem.
When it takes over file system mounting, including hiding most mount points from /etc/fstab and breaking silently if there are perfectly valid mounts in there which it happens not to like, people complain.
When it takes over system logging, previously one of the major advantages of Unix-based systems over Windows, people complain.
And so on and so forth.
Re:No... (Score:4, Informative)
Because openRC is not even in the same league as upstart. And systemd leaves upstart in the dust -- which is why debian went for that instead of upstart. Read the technical comitees findings: Most TC members wrote a summary explaining their decisions and those are really full of good technical information. There is a lot of cruft in between those posts though.
If you do not believe me or think the Debian technical comitee to be biased: Read up on why the people responsible for the software that now moves to depend on systemd do that. Most did provide a solid reasoning for their decision. One argument is that it is available everywhere, but then there is the great cgroup stuff (systemd can reliably stop services incl. all their children -- finally), security features (like private temp dirs for services, etc.) that are really easy to do, simple configuration language for the services (*way* simpler than sysv init scripts), proper logs for everything, simpler debugging of services (the status output of the service contains the last log lines -- you do get used to that really fast!).
Could all that be implemented in a different way? Sure. But nobody did it yet. Maybe openRC will at some point implement all that and be a serious contender? I doubt it, but who knows.
Re:No... (Score:5, Informative)
Those interested may look at LWN's report for a saner, more balanced view: http://lwn.net/Articles/593676/ [lwn.net]
NetworkMangler "user friendly"? (Score:4, Informative)
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".
Re:what's wrong with systemd (Score:5, Informative)
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.
Re: We'll keep on trucking without systemd garbage (Score:5, Informative)
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).
Re:launchd (Score:4, Informative)
systemd is just an inferior version of launchd [apple.com].
Yes, that's almost a factor of 10.
Re:Hmm (Score:4, Informative)
Yep, it works, I don't get any headaches from running it, so therefore it is OK.
I have started to look into the workings of systemd, and it certainly seems fine for modifying service dependencies, writing my own daemon, and customising the startup (though that is a rather ambiguous phrase). I can even use a sysv init script within a systemd service file, if I wanted to. You don't need to add debug output with systemd, because you don't need to write a script to start a daemon. It just starts the daemon you configure in a service file, and logs any output. That works for me, and to be honest, is actually much simpler.
Understanding bash syntax isn't as useful on HP-UX and FreeBSD. That shell isn't guaranteed to be available. A sysv init script isn't as portable as you make it out to be, because of inconsistencies between the different systems you mentioned. Good luck getting a Slackware init script to run on HP-UX. You _could_ make a portable script, I suppose. So that is an advantage, even if it takes extra work to properly test the script on every type of system you need to run it on. But if you have any Solaris SMF systems, portability goes down the drain.
Systemd is a change in the way thing run. It takes some adjusting and getting used to. If you make the effort, you'll find that you can make it work for what you want. That's an OK in my books.