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: 5, Insightful) by jimshatt on Monday May 30 2016, @10:36AM
It seems to me that the Linux forked libc because they thought they needed it, then later realized that was a mistake and returned to the better unforked version.
This is how it should work. If the changes you (think you) need are not generic enough to be in the upstream version, you fork the code. If that turns out to be a mistake, at least you haven't polluted upstream. And this is EXACTLY why the systemd integration into tmux should be in a fork. So that when the nightmare is over (if ever) we can kill the fork and enjoy the purity of upstream tmux.
(Score: 1, Interesting) by Anonymous Coward on Monday May 30 2016, @08:09PM
GNU, due to a combination of issues getting ahold of standards, questionable developer decisions, and forging ahead in a new field, fell behind in the development of glibc and gcc during the early to mid 90s. As a result of this glibc was lacking in a lot of POSIX conformancy as was gcc in regards to c and c++ standards (via the seperate package, at the time, g++).
The long and the short of it is that the linux libc4/5 lead to GNU getting off their asses and polishing up their turd (glibc) enough for linux to jump back to the original version rather than continuing to maintain their fork (which due to 'need it now' syndrome had ended up as a legally questionable mass of source code all stiched together as a not actually even close to conformant libc, defeating the original purpose of forking it anyhow.) egcs acted the same way for gcc during the 96-98 period cumulating in the gcc 2.95 releases, which eventually got broken again by redhat as the gcc-2.96 release and by debian as the gcc-2.95.4 release (which was never AFAIK a real gnu version number, having jumped to 3 for what was to become the gnu-98 support. But ended up as one of the clusterfucks of ABI breakage we've had until today thanks to Redhat rushing things with the 2.96 release which helped lead to 3.0-3.3 ABIs all being slightly broken. And the expectation that most/all C++ code has to be compiled with the same compiler.)
(Score: 0) by Anonymous Coward on Monday May 30 2016, @10:13PM
Well, thank fuck that now C99 is enough for anybody.