5 ms·

> IMHO sysvinit and systemd both suck in that they're both overly obscure, overly arcane, overly complex, and poorly documented. Systemd replaces a legacy pile

> IMHO sysvinit and systemd both suck in that they're both overly obscure, overly arcane, overly complex, and poorly documented. Systemd replaces a legacy pile of hacks mess with an over-engineered tower of babel mess. This is an easy criticism to make. What's no so easy is to actually implement what's needed for a modern system and still achieve what you seem to be asking for. Modern systems are unbelievably complex beasts. > An improvement would be something with modern syntax, sparse features, and good docs. This is getting pretty silly and it just looks like you're reaching for anything to criticize here. What does "modern syntax" mean and why would it be an improvement on the INI-like syntax of systemd configuration? What earth does "sparse features" mean? You don't want to support everything that a modern system requires? (Take modern system to mean everything from containerized servers to desktops to laptops to a mobile phone. All places where systemd has its place.) You don't think systemd has "good docs"? IME Systemd has unbelievably good reference documentation for any type of Free Software (in the Unix style of man pages, no less!). Perhaps tutorial-like documentation is somewhat lacking, but the "systemd for Administrators"[1] blog series is pretty good IMO. (Though, granted, a bit out of date, perhaps.) [1] http://0pointer.de/blog/projects/systemd-for-admins-1.html http://0pointer.de/blog/projects/systemd-for-admins-1.html

snuxoll 10y ago
Speaking from experience, classic sysvinit was the bane of my existence when trying to deploy Python web applications. Having to use things like supervisor because writing init scripts is such a pain is a hack, nothing more. Writing a 10 line systemd unit file packaged in with the RPM I use to deploy my app is much less of a headache, and I welcome the change - combined with parallel startup I don't have to block nginx from loading while my application loads (or vice-versa).
- nitrogen 10y ago
  Ubuntu's Upstart was also pretty nice in this regard.
  - themartorana 10y ago
    Thank you. I feel like this gets overlooked. It worked well, and was easy to grok. Too bad it lost support.
    - JdeBP 10y ago
      See the "red herring" discussion in http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ and https://news.ycombinator.com/item?id=11641426 https://news.ycombinator.com/item?id=11641426 on this very page. It's definitely wrong to think that upstart was overlooked when it came to the Debian hoo-hah, furthermore. Upstart was one of the four major contenders, and one of the two front-runners.
  - lomnakkus 10y ago
    It was certainly nicer than sysvinit, but its event-based model absolute hell to debug, IME. (It basically required the user to program a state machine around all the events that could happen on a system.) Just look at the bugs on Upstart in the Ubuntu bug tracker if you don't believe me. There were bugs in there that languished for years because they were basically unsolvable. The original author of Upstart basically admitted (to his credit!) that systemd's model is superior after Upstart had been in out in the wild for a few years.
  - snuxoll 10y ago
    Upstarts event-driven mess made it extremely hard to debug and rationalize about your dependencies for a service. systemd's approach of a basic dependency graph for services is a lot easier to work with, plus some bonus features like socket activation and work directory creation that upstart doesn't have. I have a python webapp hosted inside uwsgi reverse proxied by nginx, adding `RuntimeDirectory=mycoolapp` to the unit file automatically creates and destroys `/run/mycoolapp` every time the unit starts and stops. I just plop my socket file inside the runtime directory (which is automatically created with the correct uid/gid based on the user/group the unit runs as) and fly away, I don't have to manage some directory inside /var/ and deal with an rpm scriplet to ensure the correct owner/group are set on it after install. It's all the little things that systemd does that really make one appreciate it, they add up.

snuxoll 10y ago

Speaking from experience, classic sysvinit was the bane of my existence when trying to deploy Python web applications. Having to use things like supervisor because writing init scripts is such a pain is a hack, nothing more. Writing a 10 line systemd unit file packaged in with the RPM I use to deploy my app is much less of a headache, and I welcome the change - combined with parallel startup I don't have to block nginx from loading while my application loads (or vice-versa).

nitrogen 10y ago
Ubuntu's Upstart was also pretty nice in this regard.
- themartorana 10y ago
  Thank you. I feel like this gets overlooked. It worked well, and was easy to grok. Too bad it lost support.
  - JdeBP 10y ago
    See the "red herring" discussion in http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ and https://news.ycombinator.com/item?id=11641426 https://news.ycombinator.com/item?id=11641426 on this very page. It's definitely wrong to think that upstart was overlooked when it came to the Debian hoo-hah, furthermore. Upstart was one of the four major contenders, and one of the two front-runners.
- lomnakkus 10y ago
  It was certainly nicer than sysvinit, but its event-based model absolute hell to debug, IME. (It basically required the user to program a state machine around all the events that could happen on a system.) Just look at the bugs on Upstart in the Ubuntu bug tracker if you don't believe me. There were bugs in there that languished for years because they were basically unsolvable. The original author of Upstart basically admitted (to his credit!) that systemd's model is superior after Upstart had been in out in the wild for a few years.
- snuxoll 10y ago
  Upstarts event-driven mess made it extremely hard to debug and rationalize about your dependencies for a service. systemd's approach of a basic dependency graph for services is a lot easier to work with, plus some bonus features like socket activation and work directory creation that upstart doesn't have. I have a python webapp hosted inside uwsgi reverse proxied by nginx, adding `RuntimeDirectory=mycoolapp` to the unit file automatically creates and destroys `/run/mycoolapp` every time the unit starts and stops. I just plop my socket file inside the runtime directory (which is automatically created with the correct uid/gid based on the user/group the unit runs as) and fly away, I don't have to manage some directory inside /var/ and deal with an rpm scriplet to ensure the correct owner/group are set on it after install. It's all the little things that systemd does that really make one appreciate it, they add up.