SoylentNews is people
SoylentNews
The spreading of systemd continues, now actively pushed by themselves unto other projects, like tmux:
"With systemd 230 we switched to a default in which user processes started as part of a login session are terminated when the session exists (KillUserProcesses=yes).
[...] Unfortunately this means starting tmux in the usual way is not effective, because it will be killed upon logout."
It seems methods already in use (daemon, nohup) are not good for them, so handling of processes after logout has to change at their request and as how they say. They don't even engange into a discussion about the general issue, but just pop up with the "solution". And what's the "reason" all this started rolling? dbus & GNOME coders can't do a clean logout so it must be handled for them.
Just a "concidence" systemd came to the rescue and every other project like screen or wget will require changes too, or new shims like a nohup will need to be coded just in case you want to use with a non changed program. Users can probably burn all the now obsolete UNIX books. The systemd configuration becomes more like a fake option, as if you don't use it you run into the poorly programmed apps for the time being, and if they ever get fixed, the new policy has been forced into more targets.
Seen at lobsters 1 & 2 where some BSD people look pissed at best. Red Hat, please, just fork and do you own thing, leaving the rest of us in peace. Debian et al, wake up before RH signed RPMs become a hard dependency.
(Score: 2, Disagree) by pvanhoof on Monday May 30 2016, @06:54PM
The policy and crafting of an API around it, is precisely what developers want and need. They don't want twenty different ways of interacting with containers and services. And they definitely don't want to write goddamned hundreds of fscking scripts that suck the blood out of veins.
Instead, they want to package policy in clear and well defined configuration. Then they want to make-distcheck that. Then distributions will install it and will provide clear and well defined overrides. You know, like almost every modern package and system does. Even ld.so.conf has support for something like /etc/ld.so.conf.d.
This /etc/init.d/ stuff, stinks.
No. fucking. scripts.
(Score: 2) by Geotti on Monday May 30 2016, @10:27PM
This /etc/init.d/ stuff, stinks.
[puts on sysadmin head]
Fuck you!
(Score: 2) by Geotti on Monday May 30 2016, @10:29PM
s/head/hat/
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @09:55AM
No, the original was much better.
Swapping head spaces every so often is healthy exercise
(Score: 3, Insightful) by Anonymous Coward on Tuesday May 31 2016, @09:52AM
Errr no. I do not want any of that.
Perhaps you could ask me what I want next time instead of speaking for me.
(Score: 2) by sjames on Tuesday May 31 2016, @05:31PM
No. Policy is to be determined by the sysadmin. APIs are supposed to be the interface to the mechanism by which policy is implemented. That mechanism needs to be policy neutral.
This was figured out a long time ago and it works well. Mechanism setting policy is broken by design.