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: -1, Flamebait) by fnj on Monday May 30 2016, @06:53AM
You really are a brain damaged idiot.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @06:57AM
Those were the days! When fucking LINUX needed its own LIBC because GNU wasn't good enough for fucking LINUX. Remember how fucking LINUX forced GNU to change LIBC for fucking LINUX?
You whiny hypocrites.
(Score: 4, Interesting) by Anonymous Coward on Monday May 30 2016, @07:02AM
Quote copied from Wikipedia because fucking asshole hypocrite dumbshits can't be expected to follow a link.
Fork "Linux libc"
In the early 1990s, the developers of the Linux kernel forked glibc. Their fork, called "Linux libc", was maintained separately for years and released versions 2 through 5.
When FSF released glibc 2.0 in January 1997, it had much more complete POSIX standards compliance, better internationalisation and multilingual function, IPv6 capability, 64-bit data access, facilities for multithreaded applications, future version compatibility, and the code was more portable. At this point, the Linux kernel developers discontinued their fork and returned to using FSF's glibc.
The last used version of Linux libc used the internal name (soname) libc.so.5. Following on from this, glibc 2.x on Linux uses the soname libc.so.6 (Alpha and IA64 architectures now use libc.so.6.1, instead). The *.so file name is often abbreviated as libc6 (for example in the package name in Debian) following the normal conventions for libraries.
According to Richard Stallman, the changes that had been made in Linux libc could not be merged back into glibc because the authorship status of that code was unclear and the GNU project is quite strict about recording copyright and authors.
(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.
(Score: 1, Touché) by Anonymous Coward on Monday May 30 2016, @08:00AM