SoylentNews is people
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.
Croll's Query:
If tin whistles are made of tin, what are foghorns made of?
(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