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.
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
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.
Sun and Ubuntu did replace init, but that's all their replacement did. It didn't creep into other areas and try to take over all of system management.
How is upstartd, SMF, launchd, different than SystemD?
From brief overview the arguments it does everything is fud. No it does not route packets. It launches a process which communicates to the networking daemon inet for this. No it does manage kernel level threads. It is not a mini operating system at all and is just 300k lines of code.
SystemD is no different than the other event driven alternatives. It just requires relearning which people set in their ways get infuriated about.
With startupd, launchd, SMF, and SystemD you set the triggers for each event. No long scripts loaded with nested if/else statements galore or expensive proprietary software to mask this lack of functionality in init.
That is my answer to the grandparents argument there was no need for change. Kind of reminds me of XP users angry at MS for merely just 13 years of support and do not see the obvious need for security via ASLR ram scrambling & DEP, better process handling, better driver models, USB storage frameworks, and so on.
Things progress
http://saveie6.com/
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