Comment by its_magic
15 hours ago
The problem with the word "sysvinit" here is it's sort of a red herring. BSD init is better, in my opinion. I don't like managing all those symlinks. Plus, sysvinit is an old 90s application and its code does have some cruft built up over the years that could be removed and simplified. I'm devising a new init for my system that's much simpler than sysvinit and much closer to BSD.
"BSD init", "much simpler"... So does this mean you still expect applications to manage their own logs, daemonization and security setup themselves?
If yes, that's yet another init system not made for application writers.
Manage their own logs, daemonization, and security? The humanity! How will they ever manage all of that?
Come on man. It's been done for decades.
It doesn't take a giant bloated infrastructure to manage most people's needs, which are quite basic in most cases.
.. and that opinion is a great explanation of why systemd won.
Turns out, a lot of people are not happy with "Come on man. It's been done for decades." attitude, and they wanted something new and much better. And so when something new came up, they jumped on it with both feet.
It's instructive to read Debian CTTE discussion on init systems (btw I think it's best tech drama of 2013, highly recommend) - a lot of people dismissed the sysvinit early on because it had no features (example [0]), which means the choices were either upstart and systemd. And between two of those, systemd is a clear win.
Read the thread and look at how many highly technical people with no relation to Fedora or Poettering is ready to choose _anything else_ just to get away from "it's been done for decades".
[0] https://lists.debian.org/debian-ctte/2013/12/msg00234.html
1 reply →