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