Since systemd, I just do a service file.
So despite all its shortcommings, I now have a standard, well documented, init system that I can use accross all the distros I use, which happens to provide all the features I need.
I'm sure all the power user complaints about systemd are legitimate, but I really don't care about those. I just want an easy way to setup custom deamon on ubuntu and centos.
Provide a better system, that solve those problems, and I'll use it. I really don't care as long as my problem is solved.
Same couldn't be said about supervisor, the solution you already had running (well, maybe strike init)?
And it's not installed by default because it doesn't solve the problem of a service dependancy graph.
I doubt that supervisor is not installed because of not solving something it evidently does not want to solve, but that argument at least looks valid to me. Just in case you are not aware, https://github.com/Supervisor/supervisor/issues/122 lists two solutions (wait_for_it.sh and a supervisor plugin that adds dependency resolution).
The more systems something sits under the more places there are for it to cause a problem because it doesn't work quite how the upper components expect. At a bare minimum, you'll often run into problems with the included package management system (and how it may reload systems for security purposes after patching) if you don't take care.
nano sits on top of everything, and the few things that might rely on it use a very standard and not very extensible interface (the EDITOR environment var). It's not really equivalent at all.
Not sure what your point is (well ok, I am, and I agree), but you just lost
Rewatch the first half of the video and imagine it was a bunch of random tools with proper names (like grep, ntpd, syslogd) etc, that had all been built separately but happen to nicely tie into each other, rather than "systemd-blah"
There isn't and wasn't hardly anyone saying that. It is and was well known that there were better things out there than the hacked up sysV style init systems produced by the various Linux distributions.
This is a common strawman that seems to get rolled out any time any discussion involves systemd.
It's not just a strawman, unfortunately. I wish it were.
Systemd on the other hand seems to be trying to take over syslog, ntpd, dhcpd, named, and related with generally poorer implementations. Feature creep seems constant with systemd, for no particularly good reason.
1: https://lists.freedesktop.org/archives/systemd-devel/2014-Ma...
2: https://www.reddit.com/r/linux/comments/6kdcme/why_does_syst...
And the claim that they are 'inferior solutions' is just absolutely false in most cases. It often replaced horrible old tools that haven't been updated in 30 years. It often provides far better interfaces and tooling then the existing solutions.
This isn't necessarily a problem with the systemd project, it's more on the distros that bundle these service, but when you have the same branding across multiple systems, you have to take the bad with the good.
Had they called it "multidnsd" or "ntpclientd" then people wouldn't think "systemd sucks because when MyDistro 9 came along", they've blame multidnsd and let the systemd init system stand on it's own.
You can always disable them at runtime or during compile and use your own though.
The problem with systemd it is not just an init system. Its network-state-aware, device-state-aware container launcher(nspawn), cron, logind and syslog implementation.
The scope creep of systemd is enormous, nobody asked for that when they wanted reliable daemons.
On the other hand, I've had no issues with logind and gdm. I've been interested in trying S6 but given it's quite easy to substitute out the bad parts of systemd, so I just haven't bothered.
Probably the biggest problem with systemd is that it's hurting BSD. Then again, gnome devs are having enough trouble getting things working on Linux... also binary format journals are so dumb. How have they not changed that?
Nobody would make what Lennart did if we had a choice. Those who liked Systemd would use it, and the rest would use the init of their choice. As simple as that.
I agree that a more modern init system is necessary, but the idea of systemd is meh and the implementation is subpar.
The maintainers of Arch Linux have given an explicit list[1] of the reasons why they decided to introduce systemd:
0) it is hotplug capable
1) we can know the state of the system
2) it is modular
3) it allows dbus/udev to go back to doing the task they are meant to do
4) we can reduce the number of explicit ordering dependencies between daemons
5) we get a lot of security/sandboxing features for free
6) systemd service files can be written and distributed upstream
7) systemd is a cross-distro project
8) logind will finally deliver on what consolekit was supposed to do
9) systemd is fast
There are other things that are meant to be left around, as that's their purpose, such as screen and tmux.
I would say the safe solution would be to kill everything in the user session at multiple levels (GNOME, and user session management demon like logind, etc), and to provide a defined safe way for the very few programs that want to stick around to do so. That seems like what systemd came up with as well.