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.
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.
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.
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 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!
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...
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.