Slashdot Mirror
Removing Libsystemd0 From a Live-running Debian System
lkcl writes The introduction of systemd has unilaterally created a polarization of the GNU/Linux community that is remarkably similar to the monopolistic power position wielded by Microsoft in the late 1990s. Choices were stark: use Windows (with SMB/CIFS Services), or use UNIX (with NFS and NIS). Only the introduction of fully-compatible reverse-engineered NT Domains services corrected the situation. Instructions on how to remove systemd include dire warnings that "all dependent packages will be removed", rendering a normal Debian Desktop system flat-out impossible to achieve. It was therefore necessary to demonstrate that it is actually possible to run a Debian Desktop GUI system (albeit an unusual one: fvwm) with libsystemd0 removed. The reason for doing so: it doesn't matter how good systemd is believed to be or in fact actually is: the reason for removing it is, apart from the alarm at how extensive systemd is becoming (including interfering with firewall rules), it's the way that it's been introduced in a blatantly cavalier fashion as a polarized all-or-nothing option, forcing people to consider abandoning the GNU/Linux of their choice and to seriously consider using FreeBSD or any other distro that properly respects the Software Freedom principle of the right to choose what software to run. We aren't all "good at coding", or paid to work on Software Libre: that means that those people who are need to be much more responsible, and to start — finally — to listen to what people are saying. Developing a thick skin is a good way to abdicate responsibility and, as a result, place people into untenable positions.
While it all sounds nice, you do realize 99.99% of the population just sort of wants their computer to work. We don't strictly care too much about your love/despise of some piece of software you didn't pay a dime for, didn't invest any time in writing, and then whine about being used/write love stories to. This sort of behaviour is exactly why projects like a Linux distro, or god forbid GNU/Hurd, never make it to mainstream software. I've said this before, and I'll say it again. If you want the Linux eco-system to be accepted start by getting rid of Stallman, write some damned drivers, make an easy to use system that doesn't require 5 hours of Googling on how to get a laptop soundcard to work. If you invested half the energy you folks use for whining about systemd into actually making an alternative available you might actually get something done.
We aren't all "good at coding," but we know what init system we want.
We aren't all "doctors," but we know we don't want vaccines.
We aren't all "scientists," but we know global warming is a hoax.
I cannot be the only one sick of seeing this crap posted over and over. systemd is being implemented in distributions because a) it is good and b) the people making that decision are the ones qualified to do so.
Networked sound playing is just an incident of pulseaudio being a sound router. It's a nice feature, but that's not what pulseaudio was basically written for.
That's unfortunate, because that's the only thing it actually provides that we didn't have before.
lots of headphones/microphones now are USB. They are not another channel on the same soundcard, they are a completely different sound driver. Switching when pluging a headset is not something which is trivially done in ALSA without special support of software.
Another thing which can be done with a small shell script.
bluetooth, which is VERY common on portable devices (but also might be usefull on dekstops) isn't even a kernel driver.
But BlueZ does provide an ALSA driver.
It has much more in common with networked sound than with ALSA.
Except, you know, that the sound comes through an ALSA driver.
recording the output of another program becomes much more trivial if there's a sound router handling the redirection, instead of needing some special support in software.
Special support in software? what do you think pulseaudio is?
Pulseaudio doesn't require any special support. It can present an ALSA target to any ALSA-enabled software.
When that works.
Why the fuck do you want to round a *sound mixer* inside your *kernel space*
That's OK, there is userspace dmix for the paranoid. But you avoid a context switch by having your sound mixer inside your kernel space. However, if you want to use a floating point mixer, it has to be userspace anyway because politics.
And you're still free to disable pulseaudio and use dmix instead, if you want.
Some applications are just using pulseaudio directly for audio now.
Instead of being vulgar, maybe you should ask yourself why so many distributions are switching to systemd.
Because upstream software requires it, for poor reasons.
Also please try to avoid making confusion between the actual piece of code that runs as PID 1 (which is indeed confusingly called "systemd") and all the other pieces of code that add the functionnality mentionned in all systemd articles (these pieces of code are all members of a project which is also called by the same name "systemd", but all pieces of code are completely different deamons like "networkd", "journald", etc.).
No. I can't ignore the various pieces which are required. I can ignore the non-required bits, though.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
But in practice it is non-viable as a replacement for all systemd is doing today as the developers on it admit
There's no need for it to do all that systemd is doing today. That in fact is much of what is wrong with systemd.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Ubuntu wasn't a big enough player? That's news to me.
The reality is that upstart solved problems that systemd did too, then Ubuntu not being of the NIH RedHat type said hey, no need to continue to pour effort into our own init system, we could just switch to another.
The thing about forks is they are often created as a need to address something which does not exist. This is why I am watching this entire debacle with a very keen eye. Base on the talk on online forums one of the following 3 will happen:
1. Linux user base will decimate in favour of BSD.
2. Devuan will become a leading distribution and will quickly find it's way onto every server in the world as admins refuse to work with systemd.
3. Life will go on because people don't put their money where their mouth is, and systemd isn't quite bad enough for people to actually start supporting alternatives instead dedicating all their energy to complaining on the internet.
To anyone who hates systemd, donate to an alternative or dedicate some programming time, or package management, or any one of the other many things that go into maintaining a fork.
Another thing which can be done with a small shell script.
Oh please stop. I can't read much further than this. There were many use cases for linux audio which were either completely absent or plainly broken before Pulseaudio matured (I won't say before it came out, because frankly it was broken when Pulseaudio came out too).
If you think supporting the range of various event driven realtime changes to the sound destination (i.e. I did something as mind bogglingly complicated as plugging in my headphones while watching a movie) then I'm sure there wouldn't have been an endless list of complaints about the state of linux sound. As far as a general user was concerned, sound was effectively broken. But it's good to know you could write a shell script to fix everything. (I won't draw a comparison to sysvinit here, woopse too late).
If the problems were as easily solved as you claim the distros would have done it years ago. Except they didn't and were so very keen to migrate to something which did have this functionality that they released Pulseaudio waaaaay before it was ready for primetime (happy to draw a systemd comparison here).
But feel free to keep wearing your rose coloured glasses as you lament about why we have the things we do know.
You're right, OpenRC cannot keep up because it's not a DHCP client, nor a binary system logger, nor any of the other things systemd has now assimilated.
It's just an piece of software which starts the system in a deterministic fashion using existing software that's been very well tested, such as sysvinit on Linux the respective BSD init on the BSDs.
OpenRC is just an init system, it will never be anything more than that. And why should it be? There are much better system loggers and network management tools out there than what systemd offers.