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.
slackware users are saying "what's all this then?"
lose != loose
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.
Can't someone fork a version without systemd?
There's a fork of Debian without systemd, and there's a project to strip systemd down to the essential parts.
systemd is an abortion and one that most of us do not want.
That is simply not true. A VERY vocal minority do not want Systemd on ideological grounds (although I suspect it is more a matter of the new and different scares them, no matter what advantages it may offer)
The simple fact of the matter is that Systemd does everything, that other init systems do, at least as well, and it does some things that other init systems simply cannot do. If all the popular init systems today had been introduced at the same time, we would all being using Systemd, and no one would have given the others a second thought. The various technical committees have chosen Systemd because on the technical merits Systemd is simply better. There is no argument in favor of the former init systems that cant also be made against all technological progress.
I wish I had a good sig, but all the good ones are copyrighted
debian uses simple release engineering like unstable -> testing -> release. there are other projects that work in a similar way, freebsd is fairly similar. they have commonly done gigantic system-wide break everything for months type changes in freebsd current.
they don't need to fork to test experiental things, they just do it in unstable first. then when they can't find problems, it goes into testing. eventually testing becomes a release.
considering systemd has been in debian in an experimental capacity for nearly 3 years, i think they've done enough testing to consider it stable.
it's nothing like debian/kfreebsd, because changing to a completely different kernel is nothing like changing an init system. not to mention that debian/kfreebsd was expected to have a very long steep development curve with a very small audience, whereas systemd is something that is already proven to be a fairly stable thing. redhat has been using it by default for half a decade.
i'll never use systemd, though. not because i don't trust its stability. the way it works and is configured reminds me of DJB software. makes sense, works well enough, but is wrong on a level that is difficult to explain.
Can't someone fork a version without systemd?
I agree, choice IS good. However, what I'm seeing so far is a bunch of vocal whiners on Slashdot bitching about systemd, and no one actually stepping up to make a distro that doesn't use it. So what it amounts to is a few loudmouths telling distro maintainers they're wrong, even though the loudmouths don't want to actually do any work on distros themselves.
that's precisely why i actually worked hard and risked destroying my business by losing access to all data on a critical business laptop, documented the process of removing libsystemd0 from it, and *then* wrote the article.
unlike the people you refer to, i actually *did something*.
then, i contacted the devuan team and informed them about what i had done, so that they may consider properly replicating what i'd done as maintainable debian packages. so they now have a way forward where previously they would have been worried that their efforts would result in many people still having to remove huge numbers of packages - desktop GUIs, sane-utils, cups-daemon, pulseaudio and anything that depends on it, clamav and many many more. i've demonstrated that you *don't* have to remove all those packages and that you *can* still have a functioning debian desktop... without libsystemd0 even being on it.
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.
Software mixing you say? It's called dmix.
Why the fuck do you want to round a *sound mixer* inside your *kernel space* ?! Do you run your video decoder and webbrowser there too ?
I prefer to run unnecessary things like sound as daemons in userspace. Thank you very much.
... Because I need less than 125 microseconds mixing processing latency (12 samples at 96 kHz) so that in-ear monitor mixing for live performance can be useful - requires a total latency from microphone to wireless receiver to CPU to processing to wireless transmitter to in-ear monitor of less than 5 ms. Until Linux user tasks can be scheduled with this kind of hard real time timing accuracy, mixing real time audio in user tasks doesn't cut it for live audio. So I myself am required to do my mixing and processing for real time audio either in the kernel driver, in a RTLinux task (in kernel space), or in a Xenomai task (see xenomai.org ) running at a higher priority than Linux.
ipv6 is my vpn
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.'"
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.