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 canopic jug on Monday May 30 2016, @07:26AM
Debian et al, wake up before RH signed RPMs become a hard dependency.
Three points on that:
Too late for Debian. Nearly all the Developers that know what's going on have left. Many ended up at Devuan [devuan.org] which just released a beta [devuan.org]. The combined torrent for Devuan-beta is huge, but just select pieces can be downloaded instead of the whole thing.
The Developers at Devuan are making very good progress, but have a very tough row to hoe. As you can see from the links in the summary, systemd is working its hooks in all over the place. tmux probably won't bend over, but many other packages have. So far it's been two steps forward and one step back as Devuan straightens out one package only to find a new one infected. However, they are making headway. Perhaps by then, many of the Debian derivatives will have seen through Poettering and Red Hat.
Red Hat likes and aims for the complexity [blogspot.ru]. Their more extreme ideas won't work if they go it alone, so they infect as many other distros as they can. More complexity means fewer can support their own work environments and more will have to sign contracts with Red Hat. Also, some of Red Hat's major customers benefit from the bugs that come with the added complexity.
Money is not free speech. Elections should not be auctions.
(Score: 5, Informative) by coolgopher on Monday May 30 2016, @08:20AM
You can also download the ~200MB netinst ISO, dd it to a USB stick, boot off that and install directly from the net, downloading only what packages you need as you go along. Did that over the weekend, worked well.
(Score: 3, Interesting) by RamiK on Monday May 30 2016, @08:23AM
With all due respect, the Debian's development model failed long before systemd. Ubuntu's malignant growth opened the way to Red Hat's influence in the first place and it wasn't external forces that made it happen.
20 years ago this kind of dependence on a strict hierarchy of trust-worthy maintainers was necessary. Nowadays, you have Arch, NixOS and GuixSD all allowing an open and wider contribution base while putting the developer's choices at the forefront. The latter two even solve the technical problems of *nix distributions while they're at it. And GuixSD actually gets rids of systemd in favor of Shepherd.
Honestly, this is like the carriage drivers union fighting city hall over who gets to clean the manure, while automobiles are available in the market. It's a throwback to ancient practices that were born due to the technical constraints of the time. It's 2016. We can fork packages. We can maintain forked packages of different version in our repositories. We can install different versions side-by-side of everything. And yet, here we are, fighting about who picks up the manure... Absurd.
compiling...
(Score: 3, Informative) by zeigerpuppy on Monday May 30 2016, @11:50AM
Not quite. Package management is non trivial and standards really help.
We're only in a bad situation because the wrong standard got up and compromised the unix philosophy at the same time.
I've also given Devuan a try on some VMs that needed upgrades from Debian Wheezy. So far it's been mixed. Some went well but the hooks of systemd can be deep and I had to ZFS rollback a couple of times (luckily that's fast!)
(Score: 2) by Unixnut on Monday May 30 2016, @12:51PM
That works on the pretext that Devuan does not become large enough to be self sustaining. If Debian does go down to "SystemD or the highway" model, and if enough people want to avoid SystemD, I can imagine that Devuan gets big enough to keep on going without Debian.
(Score: 1, Interesting) by Anonymous Coward on Monday May 30 2016, @03:41PM
Yeah, I expect Linux to essentially hard-fork into two separate operating systems you could call Linux-done-right and Poetterix.
(Score: 4, Interesting) by srobert on Monday May 30 2016, @03:59PM
If Linux were "done right" it would be FreeBSD.
(Score: 2) by Unixnut on Monday May 30 2016, @07:14PM
So... GNU/Linux, and SystemD/Linux :)
I would be fine with that personally, along with Android/Linux, and the other versions. That was there is no more confusion over what is "Linux" and which way is right, etc...
Let each version exist, name it clearly but with a way of distinguishing between them (including that they are not interoperable with each other), and everyone can move on. It is like a repeat of the Unix Fragmentation in the 70s-80s, but with all source code GPLed, so if enough people want to put in the coding effort, you can port apps and other bits between them.
My main concern is that SystemD/Linux will start depending on binary blobs, which may break things in future. As long as the Kernel stays core to all 3 OSes, then binary blobs like the Nvidia Drivers will work on all of them, so a win win for all.
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @06:40AM
Is this concern based on anything related to reality?
Or is it just you making random stuff up?
(Score: 3, Informative) by cubancigar11 on Monday May 30 2016, @01:44PM
For all that rosy eyed promises of heaven, NixOS by defaults uses systemd.
WHAT... A.. WASTE.... OF MY... TIME!!!!!
(Score: 2) by Bot on Monday May 30 2016, @03:07PM
Then try guix which doesn't use systemd. I tried installing guix as a separate package manager on a systemd less distro, but I had to give up because it started pulling a lot of packages. All the packages compiled fine till I had to reset, though.
Guix and IIRC void linux can be installed as package managers alongside your existing distro.
Account abandoned.
(Score: 2, Troll) by RamiK on Monday May 30 2016, @09:48PM
Nix can be installed side-to-side too. People even install it on Macs for some reason.
But please take my original post in it's context. I was criticizing the enterprise of forking Debian into a separate, systemd free distro as pointless since the underlying system is antiquated and socially relies on strict hierarchies that aren't conducive to health development models. My purpose was to argue for taking part, or forking Guix or Nix for the purpose of non-free packages on a modern systemd distro. I didn't argue for choices you can install right now.
However, in the realm of actual choices to use right now for end-users as an alternative to systemd that has firmwares and such, use arch [systemd-free.org] or just stick to slackware. Guix is still beta and pulls lots of package sources since they didn't stabilize a release for hydra (the build servers) to focus on compiling so it's impractical unless you're an active developer.
Incidentally, it's why I ignored the other response. I'm very argumentative by nature and usually make a flame war out of anything really, but I won't be bothered responding to axioms begging the question that I didn't even hint on.
Also, as a fair disclosure (of sorts), I have no issues with systemd. I've wrote units for it. I've run it in Debian while I'm running it now in NixOS. I even packaged stuff for it on a couple of distros. On the side, I'm doing some Guix stuff in a VM because I want to see a Debian-Ubuntu relationship evolve around a GuixSD-YetToBe package channel that stabilizes backports and packages non-free kernels and firmwares. I feel this will be the healthiest thing for the linux ecosystem right now since it will make sure all the work naturally flows back into the free base, as opposed to how things are now where free packaging is done after the fact.
As such, when I see work put into new Debian fork, it really pains me. If people are too lazy to figure out how to pull it off in Nix or Guix, just stick to using and packaging for Arch. There's no winning with forking Debian. You'll either fail to get a user-base, or succeed and end-up reliving all the conflicts we've had in Debian in the past since that's what that kind of design does.
compiling...
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @07:01PM
noone has hurt you, stop acting. what pain do you feel? you are free to do what you want as long others do. noone is giving pain to each other.
this is a passive aggressive attitude to say you are right and others are wrong
fucking systemd shiller
(Score: 2) by fnj on Monday May 30 2016, @10:39AM
Realistically, devuan, like ubuntu, is no more than a parasite on debian. They couldn't exist without debian. They can't CONTINUE to exist unless debian continues to exist. And in the case of devuan, debian controls whether it can continue to exist without systemd at all. If debian throws in with forces which promote systemd to grow malignant tentacles into every crevice, it could easily become prohibitive for devuan to keep it untangled.
(Score: 2) by Bot on Monday May 30 2016, @03:28PM
Devuan probably can't free all systemd dependent stuff, but as long as it lets people run a fairly complete stack without systemd, it is good.
I have been twice through the non mainstream crowd, first blackisting windows for MacOs, then dumping OSX for Linux. It paid off both times, in the long run.
Account abandoned.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @03:02PM
What about Upstart?
I was surprised no mention of Ubuntu's former init daemon replacement here. [devuan.org]
(Score: 3, Interesting) by JNCF on Monday May 30 2016, @04:54PM
The relevant excerpt from OP's link about Red Hat aiming for complexity (emphasis original, to show questions):
Do you think the Red Hat model would apply equally well to other areas of software?
Red Hat's model works because of the complexity of the technology we work with. An operating platform has a lot of moving parts, and customers are willing to pay to be insulated from that complexity.
I don't think you can take one finite element - like Apache - and make a business out of it [using our model]. You need product complexity.
I'm amazed how open they are about this obvious incentive that their business model creates. It seems like the sort of thing you wouldn't want to shout from the rooftops, if you were in the business of making open source software more complex than necessary. They don't say that they make anything more complex than necessary, but they spell out a motive quite clearly.
(Score: 1) by pvanhoof on Monday May 30 2016, @07:21PM
Men, it must be pure slavery for the poor Devuan developers to do git clone repo.git and then use git log to find the commit ids of commits related to systemd. Then do git checkout -b devuan and then revert all the commits related to systemd. Then run dpkg-buildpackage. Poor poor Devuan "developers"! The horror they have to endure is for me, as actual mantainer of some in-Debian packaged softwares, unthinkable. They actually have to do the slave-work that we maintainers have to do every single f. week, once.
To think that if they'd rewrite the revert patches with some #ifdefs, that we maintainers would reject their contributions and tell them to abstract it a bit must be pure hell.
Imagine that we fucking maintainers would ask them to, if they see a program-init.c, that they'd make a program-init.h with some abstractionitis and then have a program-init-systemd.c implementation and a program-init-openrc.c implementation. And then maybe we'd consider it (if they also patch configure.ac or the program.pro or the CMakeLists.txt file in the root of the sources a bit, and follow our semantic-versioning guidelines).
Can you imagine the pure hell they have to go through? It's so horrible! I know. It's what the guys who are actually working on systemd packaging do, all the times.
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @05:56AM
They refuse to fix the bastille-linux perl and TK scripts, as they don't like the person suggesting it.
They pooh-pooh the idea of hardening scripts alltogether.
(Score: 2) by Bot on Tuesday May 31 2016, @10:05AM
If you don't like devuan, then help out antix, or make its fatter cousin mxlinux more systemd independent. Or look at what mr. Knoppix is doing [youtube.com]
Account abandoned.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @10:14PM
Well, Devuan certainly managed to release an impressive 4.5 GB netinst image :D (Yes, their "DVD image" doesn't actually use the contents of the DVD.)
Did they manage anything of note besides that?
(Score: 0) by Anonymous Coward on Monday May 30 2016, @10:54PM
You must live in a parallel reality...