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?"
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.
Wow....someone asks what they can do about having a software package shoved down there throat and your response is just open wide and swallow? I thought this was supposed to be about freedom. Wait, GNU/Linux is about freedom, as long as it's what they want you to do....
On a more serious note, any software that wants UNIX compatibility will keep supporting SystemV/BSD init. I get the distinct feeling that Oracle and especially the BSD guys don't want anything to do with systemD.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
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.
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.
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.)
To be fair, LILO is very primitive and sensitive. It doesn't read filesystems; it has an installed map (the result of running lilo) that lists the exact blocks to load for a given entry. You cannot load anything that's not in its map. Touch any of those blocks and it can fall apart. GRUB was a vast improvement, but also adds a great deal of complexity. (GRUB2 even more so.)
the systemd init may be brilliant, if it would be isolated. But its mixed up with udev, syslog and even gnome to some extent. This cannot be an good idea, because stuff like init needs to KISS.
http://wizardofbits.tumblr.com...
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.
Finally! A year of moderation! Ready for 2019?
Those interested may look at LWN's report for a saner, more balanced view: http://lwn.net/Articles/593676/
It's a theme on the Internet. If you don't qualify every minor nuance of your statement, or carve out an exception for every conceivable corner case, someone calls you out on it. Nothing can be left as an excercise for the reader, because too many readers are pedantic or intellectually dishonest.
Usually it's intentional equivocation masked as an attempt to sound intelligent or continue the argument when they no longer have a real point. Often they boil down to syntactic or semantic arguments, belaboring point after point until those with solid points are swarmed by nits. Unfortunately, that makes it very difficult to tell when someone is being obtuse versus when they are being curious or have a legitimate point.
The road to tyranny has always been paved with claims of necessity.
If you think sysv init is not broken, then you must not have been using unix systems in earnest.
It is only simple till you want to have a reliable boot without races... BSD init is way simpler, true, but then that was deemed to be too inflexible already in the golden times of Unix. You really want to go back to that? Seriously?
You are aware that udev is part of that tree you are proposing to delete? With eSATA harddrives coming and going, projectors that get attached at random times, all kinds of gadgets with USB connectors? No thanks, I want something that I do not need to change a the boot script and then reboot when I plug in a mouse.
Let me keep systemd and go straight for a beer instead of bombing my system back into the 60s.
That way I can also update all the software I care about (much of it already depends on systemd or will do so soon), I get /var/log,
* the journal instead of a set of randomly formatted text-dumps all over
* a convenient way to kill apache with all the crap that it started,
* a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there.
* a more secure system by being able to isolate daemons from one another and the rest of the system.
* a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them
Sheesh:-)
Regards, Tobias
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"
the journal instead of a set of randomly formatted text-dumps all over /var/log,
Yes, those would be called, errr, yes, LOGS.......
As a sys admin I want something I can read when my system goes wrong and I don't want to have to get a retarded web server up and running to read them.
Seriously, people suggesting this kind of retarded shit don't know Unix, don't know Linux and don't have the faintest idea whatsoever. Go and read a Windows registry file, have fun and knock yourself out but don't bring that retarded crap so an operating system that actually works.
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.
Regards, Tobias
the journal instead of a set of randomly formatted text-dumps all over /var/log,
I'll take the text-dumps any day, thanks. And since they're usually created via *syslog*, they may not even be stored locally. And they are easy to manipulate with the available shell tools (grep; cat; awk; etc). If you want a database-driven syslog, there are plenty around.
You can wire up syslog to the journal. Why would you want to convert rich information into a string and shove it down a pipe before you make use of it? Let's start with a useful format and use lossy conversion methods on that when needed, not the other way around.
You are not ripping your CDs to mp3s either so that you can burn other CDs by converting those mp3 files to WAVs either, do you?
a convenient way to kill apache with all the crap that it started,
It seems you're getting closer to the real problem. Apparently you don't know how to operate a vaguely modern unix system.
So please enlighten me: How do you kill apache with all the php/ruby/whatnot crap it directly or indirectly spawned? With systemd it is just one convenient systemctl stop apache
Please do not assume that I am too young or too stupid to know the good old ways. I have been around for a while, even though I still have not managed to learn not to get into discussions at slashdot that are bound to end up in namecalling.
a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there.
Usually the sleeps are for hardware settling, not for script startup. Eg. when you plug a USB device that may take a couple of seconds to be available after powering on. This will be needed *regardless* of what script is running the show. And dependency management on start scripts is a solved problem. Have a look at FreeBSD/NetBSD rc.d system, or Solaris SMF.
I was more thinking about starting postgres before the server that uses that DB to store its stuff. Grep for "sleep" in the init scripts of the sysv-init distribution of your choice: You will be surprised.
a more secure system by being able to isolate daemons from one another and the rest of the system.
So, its a startup daemon AND a kernel, huh?
Check out http://www.freedesktop.org/sof... , especially all the options starting with "Private" there.
a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them
Convenient for who? For you, because you cannot be bothered into using the existing tools? You may have some unusual requirements, it doesn't mean everyone else has the same needs. And while I'd applause a sort-of-standard way of bootstrapping Linux distros, adding complexity seems to be a pretty stupid approach.
Convenient for everybody. Just try the things that come with systemd. Most are a real improvement over the existing tools to manage hostname/date/time/timezone/locale/service/network/efi boot loader/virtual machine/whatnot. At the very least they are way more consistent in how they work and they work on all modern Linux distros in the same way. That was never possible before.
Yes, I know: Just suggesting to look into systemd is sacrelegious:-) Sorry, I won't do that again.
Let's just wait a year or two. By then all the hotheads that are running for the BSDs now will be back, everybody will be using systemd (including gentoo and slackware) since it clearly is the best approach available right now. When somebody finally comes along in 10 or 15 years with a good idea to replace systemd she will be yelled at for breaking away from the tried and true systemd that has been good enough for everybody this past decade.
Regards, Tobias
I just spent a merry 45 minutes trying to get Fedora 20 back up and running after a reboot. Systemd kept knocking it into Emergency Mode with no indication as to why. I'm still not certain whether it was a failing mount or a video card acting up. Or something else I don't know about yet.
SysV init is unquestionably feeble when it comes to controlling systems with complex daemon interdependencies. But putting stuff into sealed packages with No User Serviceable Parts Inside is not the way to go. I had to deal with that under OS/2 and it's one of the things I hated most about OS/2.
There is a tendency these days to offer a "complete solution" and to sneer at the ungrateful unwashed masses. But complete solutions never turn out to be complete enough. And these "Complete Solutions" are infamous for eliminating popular features that were in their predecessors. The systemctl facility admits that there are certain things that it cannot at present do that the cruder, but more flexible scripts of SystemV supported, and it's far from the worst offender.
Unix was developed on the philosophy that you didn't attempt to make one program do everything, you strung together simpler tools. Likewise, it logged to plain text files, which makes them accessible to a whole raft of text utilities, instead of a handful of specialized log utilities a la IBM. Besides which, a text file has to be seriously mangled before it's totally useless when everything's shot to Hell. Most binary files break far more easily and are far harder to repair.
If we forget where we came from, we're going to end up acquiring many of the same faults as Windows.