I am not upset that there was divergence from POSIX.
Design choices are fine - I can understand why systemd takes a different approach.
What I don't like, and completely disagree with, is systemd not working with the community they directly effect to reduce disruption.
Like it or not, the product is an industry standard, and so will be held to industry expectations.
Rather than turning around and requiring everyone to change, they could have said, "Sorry, we're making changes, here are some preliminary patches that could help."
Or a timeline for a breaking change, wherein they can negotiate with others.
I don't have significant issues with systemd's software, though some reservations about quality. My main concern, and it has been since the beginning, is that systemd acts without thought or conscience to the effects that they might cause.
They lack the ability to be a team player, despite creating an environment where people depend on them.
systemd's adoption rates is an absolute credit to it. They have some very good design thoughts, and those working on it have done some excellent work.
However, it would be better if they communicated with the people they effect, rather than letting the community be an accidental Q&A team when things go wrong.
They do get this right sometimes, but that seems to be the exception, rather than the rule.
They approached the init.d situation calmly, and slowly. They worked with Debian, and Fedora and others to make sure it would work without interruption or loss of quality.
They approached the sigkill situation like they were a kid who just learned how to light a fire and wanted to burn the library down.
You make plenty of assumptions there, in particular that there was no communication about the session killing thing. Turns however there was. We informed downstreams about our intention and the reasons in detail, and we documented this for everybody else in NEWS. We also made sure there was an easy compile-time option to pick the default for this option, and then left the rest for the downstreams to decide: whether to default to on or off to this, taking in the information we got from us and from the rest of the community. If you think they made the wrong decision, then complain to them really. But seriously, you really just assume we wouldn't talk to anyone, without actually having any idea what it communication is really taking place.
> We informed downstreams about our intention and the reasons in detail, and we documented this for everybody else in NEWS.
From The Hitchiker’s Guide to the Galaxy, regarding the plans to destroy the Earth:
‘But the plans were on display …’
‘On display? I eventually had to go down to the cellar to find them.’
‘That’s the display department.’
‘With a flashlight.’
‘Ah, well, the lights had probably gone.’
‘So had the stairs.’
‘But look, you found the notice, didn’t you?’
‘Yes,’ said Arthur, ‘yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying “Beware of the Leopard.”’
Back in the real world: you built & shipped a system whose defaults were and are broken, and now you blame others for not enabling the DONT_BE_WRONG setting. You might as well blame end users for not becoming fully-versed with your code before their first login.
It’s not the users’ fault. It’s not the distros’ fault. It’s yours, and your project’s, for shipping code which breaks the user experience.
I appreciate your vision. It’s a good one. You’re a smart guy. But have some humility! Have a sense of your own limitations, and those of the distros and users who will use your code. You’re a human being; the distros are made up of human beings; your end users are … human beings. Think of them.
This is kind of a ridiculous reply. Is the only solution then to admit that Linux is "done"? Because it sounds like there's no room for change, even when change is communicated and multiple options to avoid it are provided.
> What I don't like, and completely disagree with, is systemd not working with the community they directly effect to reduce disruption.
> Rather than turning around and requiring everyone to change, they could have said, "Sorry, we're making changes, here are some preliminary patches that could help."
> Or a timeline for a breaking change, wherein they can negotiate with others.
But they did exactly that.
They contacted the tmux mainteners and asked if some modifications would be possible to accomodate the new option (see poettering comment here: run things as child of systemd --user or just register a separate PAM session). If I remember correctly, it would not even have been the first special case in tmux ; there already is one for OSX.
The discussion was actually progressing nicely until the anti-systemd flooded it. I remember seeing posts in a lot of place urging people to comment on the bug report with specious arguments. The whole thing was kind of upsetting.
Design choices are fine - I can understand why systemd takes a different approach.
What I don't like, and completely disagree with, is systemd not working with the community they directly effect to reduce disruption.
Like it or not, the product is an industry standard, and so will be held to industry expectations.
Rather than turning around and requiring everyone to change, they could have said, "Sorry, we're making changes, here are some preliminary patches that could help."
Or a timeline for a breaking change, wherein they can negotiate with others.
I don't have significant issues with systemd's software, though some reservations about quality. My main concern, and it has been since the beginning, is that systemd acts without thought or conscience to the effects that they might cause.
They lack the ability to be a team player, despite creating an environment where people depend on them.
systemd's adoption rates is an absolute credit to it. They have some very good design thoughts, and those working on it have done some excellent work.
However, it would be better if they communicated with the people they effect, rather than letting the community be an accidental Q&A team when things go wrong.
They do get this right sometimes, but that seems to be the exception, rather than the rule.
They approached the init.d situation calmly, and slowly. They worked with Debian, and Fedora and others to make sure it would work without interruption or loss of quality.
They approached the sigkill situation like they were a kid who just learned how to light a fire and wanted to burn the library down.