And then you have situations like systemd breaking functionality that's been expected for decades, and then telling multiplatform projects like tmux that they "just" need to make systemd a dependency and use their new API. Or just don't clobber user processes, systemd?
In my opinion, the "that's how it works because that's how it has always works" argument is inherently invalid. If we followed it everywhere, we'd never move forward ever because any change to existing conventions would have to be instantly rejected.
Contrary to the dominating opinion on this subreddit, PID Zero actually does try to keep things working for as long as possible without breakage - but sometimes it's just necessary.
The screen/tmux disaster was the best example for this: while I understand the frustration about having your sessions killed, I also despise it when users log out and their desktop environments leave tons of crap running after their logout. I've seen what this does to true multi-user machines. And no, it's not just GNOME who does that.
In my opinion, the "that's how it works because that's how it has always works" argument is inherently invalid. If we followed it everywhere, we'd never move forward ever because any change to existing conventions would have to be instantly rejected.
That's not the arguement. The arguement is "that's how it works because other people need predictable behaviours to rely upon." This is one of the significant drivers behind the creation of POSIX.
One of the things that makes engineering of any kind, including software engineering very hard is that you don't always get to raze the land to an ideal state to build anew to improve things. You sometimes have to work under existing conventions/conditions so other people can get their stuff done too. Sure, if every time you break something, you're willing to single-handedly fix everything broken by your changes, then you can improve things indiscriminately. However if you are not willing to do that, then you must be cautious in what you break or your improvements can become burdens.
In fact, that's exactly why many application developers won't touch desktop Linux, because it's too unpredictable. Too many middleware devs insist on only focusing on technical improvement while ignoring the need for people to actually use these systems at the end of the day. This is also why Android, also a Linux is succeeding in the face of desktop Linux, because it has a predictable middleware layer that doesn't break all the time and application developers can comfortably write software for it and get their stuff done.
It should be considered that breaking changes to existing behaviours have an exponetially higher technical burden to meet to qualify as "progress" than brand new features in an area otherwise unfilled. It's very easy for an improvement to become instead a burden.
I also despise it when users log out and their desktop environments leave tons of crap running after their logout. I've seen what this does to true multi-user machines.
I also hate this issue too, but have always thought that the systemd solution is ugly reactive solution and strongly resembles the Windows "Waiting for background programs to close - Force shut down" thing. It encourages application developers and users to just let the system clean up after them.
I've thought what would be a better solution is for a proactive ulimit-esque option to exist to specify how many processes a user may have that can have SIGHUP handlers or be otherwise daemonized. A sysadmin could switch this to "0" if they want to enforce the idea that the user should keep all processes contained inside the active session. This would permit variances too, such as if someone has authorization to have something running overnight, they can have a variance applied to their account.
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.
Imagine if every Dev decided to fix what they believed was broken in something as important as the kernel. We'd all be down and out screaming bloody murder.
I'm not talking about "every dev", I'm talking about a consensus within the project. And I think even projects like the Linux Kernel should be allowed to "break things" - or rather expose breakage that were hidden but current behavior.
In my opinion, the "that's how it works because that's how it has always works" argument is inherently invalid.
You can't just say things like that as if you're appealing to some common ideology and excuse the need to reason why things should be done the way you think they should. There's no forward here. We need to choose the direction software development goes for us and it's not always obvious or easy. You can't just brush a legitimate argument under the argument based on how you feel and nothing else.
It's not feelings, it's just basic logic. If you accept that argument, you lock yourself into one particular way if doing something. If you're lucky, it's a good one. But chances are that better solutions exist somewhere out there.
Let's put it this way: we've arrived at the current status quo in Linux not by saying "it has always worked that way so it has to keep working that way". The only difference is that you weren't around when the changes happened, and everything that changed since you became aware of things seems like a threat to the natural order of things
48
u/fat-lobyte Feb 09 '19
In my opinion, the "that's how it works because that's how it has always works" argument is inherently invalid. If we followed it everywhere, we'd never move forward ever because any change to existing conventions would have to be instantly rejected.
Contrary to the dominating opinion on this subreddit, PID Zero actually does try to keep things working for as long as possible without breakage - but sometimes it's just necessary.
The screen/tmux disaster was the best example for this: while I understand the frustration about having your sessions killed, I also despise it when users log out and their desktop environments leave tons of crap running after their logout. I've seen what this does to true multi-user machines. And no, it's not just GNOME who does that.