SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 15 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.
We lie loudest when we lie to ourselves.
-- Eric Hoffer
(Score: 5, Informative) by VLM on Tuesday August 19 2014, @12:28PM
Here's the wikipedia summary of the linked article:
http://en.wikipedia.org/wiki/Inner-platform_effect [wikipedia.org]
And I directly quote wikipedia: "The inner-platform effect is the tendency of software architects to create a system so customizable as to become a replica, and often a poor replica, of the software development platform they are using. This is generally inefficient and such systems are often considered by William J. Brown et al. to be examples of an anti-pattern."
Another example I can provide is see the "wayland" project pitifully attempting to replace X as another example.
(Score: 2, Interesting) by epitaxial on Tuesday August 19 2014, @12:45PM
I agree systemd is a pile of shit that needs to go but X really does need a ground up rewrite. We're dealing with 30 years of legacy bullshit and slowness.
(Score: 5, Insightful) by VLM on Tuesday August 19 2014, @01:13PM
And by a study of the inner platform effect I guarantee the loudly trumpeted solution to "bullshit and slowness" will inevitably slowly buggily and ineffectively eventually reimplement the same "bullshit and slowness". Just watch, it'll be fun.
Just ask yourself, whats changed in the use case? Oh, nothing? Well then.
(Score: 5, Insightful) by forsythe on Tuesday August 19 2014, @02:30PM
I agree with your appraisal of X (and systemd, for that matter), but I'm also growing increasingly wary of ``This is broken, let's rewrite it to be awesome because we're geniuses!''. Systemd (vs. init), Pulse (vs. ALSA, OSS), Wayland (vs. X) any new DE (vs. the previous version), new udev (vs. old udev), etc. all leave a bad taste in my mouth. X certainly has the best argument for replacement, but I'm not convinced that Wayland is the necessary replacement.
Libressl (from the OpenBSD folks) is the only major rewrite project (that I can think of right now) which I'm actually anxious to use.
(Score: 5, Informative) by PinkyGigglebrain on Tuesday August 19 2014, @07:00PM
Lets not forget GRUB, it used to be great, everything in one config file. Want to change the default wait time, a kernel argument or add an entry all you had to do was edit one file and reboot. Done. Now you have to find the right "configlet" file, among 20+ other files in different directories, edit that file, then call some utility that takes all the configlets and creates the single config file that you can't edit directly anymore. And the documentation is a steaming pile. The improvements added between the versions didn't warrant a complete rewrite of the configuration process. First thing I do on a new install is purge it and install grub-legacy. I can live without being able to boot from an ISO in grub, I've got VMs for that.
"Beware those who would deny you Knowledge, For in their hearts they dream themselves your Master."
(Score: 3, Informative) by zafiro17 on Tuesday August 19 2014, @07:43PM
Glad to hop on this bandwagon. OP is totally right. I just downloaded and installed LinuxBBQ the other day (www.linuxbbq.org) and by default it installs LILO and I found myself gushing over how simple and easy LILO is compared to Grub legacy, too. I accepted Grub over LILO because it did away with the risk of forgetting to re-run lilo and borking your system. But it was never clear to me why Grub needed to be updated. In fact somewhere out there is a little utility you could run on a floppy disk that would let you boot Linux or a dozen other OSes. Forget what it's called, but in theory it provided more improvements over grub than the new version of grub ever did. Fooey on all this "improvement." Get offa my lawn, while you're at it.
Dad always thought laughter was the best medicine, which I guess is why several of us died of tuberculosis - Jack Handey
(Score: 1, Interesting) by Anonymous Coward on Tuesday August 19 2014, @10:03PM
a little utility you could run on a floppy disk that would let you boot Linux or a dozen other OSes
Sounds like you're talking about PLoP Boot Manager.
Smart Boot Manager is another that is commonly mentioned.
There's a scad of them. [wikipedia.org]
-- gewg_
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @11:28PM
If, instead of replacing your working kernel, you added a second kernel entry at the end of your LILO config, then if you forget to rerun LILO the worst that happens is you have to boot into your old kernel, run lilo, then reboot.
(Score: 2) by Pav on Wednesday August 20 2014, @11:59PM
more complicated without adding much (directly related) benefit = breakage
(Score: 2) by Subsentient on Saturday August 23 2014, @05:44AM
Use syslinux, you swine. Syslinux will crush you all!
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 2) by cykros on Tuesday August 19 2014, @07:46PM
I'm not sure it's fair to compare pulse to ALSA/OSS, as they operate on separate levels and really aren't there to do the same thing at all. If anything, it's worth blaming the distros for really going out of their way time and again to break things.
I personally use Pulse on Slackware (making me in a very small minority). Because Pulse allows me to do things (using ALSA) that ALSA cannot do by itself, such as output my music from one sound card (speakers) while another audio stream (perhaps a private video call) to a headset, all at the same time.
Thing is, Pulseaudio works fairly reasonably for what it tries to do (once ALSA is reasonably configured to output to it). The biggest issue with it seems to be that distros are assuming that people need this functionality badly enough to make user after user spend hours figuring out why they're getting no sound at all from a fresh install that is more complicated than it actually needs to be in the first place. While it's gotten better over the years, it still seems nuts considering that most users really just would be fine with a working ALSA configuration using dmix for hardware mixing, and if they needed pulse, should be able to just grab it themselves (just like people do with Jack...).
As for most of the rest of your examples though, I'll mostly agree. While I don't mind the exercise of making new tools to try to do it better, or just increase the options out there, it is a little scary watching as the distros line up to all adopt the same thing as all of the rest regardless of the fact that it's unnecessary and adds more confusion and general bugginess to the mix. Whatever happened to "if it's not broke, don't fix it"?
(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.