3 ms·

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

by jle17 10y ago

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.

thwarted 10y ago
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.
- Pyxl101 10y 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 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.
  - nickpsecurity 10y ago
    Btw, here's the answer to your recently deleted question: http://www.throwww.com/a/7bn 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.
  - nickpsecurity 10y ago
    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.

by jle17 10y ago

thwarted 10y ago

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.

Pyxl101 10y 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 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.
- nickpsecurity 10y ago
  Btw, here's the answer to your recently deleted question: http://www.throwww.com/a/7bn 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.
- nickpsecurity 10y ago
  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.