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.
Go back 5 years and imagine yourself trying to explain systemd to all the Linux developers. One massive program running at PID 0 doing 100 different jobs from startup scripts to DNS resolution complete with binary log files and a completely different (but the same) set of tools o manage them (grep less awk tail). You would be laughed at and run out of town. Nobody would ever take you seriously again.
Can't wait for all of /etc to disappear and be merged into a single binary file like the Windows registry. I first ran into this nonsense when playing with a BeagleBone Black board. Go ahead and see if you can figure out how to change the ip address. In case you can't here is how you do it:
http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/
Tell me why any of that is necessary? It's exactly like how Windows manages network interfaces.
This is the same community that you can still start a street fight, or at least a troll war, by asking "Which is better: emacs or vi?" I'm not sure they're ever going to get over this. But, like the above question, the world will move on and leave them behind.
"Be particularly skeptical when presented with evidence confirming what you already believe." -
some developers are already trying to mend the community and soothe the wounds.
I'm not sure that giving people warm fuzzies should take priority over steering the ship in a direction that has proven successful for more than a generation, and which has allowed diversity to flourish.
more insightfult news and posts from lwn. Regarding burnout and voicing concerns over systemd. lwn.net lwn.net
It's a bit more of a meta-outcome. The option that won the vote said, more or less: the General Resolution (GR) process in Debian is not the right way to resolve this dispute.
There was a proposed option which would actually have explicitly said: packages are not required to maintain non-systemd compatibility. But that option did not win.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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.
Linux has become the laughingstock of the computing world thanks to the Systemd Fiasco.
An entire operating system trashed by a single incompetent clown and his shit pet project rammed down distro throats by his foaming at the mouth fanboys.
A healthy open source community would never have let this fiasco happen.
Hello FreeBSD. A pure Unix operating system run by grownups only interested in technical excellence.
There seems to be a little foaming at the mouth going on right there in your own post.
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! ~~
Systemd works OK in Fedora, so I don't see a serious need to run to Slackware, but if I was running a server, then I would probably use FreeBSD anyway, not Linux.
Not.
I got reminded why I didn't like this idea yesterday.
System wouldn't reboot. Flipped to the alternate consoles to see the logs and command shell. GONE.
Finally figured it out. It was a USB device and it had to be unplugged or the whole boot process would hang without any information displayed.
I've said it before and I'll say it over and over. I like the concept of a wireable process management system. But what systemd did to logging is an abomination. I didn't like binary logs in OS/2 and I still despise them.
Well, ifconfig on Linux hasn't had a release since 2001, and is considered deprecated by the Linux devs. Some distributions provide its former functionality via iproute2, which is sort of a successor. However it's pretty low-level. In some environments (esp. servers sitting in a colo) it's perfectly fine. It tends not to do what people expect from a network stack on movable devices though: saved wifi networks and wifi autoconnect, sane management of hotpluggable interfaces, etc. For that, you need some kind of wrapper around it, which is what network-management daemons provide (in varying forms).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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.
That's the case now but soon desktop environments will start using logind and applications may start using journald. As systemd continues to offer more tightly-coupled modules, applications will likely start relying more on these modules until the point that systemd will likely be a requirement for almost all applications and desktop environments.
Yes, there are emacs/vi fights, but in truth these are in fun. There is not a single vi user who would say that they should build a distribution where emacs did not work. There is not a single emacs user who would say it is OK to build a distribution where vi did not work. Everyone in this community would really say, even though you may be stupid for making your choice, our distribution should work under whichever you choose.
This General Resolution was about making certain that the distribution still worked even if someone chose to use a different init system. I am not sure why that is contentious.
They already are. A lot of the FreeBSD people are sysadmins and there's already conversion stories where these FreeBSD guys admin datacenters and some of their clients are already completely switching to FreeBSD because their sysadmins hate systemd. Then the clients realize how awesome FreeBSD is and start tell their friends, who are also sysadmins. ZFS is like crack, once they've tried it, there's no going back.
Linux distros seem to be going the way of "We're awesome, so we'll alienate all the non-awesome people and then everyone will be awesome!". Only to realize later that they gutted what made them great in the first place. They don't realize how important it was to have things the way they were because they didn't use them. Screw those power users! Who needs them anyway? Like a corporation that just let go all of their engineers and now only have marketing and sales. How long will it last? Who cares! It looks great on the quarterly report!
Rubbish. FreeBSD is insecure crap. You should be using OpenBSD.
OpenBSD is run by that thug Theo, you should try NetBSD.
What a jerk - only a loser would use NetBSD, it's DragonFly or nothing.
Watch this Heartland Institute video
Or try it with some fava beans and a nice chianti.
Watch this Heartland Institute video
You're barking up the wrong tree. I don't think you remember how things were before PulseAudio.
You had /dev/dsp or later /dev/snd. Since the kernel doesn't do sound mixing, they were one user only, unless the soundcard provided mixing. Which a lot of them didn't. So esd, artsd and similar appeared. Running KDE and want sound in the one Gnome app you use? Have fun making esd run against artsd. Want to run an old game or app that only knows about /dev/dsp? Sorry, artsd has it busy. You make it auto-close the device when unused? Unreliable as hell. USB audio? what is that? Certainly no plugging and unplugging support there. For a while dmix was all the rage. Thing is, dmix is implemented in the ALSA libraries, which means it does nothing for you unless your app uses ALSA libraries, so it doesn't help your any with your /dev/dsp using app.
PA was created to solve all this mess. PA basically handles everything and provides interfaces for everything, so finally pretty much all apps can talk whatever protocol they like, and work. And audio can be reconfigured as you plug and unplug devices.
Was it unreliable for a while? Yes. But there is still nothing better. The kernel doesn't mix audio. You need a daemon by design, and you need something PA-like to provide a modern level of functionality. The only way to do without PA is have the kernel implement all that, and as far as I know, the kernel devs don't want it.
https://lists.debian.org/debian-ctte/2014/11/msg00091.html
I am resigning from the Technical Committee with immediate effect.
While it is important that the views of the 30-40% of the project who
agree with me should continue to be represented on the TC, I myself am
clearly too controversial a figure at this point to do so. I should
step aside to try to reduce the extent to which conversations about
the project's governance are personalised.
And, speaking personally, I am exhausted.
The majority of the project have voted to say that it was wrong of me
to bring this GR at this time. Despite everything that's happened, I
respectfully disagree. I hope that the next time a controversial
issue arises, someone will step forward to advance what might be a
minority view.
Thanks to everyone who has served with me on the TC. I wish those who
remain on the TC the best for the future and I hope that you'll find
colleagues who are as good to work with as you have been to me.
I now hope to spend more of my free software time doing programming.
dgit is at the top of my Debian queue, but some of my GNU and SGO
projects could do with attention too.
Thanks,
Ian.
It's funny that you mention Wayland.
systemd is all about putting the kitchen sink into the startup proces.
Wayland is all about removing the kitchen sink from the window manager. (seriously, why does it include a network protocol?)
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
I don't think you remember how things were before PulseAudio.
No, we remember quite clearly. ALSA worked just fine, with only one easily fixed issue: distros needed to set asourdrc to use dmix by default. Those of us that have multiple soundcards and pre demanding requirements (music pa/production)went through the minor trouble of setting up jackd, which solved all the rest of the problems regarding synchronization and very-low-latency data processing.
Really, the only thing that ALSA needed was a nice GUI editor/frontend for the config file. Those of us that used jackd already had such an editor (qjackctl, among others).
Oh, what's that? You want to claim that PA forced better drivers? That may be true, but it is not a feature of PA, nor a reason to use it. (driver fixes are orthogonal, to which software uses the drver) . Some of us actually read the hardware compatability lists before buying our hardware, too, and never had a problem with stabilitgy.
PA basically handles everything and provides interfaces for everything,
Yes, it is a wrapper around ALSA (unless you someohow usedd some some other type of sound driver than the ALSA snd-card-*.ko kernel modules). It adds latency and a giant pile of useless overengineering, when a simple config file was all that was needed (and maybe GUI editor for that file). Any of the fancier features provides were better served by jackd anyway.
Oh, and that's when it works. Even just a year ago, when I last tried PA, it introduce a shocking number of compatability problems for no good reason, and stilll added a LOT of latency.. I'm not even talking about the non-sound issues!) by simply uninstalling PA so everything fell back to using ALSA by itself. The list is so large now, that even non-technical people I know make jokes about how bad PA is.
As usual, while there is some need for improvement in ALSA ( and other linux features, but the bloated, non-working, latency adding mess called PulaseAudio is *not* the solution.
Ce n'est pas une signature automatique.
I'm running arch. Arch moved to systemd before I understood the issues at stake. I feel the systemd pain every day. I'm trying to get multi-head with nouveau working (a different set of pain, that I'll probably just switch to nvidia blobs to get around -- unless someone can point me where I want to be -- but I digress)
...and I don't understand why "systemctl isolate multi-user.target" vs. "systemctl isolate graphical.target" [try explaining THAT pair of command lines to start with] can't be expected to be as dependable as "telinit 3" vs. "telinit 5".
If I couldn't ssh into the box from somewhere else regularly, I'd be hitting the Big Switch a lot and we all know how well file systems take that kind of shenanigans.
I don't need to wait five years to hate systemd. I hate it more and more every day. My feelings do not extend to the authors -- as humans, they deserve my compassion and (in this case) pity. But I hate their software with a passion that grows more intense by the day. This is a sad day for Debian, it was one of the places I was thinking of escaping to.
Still hoping for Gentle Treatment...
Yeah it is a remarkable change in attitude on /. over the past 15 years. People used to be thrilled about change. Now they hate it. If it were the old fogies like me I can understand, get off my lawn... But it is the young guys who seem the most fearful of change and stuck in their ways. I really realized this during the IPv6 debates when the idea of changing a network system was unthinkable. Dammit where would you all be if my generation had ripped DECNet et al out?
I'd doubt that Linux is alienating power users. What it is alienating is traditionalist system admins.
I know a lot of non-sysadmin Linux users who very alienated by this whole thing.