Hacker News Reader

Comment by d33 | Hacker News Reader

Based on last time when someone decided to rethink PID1 and wrote systemd, I'm kind of afraid of any research in this field...

EDIT: flicked through the article and yup, it's 2010 and systemd is announced: "You probably guessed it: what I suggested above as requirements and features for an ideal init system is actually available now, in a (still experimental) init system called systemd, and which I hereby want to announce."

2016 and I'd still say it's mostly experimental, but unfortunately reached production machines now.

View on HN

Did you not read the article? It's from 2010 and written by Lennart Poettering, introducing the basic concepts behind systemd.

Well I would say it's functionnal and hasn't reached enough production machines.

I don't understand the hate that systemd seems to bring in people. It may not be perfect but the good largely outweights the bad and anyway most of the arguments against it are the same copy pasted critics from day one, when they aren't pure name calling against its author.

From a user perspective I for one am glad to be able to start and kill services in a reliable maner, to have structured logging and a set of base system components that are simple to use, coherent and well documented and make taking advantage of otherwise painful to use Linux features easy.

Most anti-systemd people seem to be adverse to change and would rather stay on SysV init, but seriously how much longer are we expected to stick with that symlink mess of ugly scripts that can't reliably start a service in a reproducible environment or track which process belongs to which service ?

I often see anti-systemd people advocate a move to FreeBSD, but there is a reason behind the existence of the nosh or launchd projects... BSD init might be cleaner than SysV but it suffers from some of the same problems.

and anyway most of the arguments against it are the same copy pasted critics from day one

The age of an argument doesn't negate the argument, especially if it has not been effectively addressed since it was first proposed.

Those arguments are copy and pasted because they are still solid arguments and they have been pretty much ignored or handwaved away.

That you're tired of hearing them doesn't mean that they shouldn't be addressed. Those making the arguments are getting tired of having to repeat them—just like the tech industry is tired of having to continuously debate the government on cryptography: the arguments for liberty still stand, despite being codifed two centuries ago.

This seems like a pretty strong and specific technical argument in favor of systemd: https://lists.debian.org/debian-ctte/2013/12/msg00234.html

What's the best single page summary along with adequate details of the arguments against systemd, and what's the professed alternative? From Googling around, I haven't found anything with a comparable level of technical quality, depth, and concreteness.

Btw, here's the answer to your recently deleted question:

http://www.throwww.com/a/7bn

Had to do some long shifts before digging it out. Not sure why you deleted it given it was a decent question. Still "self-censoring?" :P Anyway, you can email my profile address about it if still curious on technical angles and such.

Interesting link btw. I think the number of features is oversold a bit. Others here pointed out that, being so critical, it's best to have first process be simple as possible with another doing the complicated stuff. So, those features could be delegated into an isolated process via message passing.

However, it stood out that the shell scripts are complex and buggy in edge cases. Quite opposite of robust programming we normally want. The socket activation trick is nice. I could see following Systemd's lead to improve in those two areas with a regular, minimalist init. Other features in other processes. See where that goes before letting one component go octopus on everything else.

Reply on news.ycombinator.com