> Nohup was invented in response to a new SIGHUP which broke persistent processes. And today, it is accepted as the Right Way.
Correct
> This is no more an insult than removing cgroup write access from processes or any other new kernel feature.
False. Empoyees of a 2 billion dollar corporation deciding to demand free labour from the community to accommodate what they've decided by fiat is the new Right Way is incredibly insulting. The tmux developers do not exist to serve your whims. The community is not here to save you money.
> Systemd is trying to build a new feature that is useful - reaping processes after logout should help improve security and performance.
There's NOTHING new or innovative about this! Processes are already reaped at logout, unless they're nohup'd. Changing the state of affairs to "processes are reaped at logout, unless they use dbus to ask systemd to not reap them" is just a bunch of mechanism churn to get the same result
> Think about Chrome having flags to "run background processes after app is closed".
What would stop Chrome from doing that under this new regime? Literally the only difference is that they'd be accomplishing that via systemd-specific code rather than portable, SUS-compliant code.
Ultimately all this change is accomplishing is deprecating simple, portable interfaces for achieving nohup behaviour with baroque, dbus-laden, systemd-specific ones. Red Hat's goal here seems to be little more than increasing systemd's surface area; otherwise, why not simply hide the sausage-making systemd cruft behind the portable API?
> Systemd is trying to maintain backwards compatible behavior by collaborating with developers.
"Collaboration" is not a synonym for "I have altered the user space contract. Pray I do not alter it further".
> We should not do these things cost "that's the way they've always been" is killing innovation.
"Innovation" is not a synonym for "instead of a daemon(3) call, here's 150 lines of dbus crud to get right back to where you were before".
> There's NOTHING new or innovative about this! Processes are already reaped at logout, unless they're nohup'd. Changing the state of affairs to "processes are reaped at logout, unless they use dbus to ask systemd to not reap them" is just a bunch of mechanism churn to get the same result
The difference is that pre-systemd, there is no safe way to guarantee that all processes are reaped on logout if some of the processes are written maliciously to try and avoid being reaped. The new cgroup-based system makes it impossible to evade being reaped by playing games with fork. This mechanism is valuable, but it is possibly not the best default for most systems.
The difference is that pre-systemd, there is no safe way to guarantee that all processes are reaped on logout if some of the processes are written maliciously to try and avoid being reaped.
And this is a red herring. If the process is malicious, it can just as well use this systemd method to keep from being killed and continue to do its dastardly deeds in the background. Logically, this "feature" can not be about controlling purposely malicious programs, because there's no way to determine if a process is malicious or not just by asking it or by having it assert that it is not. The only reason this exists is to paper over bugs in either the way these daemons are spawned (ssh-agent and pgp-agent, for example, work best when they appear in the execution inheritance hierarchy, rather than as separately spawned programs that run as siblings) or in the way they detect that a session has ended.
You can't guarantee reaping while allowing for opt-out semantics for things like tmux. Everyone who thinks that's some innovation being achieved here is misunderstanding it.
This is originally about some GNOME daemons sticking around when they shouldn't. GNOME should just fix that, of course, but it points to the hole of it being all-or-nothing when it comes to nohup'ing. There's no good mechanism for asking for more limited lifetimes.
Of course, the Right way to solve that would be to leave the existing API alone for the all/infinite lifetime case, float a proposal for a new API for the limited case, raise consensus, implement it, and encourage devs like GNOME to move to the new limited case.
But that might mean actually talking to the community and building an encapsulated API that could be reimplemented on other platforms. So much easier to break everything and demand the world keep up, with the added benefit of all those raw dbus calls and hard-coded end points making portability off of your 2 billion dollar cash-cow OS just a bit incrementally harder, again.
False. Empoyees of a 2 billion dollar corporation deciding to demand free labour from the community to accommodate what they've decided by fiat is the new Right Way is incredibly insulting. The tmux developers do not exist to serve your whims. The community is not here to save you money.
Isn't the usual answer to this, "If you don't like it, fork it?"
If you work on a large FOSS project, you will spend a lot of your time reacting to decisions made by other people. You won't agree with all of them. Some of those decisions will be made by $2B companies, some of them will be made by influential individuals like Linus and Lennart. Still others were made 20 years ago by some anonymous person in their basement.
Either way, if your complaints fall on deaf ears, your options are limited to living with it or forking it. That's just how it works.
> Isn't the usual answer to this, "If you don't like it, fork it?"
Zbigniew Jędrzejewski-Szmek, systemd developer, is asking for tmux to change to incorporate some systemd-specific Desktop Bus code. Nicholas Marriott, tmux developer, replies that this should go in the GNU libc daemon() function for everyone whose programs do this to benefit, repeating what he said 5 years ago.
Following your model, which should Zbigniew Jędrzejewski-Szmek be forking? tmux? Or GNU libc?
I was just thinking this. It seems to be tempting fate and encouraging a "$2B company" to make changes that suit their objectives.
It does seem like what is being requested is not a sensible change, but arguing with insults and getting so personal seems like poking a rather large bear with a very short stick because it is trying to make you move away from it even though you were there first. You can do that, but it's unlikely you will enjoy the outcome.
Correct
> This is no more an insult than removing cgroup write access from processes or any other new kernel feature.
False. Empoyees of a 2 billion dollar corporation deciding to demand free labour from the community to accommodate what they've decided by fiat is the new Right Way is incredibly insulting. The tmux developers do not exist to serve your whims. The community is not here to save you money.
> Systemd is trying to build a new feature that is useful - reaping processes after logout should help improve security and performance.
There's NOTHING new or innovative about this! Processes are already reaped at logout, unless they're nohup'd. Changing the state of affairs to "processes are reaped at logout, unless they use dbus to ask systemd to not reap them" is just a bunch of mechanism churn to get the same result
> Think about Chrome having flags to "run background processes after app is closed".
What would stop Chrome from doing that under this new regime? Literally the only difference is that they'd be accomplishing that via systemd-specific code rather than portable, SUS-compliant code.
Ultimately all this change is accomplishing is deprecating simple, portable interfaces for achieving nohup behaviour with baroque, dbus-laden, systemd-specific ones. Red Hat's goal here seems to be little more than increasing systemd's surface area; otherwise, why not simply hide the sausage-making systemd cruft behind the portable API?
> Systemd is trying to maintain backwards compatible behavior by collaborating with developers.
"Collaboration" is not a synonym for "I have altered the user space contract. Pray I do not alter it further".
> We should not do these things cost "that's the way they've always been" is killing innovation.
"Innovation" is not a synonym for "instead of a daemon(3) call, here's 150 lines of dbus crud to get right back to where you were before".