SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
SoylentNews
The good people over at Infoworld have published a story outlining why they feel systemd is a disaster.
Excerpt from Infoworld:
While systemd has succeeded in its original goals, it's not stopping there. systemd is becoming the Svchost of Linux—which I don't think most Linux folks want. You see, systemd is growing, like wildfire, well outside the bounds of enhancing the Linux boot experience. systemd wants to control most, if not all, of the fundamental functional aspects of a Linux system—from authentication to mounting shares to network configuration to syslog to cron. It wants to do so as essentially a monolithic entity that obscures what's happening behind the scenes.
This discussion has been archived.
No new comments can be posted.
systemd: Harbinger of the Linux Apocalypse.
|
Log In/Create an Account
| Top
| 98 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
You know, the difference between this company and the Titanic is that the
Titanic had paying customers.
(Score: 3, Insightful) by NCommander on Tuesday August 19 2014, @02:10PM
There are legitimate design issues with the X11 protocol that makes things much more difficult than they should be. THe reason screen flicker is such a problem on Linux is due to this in part. With Wayland, the problem is the improvements can only been seen by those familiar with X11 and its "pitfalls", a pretty good explination is available on Phoronix [phoronix.com]
My problem with systemd is its upstream is an ass in the sense of "the my way or the highway". Unlike most folks, I actually find PulseAudio tends to improve life vs. make it more painful (but I use bluetooth headphones a lot; try making those without Pulse (aka, raw ALSA) and not ripping your hair out), but I accept the initial implementations were half-baked, and there are still a lot of issues though I see this more a fact that sound on Linux is braindamaged more than anything else (ALSA's APIs are horrorifying to say the least; given OSS is now GPLv2 licensed, I *really* wish the kernel folks would at least consider a move back).
Personally, I never understood the obsession with cold boot time; in Ubuntu, before we had several dev cycles focused on it, our boot time was ~30-45 seconds. I *kinda* get the point of it, but I feel that if a user has to reboot more than once a month (for kernel upgrades/etc), then we've done something wrong. In the server space, you usually have 5-10 minutes of firmware time dealing with RAIDs/SCSI/etc on a cold reboot before the OS even gets a crack at starting up. Now, I do agree sysvinit was getting long in the tooth; it was far too easy to hang a system due to dependency loops and such; I love when a system failed to boot because the network was down, and Canonical took up the challenge with upstart, written primarily Scott James Remnant, which was fully sysvinit compatible, a drop in replacement for init (something launchd, the other candidate wasn't), and it does one job and does it well.
I don't think I've ever seen anyone complain about upstart at any significant length. I was truly sad that Debian chose to adopt systemd, but I don't think they had much choice int he matter; they don't have the resources to patch GNOME and other userspace stuff that wants to depend on systemd. I accept a lot of things systemd is trying to fix, like logging, is stuff that could be improved, but you improve it by patching rsyslogd, not putting it all in PID 1. Honestly, at this point, I think the only thing that's going to kill this brain damage is if Linus does something insane to replace it, but systemd has RH backing it all the way, and doing everything to entrench it as much as possible.
Still always moving
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @02:23PM
I wonder: X11 was a successor of X10. So why not simply make an X12 which fixes the main problems of X11 while keeping the good parts of X?
(Score: 3, Informative) by forsythe on Tuesday August 19 2014, @02:37PM
That thought [x.org] has been tossed around a bit. I would be heavily in favor of it. Unfortunately for me, it looks like most recent effort is going into Wayland.
(Score: 2) by tangomargarine on Tuesday August 19 2014, @04:31PM
For those not wanting to Google it themselves, X11 was released in September 1987. X11 actually refers to the protocol it uses to get stuff done so if we were to follow the naming terminology X12 would be a protocol that may not be backwards-compatible (?).
Doesn't sound like a bad idea to me.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by No.Limit on Wednesday August 20 2014, @11:33AM
From NCommander's link (1st page bottom) [phoronix.com]:
Really good article, very recommendable.
(Score: 1) by cesarb on Tuesday August 19 2014, @02:56PM
Think desktops.
Arrive at work at morning, turn desktop on. Leave work at night, turn desktop off.
Also for laptops, if you're not going to use it for more than a few hours, it's better for the battery to turn it off completely.
The logging (systemd-journald) lives on a different PID, not PID 1.
(Score: 1) by cout on Tuesday August 19 2014, @03:08PM
And what do you do when you need to log something before the logger daemon has been started?
I have as strong a distaste for the systemd monolith as the next guy, but I kinda see why the devs are wanting to move in that direction. It's wrong, but natural.
(Score: 3, Informative) by NCommander on Tuesday August 19 2014, @03:30PM
Thanks for the correction on what goes in PID 1, systemd isn't QUITE as abraindead as I thought it is, but I've recently had my first RL experiences with it on Fedora (helping a friend managle postfix into working), and it managed to cause nothing but frustration in detecting new service files, and then confirming they run. I don't understand how it can be hard to do any of this; half the time, I was fighting systemd to get shit to properly enable (not knowing I had to tell it to rebuild its internal index), and then getting misleading messages from status.
What a mess.
Still always moving
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @03:49PM
Solved by a working hibernate to disk. Arrive at work, hit "on" button, unhibernate, work.
Leave at night, hibernate back to disk, power down, wait for morning.
Also solved by a working hibernate and working suspend.
Am I going away from it for 60 minutes - hibernate to disk.
Am I powering it off to take it through TSA's body cavity search? Hibernate to disk.
The solution is not to "cold boot faster". The solution is "never need to cold boot, ever".
If all this effort spent on rewriting an init had been spent on fixing issues with suspend/hibernate, image where Linux's suspend/hibernate would be now.
(Score: 5, Funny) by forsythe on Tuesday August 19 2014, @05:07PM
Tongue in cheek, I can imagine. We'd have ``hibernated'' running on PID 1 and it would be slowly engulfing cron, video drivers, input devices, udev, network management, and a host of other things. I don't think I want ``all this effort'' to be spent on anything close to what I use, actually. Effort is good, but not this effort.
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @05:37PM
That's YOUR solution(*). Not everone elses.
*) and currently mine as well. this thing wakes up from suspend under a second. if hibernate was an option i'd rather reboot since 16 gigabytes is a whole lot of shit to read from disk.
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @11:34PM
Except that, unless you are doing something really weird, most of that 16gigabytes is cached filesystem data. So step one in a hibernate is: sync dirty disk caches out to their backing files. After syncing all the cached filesystem data, what's left to actually write to disk is often far less data than 16G (on the order of 2-4G). That's a lot faster than a reboot, which entails restarting your "desktop" (in whatever form it is) as well as restarting any running programs and getting back to where you were in those running programs.
(Score: 0) by Anonymous Coward on Saturday August 23 2014, @07:18AM
Even 2-4GB is a gargantuan amount of data. Not only the actual working set of whatever you are doing is way less than that but most of it is also redundant. If we didn't have as braindamaged systems as we do, the computer could very well boot "instantly" to the point where you could continue doing whatever you were when you shut it down. You've just learned to accept that it doesn't.
Heck, even PCs used to do that pretty fast at some point. The slowest part might have very well been turning on the CRT since it needed some physical warm-up time to be usable.
(Score: 2) by VLM on Tuesday August 19 2014, @03:00PM
No coincidence the two lines below are found in the same post about upstart. They should have just stolen the name and started calling themselves "sysvinit 2.0"
"it does one job and does it well."
"I don't think I've ever seen anyone complain about upstart at any significant length."
There are some architectural issues with upstart. The vulnerability and reliability surface of "lets run us some bash scripts" is immensely smaller and better debugged and better reviewed than a big ole event driven state machine, so its inherently always going to be worse than sysvinit for all tasks other than rebooting quickly which isn't an issue anyway. Then again the bash scripts have their own interesting surface of vulnerability and NIH and repeated (sometimes buggy) implementation of the same tasks so the net result is probably about as bad. Or the TLDR is the security problems with upstart are not likely to be worse overall than bash scripts, but would be somewhat different.
The systemd guys need to read this line from the upstart docs
"This design is sensible and clean: the init system itself must not be compromised since if it fails, the kernel panics. Therefore, any functionality which is not considered "core" functionality is farmed out to other daemons."
And realize the only thing worse than a kernel panic is getting owned. Trying to shove more eggs in one basket, systemd style, is just dumb from a security perspective. And now they want to wedge logging in there to make it harder to trust the logs when you get owned. Thats great. Just great. I'm sure the KGB wants all IDS and firewall stuff in there too. Its almost like the NSA or the .ru people or microsoft are paying the systemd people to screw security up.
Fundamentally init of whatever system is just a batch operations queueing system where some jobs run forever, others are restarted, others run after other jobs successfully complete, etc. This is not exactly new tech in IT land. Someone should unify that experience between system and user (preferably without including emacsd and syslog and probably a mp3 player like the systemd guys would do) and make a really good universal batch system. A really good batch system in all machines would be quite helpful in my line of work because I just end up installing "torque" or something anyway on my data-processor-nodes. I am pretty sure torque would not be the ideal /bin/init replacement, given how well it jams itself and how poorly it recovers from problems, but the general idea stands. Or rephrased upstart could be hacked into a weirdly usable batch processing system in userspace. Every time I swear at torque I'll think of how I'd rather be using some userspace variant of upstart. Likely because upstart hasn't crashed and jammed and pissed me off (although in production with random user submitted jobs maybe it would)
(Score: 2) by WillR on Tuesday August 19 2014, @03:15PM
(Score: 4, Insightful) by VLM on Tuesday August 19 2014, @05:18PM
LOL thats kind of the point, if bash has a priv esc hole, its going to be found probably well before it becomes an "init system" issue. Also if it has a hole it was probably found in December of 1995 which is great seeing as I've kept up with patches since them. Systemd, probably none of the above. You'll find your bugs the hard way.
"that only one or two maintainers really understand" No they're not that hard. And fairly well standardized. Much simpler to learn and understand than the internals of the replacements. Which is scary.
(Score: 4, Funny) by mrider on Tuesday August 19 2014, @07:31PM
Because all-new code is bug free, while old code accumulates bugs like barnacles.
Doctor: "Do you hear voices?"
Me: "Only when my bluetooth is charged."
(Score: 2) by NCommander on Tuesday August 19 2014, @03:23PM
There are legitimate problems with sysvinit, specifically, dependency tracking is a hack and fragile at best, requiring ordering by hand to make sure things come up right. A dependency based system like launchd/upstart is worth it in my opinion since it drastically reduces boot fragility. Upstart DOES have some issues (try using Ubuntu in a chroot without replacing initctl with /bin/true), but all things considered, it was the "right" approach. Debian experimented with replacing sysvinit with upstart, and nearly did so right about the time systemd started becoming a thing.
Once I'm free and clear of professional obligations, I'm going to take to running FreeBSD for awhile, and try to get some perspective on things.
Still always moving
(Score: 1) by cout on Tuesday August 19 2014, @03:05PM
I agree that the big benefit of pulseaudio is bluetooth support. But I'm yet to use any bluetooth device under desktop linux in A2DP mode that doesn't drop out due to overflow. And while that's likely the fault of bluez or blueman or whatever and not pulseaudio, it means that bluetooth support isn't a particularly convincing argument for me to have all the additional latency imposed by pulseaudio.
(Score: 2) by NCommander on Tuesday August 19 2014, @03:28PM
A lot of the experience is just being able to sanely reroute audio from point to point; on my desktop, sending some streams to headphones while other to HDMI is a breeze with pulse. The fact though is we shouldn't need pulse to do this, almost everything pulse does with the exception of network audio routing can be done directly by ALSA; the problem is the API is poorly documented, and what few tools are even worse. In my little bubble of the world though, pulse has been relatively trouble free, and it does solve some actual problems.
Still always moving
(Score: 2) by Nerdfest on Tuesday August 19 2014, @04:04PM
Likewise. I use PA heavily, including its BlueTooth support. I use BlueTooth headphones and a BlueTooth receiver on my stereo and it works very well other than dropping the signal when I walk between the machine and the receiver sometimes. Apparently I'm very radio opaque.