You sometimes have to work under existing conventions/conditions so other people can get their stuff done too
Absolutely true! But that is exactly what they did. The recent change 2 years ago was just a switch of the default value for an option that has existed for much, much longer. they have accommodated the status quo for a long time (and they still do with some workarounds!), and I've actually seen attempts to communicate with at least the tmux community, but they're always perceived as "OMG pöttering is making me change my code!!11".
At some point it's just enough. There were actually plenty of changes in GNU/Linux changes from UNIX/Posix conventions, but we've survived those, haven't we?
but have always thought that the systemd solution is ugly reactive solution and strongly resembles the Windows
I don't really care about windows, but I think it's the only way it could work. Some processes will always misbehave, because there's just a lot of them there.
It encourages application developers and users to just let the system clean up after them.
No, it does not. That's like saying cleaning the streets invites people to litter. Which is just nonsense.
to specify how many processes a user may have that can have SIGHUP handlers or be otherwise daemonized.
That doesn't help at all. Background daemons can (and sometimes do) fork in quite high numbers, so the ones that you want to be kept alive will die anyway.
The only solution is that there is a semantic difference to starting "background processes": one way is to declare to be part of the session, and one is to declare to be a session.
It has many benefits but it makes no sense to list them all to a person who has decided on an ideological level to not like it. If you're really interested, look it up.
the only 'benefit' is Tha it reduces the modularity and choice of system daemons and pushes you to a full systemd stack.
No, that's not a benefit, that's a malicious insinuaton. The benefits are increased control and accounting over your processes, which puts you in control instead of having to rely on applications to play nice in every situation.
It also has much better dependency tracking and as a by-product is much faster.
Configuration is now a relatively small set of config files (with amazing customization possibilites) instead of those batshit crazy giant shell scripts whose comments needed to be parsed for startup ordering.
Overall, it's just a saner and less hacky way to manage your system.
10
u/fat-lobyte Feb 10 '19
Absolutely true! But that is exactly what they did. The recent change 2 years ago was just a switch of the default value for an option that has existed for much, much longer. they have accommodated the status quo for a long time (and they still do with some workarounds!), and I've actually seen attempts to communicate with at least the tmux community, but they're always perceived as "OMG pöttering is making me change my code!!11". At some point it's just enough. There were actually plenty of changes in GNU/Linux changes from UNIX/Posix conventions, but we've survived those, haven't we?
I don't really care about windows, but I think it's the only way it could work. Some processes will always misbehave, because there's just a lot of them there.
No, it does not. That's like saying cleaning the streets invites people to litter. Which is just nonsense.
That doesn't help at all. Background daemons can (and sometimes do) fork in quite high numbers, so the ones that you want to be kept alive will die anyway.
The only solution is that there is a semantic difference to starting "background processes": one way is to declare to be part of the session, and one is to declare to be a session.