5 ms·

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

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 11y 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 11y 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 11y 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.

Pyxl101 11y 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 11y 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 11y 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.