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.
Im not sure who at debian proposed this idea, that packagers be required to maintain support for non-systemd applications, but its untenable at best. It would mean a redesign of gnome, KDE, and a dearth of other code that in many cases makes no sense (how does networkManager get this treatment outside the scope of systemd?) this particular vote also smacks of an attempt at debian character assassination. the fact is that Debian, and Ubuntu, need to sit down and recognize is that open source software means If i, or users, want rc-init support in Debian for a package we can code it.. If the package doesnt do what we want we can either commit, fork, change packages, or change operating systems. Bureaucratic red tape seems to be an Ubuntu specialty thats strong-armed its way into debian from the start of Systemd. pointless electoral procedures avoid the cusp of the communities argument. SystemD is controversial enough that Debian should give the user the choice to decide whether they want systemd.
Good people go to bed earlier.
My feelings on this matter? :(
I intensely dislike systemd and all of its methodology - it's not the Unix way, and I really dislike the systemd developer's attitudes towards bugfixes and other problems with their processes. Systemd is a solution looking for a problem.
As an admin in a company with something like 50,000 *nix machines, of which I have root on about 10,000 of them, systemd will not be making an appearance on any of these systems and the vendors have been appraised of this fact. Any vendor that cannot provide an alternative to systemd will not be in the running for the next phase of server rebuilds.
Personally, I think I'll be migrating all my own personal servers and the servers of my University's computer society to something a lot more useful and not requiring systemd to boot. Going to be a fun time.
- This sig deliberately left blank. Nothing to see, move along.
You are aware that most of the systemd daemons do NOT run on PID 1 (and none of them on PID 0), right?
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! ~~
BS. During the early 2000s the discussion of complex scheduling like existed in Solaris came up again and again. There was general agreement that while Linux was fine for simple Linux servers and workstations that the lack of advanced features made it unsuitable to replace big box Unix. Linux induced a financial collapse in big box Unixes now it needs to replace their complexity and functionality.
It is expected. Most systemd whiners have not explored systemd. They don't know how it works nor have they administered it. If they would have done that, they would have found that systemd is just fine. Actually systemd is much more professional than sysvinit and the hacky collection of hobbyist scripts surrounding it.
Funny thing, i could have sworn that even Torvalds claimed he would stop using ifconfig when they pried it from his cold dead hands. And i can see why. The ip command is convoluted to the extreme. Just looking up the interfaces and their addresses seems to need some switch or other, never mind toggling a interface state or changing the address.
Don't worry, there will be plenty of those. Here's one:
I am testing Jessie with systemd and find that systemd absolutely refuses to mount a btrfs filesystem in degraded mode even though I explicitly set the option in fstab.
Can anyone tell me how to either force it to at least attempt mounting or to have it leave fstab alone and call my script to do the mounting?
No, dropping to an emergency shell so I can mount it manually over IPMI is not an acceptable alternative.
Ummm, the fact that almost every distribution is adopting it and not giving you an alternative???
So support only those distros that refuse to incorporate systemd. Then superiority by omission will win out, and the systemd haters will prove right in the end. Right?
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
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.