Slashdot Mirror
Debian Votes Against Mandating Non-systemd Compatibility
paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.
This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.
However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.
Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.
This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.
However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.
Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.
That SystemD is bad for Linux not because of the technical merits but the political BS drama it's spawning. Technical wise I can see why server admins want to have the fine grain control of their start up through individual scripts. It makes sense to me even though I don't do administration. KISS is the order of the day and flat text files beat out binaries any day. Now for desktops SystemD seems fine to me for people who run out of the box systems.
Honestly the whole thing sounds to be a fix that works better for some things but is getting shoved in to other areas where it isn't needed, wanted, and maybe even detrimental to the operation of other systems. Kinda like when Ubuntu/Gnome went with more touchy modern interfaces on desktops when really it was tablets and phones their interfaces made the most positive impact while negatively effecting others on the desktop.
I think it's time for some people to get over the one size fits all mentality in the Linux community. Obviously other people have problems with it and it's going to end up tearing you apart in the long run while scaring off others who sit on the sides playing with the toys you folks made up to this point. That's going to leave companies like Microsoft grinning like a Cheshire Cat.
~~ Behold the flying cow with a rail gun! ~~
I fail to understand the reasoning for choice as well.
I think I get this.
One example: I have a handful of shell and perl scripts that I use to manage virtual machine interdependencies at startup time - this vm needs to be listening on this port before I can think about starting this other vm, etc. and I express that in a JSON tree for configuration.
I've recently been noticing that the dependency "engine" is a bit buggy and also duplicates much of what systemd already provides (pre-dating it by some years), so I'm going to look at making it work with systemd instead and cutting out a bunch of the code. That also gets me pretty easy dependency tracking on various filesystem mounts, network status, etc., so it could be better than 'sleep 20' in some spots.
Now, if I wanted to offer that up to the community, somebody could choose to package that into Debian. Assuming my experiment works, systemd would be a hard requirement to use this particular system.
Somebody in the Debian community proposed that for this package to be accepted I would also have to [re]write another dependency engine and support that. I can't see doing that if the systemd approach works.
Does it make sense that people who don't want to run systemd (which is fine) also can't impose additional work on developers who do want to use systemd?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
They want a process to handle things like shutdown, reboot and hibernate via a UI dialog. Previously, Consolekit was that process. But Consolekit was scuttled in favor of Logind. And Logind is dependent on Systemd running as pid1.
Btw, the guy that had the reins of Consolekit at the time of its closure was Poettering...
There are long term non-systemd distributions. Crux and Alpine for example. The mainstream distributions are having it foisted on them by upstream because open source developers do think it is that good. This isn't about system admins.
The sysadmins are the meal ticket of developers. For years now, we've been saying we don't want systemd unless it can be made compatible and standalone. Now Red Hat calls me and wonders why I choose to install RHEL 6 on new systems, given that RHEL 7 is out. Why? Because we told you in advance what we wanted, and you chose not to listen.
Sysadmins are in a position to choose their operating systems. The developers are not in a position to choose their customers.