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.
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.
You are aware that most of the systemd daemons do NOT run on PID 1 (and none of them on PID 0), right?
Yes, you are right. It is always better to not fight. If something inferior is becoming the new standard then oh well. It is better to just let it happen than to show the outside world an ounce of disagreement. As soon as a community does that they might get some internet person posting snarky comments about leaving them behind. The horror!
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.
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.
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
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.
SystemD is a liability for sysadmins, it is the only logical decision unless you have support contract with RedHat. There's already stories of "I moved to FreeBSD to solve one issue and realized it made things so much easier. Instead of 10,000 RedHat servers, we now have 3,000 FreeBSD doing the same work, and the reduced time managing the systems frees me up to work on other things". One of the biggest reasons for sysadmins loving FreeBSD is how "unixy" it is, and systemd is anti-unix.
Sysadmins live and die by their automated scripts. There are scripts that were made 15 years ago for FreeBSD, and they still work to this day. Linus takes the stance of "don't break userland". If you're going to break your user's scripts, you'd better have a damned good reason.
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.