This is always the case with any new software. Things may get a bit worse before they get better. Honestly Systemd addresses the complexities of a modern system in the simplest fashion but no simpler, and that is the key. It is in the same spirit as launchd on macOS. It works well overall and end up being more portable and consistent in the long run. Hatred for it seems to come mostly out of dogma, something to be avoided in this age.
> addresses the complexities of a modern system in the simplest fashion but no simpler
I have a serious contention with the statement that systemd is the simplest possible solution for this problem. Especially since it involves not only service management, but user logins, a data bus, logging management, file system mounting, initd, and a host of other things.
Are all of those pieces necessary? Arguably yes. But not all in one system(d).
Thing is, though, most of those things are different systems. systemd-logind systemd, systemd-udevd, and journald (and others) are different systems in the same project. They're a bit tied together (through dbus and I'm not sure what else), but that doesn't mean they're the same system.
> This is always the case with any new software. Things may get a bit worse before they get better.
So why should I currently opt for the worse solution? Is the overall design of it promising?
> Honestly Systemd addresses the complexities of a modern system in the simplest fashion but no simpler, and that is the key.
What complexities does it address? I lost track of everything an init system is apparently responsible for.
> It works well overall and end up being more portable and consistent in the long run.
Since systemd only runs on Linux APIs, I can't figure out what this even means. There are init systems that run perfectly fine in plain POSIX environments. systemd is not one of them.
I'm not going to discuss the merits of portability or what "typical developers use". I'm questioning the idea that systemd is somehow more portable than its alternatives. That belief can only be rooted in plain ignorance of the actual situation. It has absolutely nothing to do with what typical developers use, and to that end your comment is a pointless derailment.
What I mean is that there are init systems that only require POSIX compliant APIs and as such are portable across systems that implement POSIX, e.g. GNU/Linux, BSD, Solaris, AIX...
systemd requires (in addition to POSIX) Linux APIs and is therefore not particularly portable by any reasonable definition of the word. You can use it if you are running a Linux kernel, and that's it.
> What I mean is that there are init systems that only require POSIX compliant APIs
Those are irrelevant as they can't even do basic tasks like shutting down the computer or restarting it.
Feel free to find a POSIX API for Linux' reboot syscall.
Some systems also require mounting additional filesystems, again not possible in a world limited to POSIX interfaces.
launchd doesn't break nohup. It doesn't have any opinions about processes started from shells. systemd does, which is completely inappropriate scope creep.
I agree with the systemd developers on this one. It's weird that processes started by users when their logged in by don't end when they log out unless they voluntarily terminate when sent a signal.
And nohup was always a hack. Now that we actually have a functioning user-level service manager keeping processes alive by throwing them at PID 1 to parent needs to go away. I really hope that systemd eventually uses subreapers to keep all user processes under the session leader.
I feel like it's weird to talk about scope creep when logind is pretty much the first system to define what a session even means on a Linux system.
If a process is interactive, it needs a way to be notified that its user is gone. That became a distributed system problem a while ago. PID 1 doesn't know whether an X client is active on a remote display, or a batch job is doing useful work.
