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.
every so often, I try out the various 'desktops' that linux distros offer.
every time, I give up, dislike all the procs running, mem wasted, cpu cycles wasted and all the crap that comes with the desktop. feels like bloat that should not be there, not for a 'simple' linux install.
I always laugh when people look at my display. I use a red/orange color to highlight the active window and grey for the inactive ones. there is no trash icon, no iconbox, no drag/drop. a short menu appears when you click into space (no clients under) and then pick which foreground rxvt opens up (all with black bg's).
I keep things simple. but I've been using this layout for literally over 25 yrs (starting with twm and using mwm for a short while, when motif was still popular).
not having a desktop is great. in all that time, I just have not been limited (at all) in what I can do, and things seem to be fast when I just run a term window, type what I want and it instantly runs.
unix was supposed to be simple. systemd is an abortion and one that most of us do not want.
good to see this protest post with a hand-tweaked system; but the fact is, we should NOT have to flip over backwards to remove a stupid should-not-be-there-anyway daemon and its evil libs.
--
"It is now safe to switch off your computer."
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.
Man, can we just give this a rest? My gawd, I can't believe people have the energy for this. Just go back to an earlier distro before all this stuff and enjoy.
we can't. the reason is simple: security updates and software updates will be incompatible. i actually maintain a hell-on-earth system for a client. the choice to do so is entirely mine, i have to point out. it's hell because i disagreed with putting KDE 4 in front of clients who are used to the simplicity of KDE 3.5, and i disagreed with moving them over to Gnome because, well Gnome is a different kind of hell (for me), involving being completely unable to remotely ssh in and hand-edit config files in a pinch. with KDE 3.5 it is still possible to do that.
so i ended up upgrading to Trinity Desktop, but this is after leaving the system running debian 6 for as long as possible. the upgrade was... fraught. then i had (in December 2014 - so only a couple of months ago) to buy and install a new printer (because we couldn't get the old one). that new HP printer wasn't recognised by the version of hplip that was on the system (3.12).
so i did an "apt-get upgrade hplip" - and what do you think happened? it said "to satisfy your request we require to remove Trinity Desktop and install KDE 4".
the reason was because the Trinity Desktop Team do *not have the manpower* to keep such a large old software base completely up-to-date with debian/testing. ... so i was forced to compile hplip from scratch, from source code! *fortunately* HP saw fit to include an extremely well-written and well-thought-out script that detected the OS, installed the build dependencies and generally got on with the job. i was really impressed.
now, the only reason i could contemplate this was because i am an experienced GNU/Linux systems administrator, but do you *really* think that the average person will be satisfied to "use older software" as you suggest?
this is the crux of the situation: that we *are* forced to such extreme polarising choices. and that's why i did what i've done - demonstrate that it's possible to remove libsystemd0 which is being shoved down our throats. i *don't care* if libsystemd0 is good or not: i object to it being forced onto people.
All the criticism of systemd is not strictly from a luddite perspective. There is a population that appreciates meaningful advances (Wayland, btrfs, even some facets of systemd), but doesn't like some of the compromises systemd has employed to achieve their goals. Getting stuck in a point of time before systemd is not a desirable result, and in fact systemd might be able to win over some detractors if they recognize criticism and make sensible technical solutions to those rather than continuing to say 'oh everyone loves it except some impossible to please luddites'. For example, journald could embrace native text logging with external binary metadata and deliver all the goodies they provide and quell all the (justified) bitching that human readable logging is a second class citizen in their model.
They may not be able to accommodate all the objections (e.g. the amount of complexity they *must* do in pid 1 to have guaranteed comprehensive service management without blindly applying namespace isolation everywhere that would make a system look even weirder/risk breaking some services), but they could come a long way.
The issue for many of us is that things are being implemented that go beyond what systems administrators can follow along without understanding how to be a more robust software developer (and even then, there's some loss of convenience in analyzing things compared to an interpreted language). Systemd design shifts focus on specialized tools that are better at their specific task, but less reusable in similar contexts. If I started with syslog and learned 'tail -f' will let me watch logs, then I have acquired knowledge that can be used the next time I encounter logging output. If I learn 'journalctl -f', then that knowledge does not transfer to the huge number of other applications that do logging. It's a small example of things that in aggregate pose a significant challenge.
An administrator faced with a 'classic' design won't know everything about the system, but can get far with 'set -x', 'find', and 'grep' because the configuration, logging, and much of the 'glue' code is in clear text, and communication between programs usually hits the filesystem in fairly specific ways. Now with things like systemd and dbus, 'invisible' things happen (well, overly generic communication channels and compiled code). When the kernel implements new awesome stuff, it frequently manifests in sysfs, which is nice and discoverable. Advanced functionality that adheres to the 'everything is a file' and generally presents and accepts simple utf-8/ascii data. Not everything in the kernel does that, sometimes it creates obscure devnodes with ioctls instead, but it's a common and good practice in kernel land.
In general, we already have a system that embraces many of the design principles observed in systemd and actually does a decent job of making the concepts work: Windows. Even with a great deal of talented investment over the course of decades, when a Windows system goes off the reservation in certain ways, no one will be able to bring it back because of how complicated the integration of the various components. While certain concepts can be specifically be done better (e.g. journald does better than windows event framework), the emergent behavior of Windows that becomes impossible to overcome by administrators isn't really due to those specific things.
XML is like violence. If it doesn't solve the problem, use more.
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.
Ah, another systemd complainer, who of course can't be bothered to have a real Slashdot account.
However, the fact that systemd comes with the "USE US OR FAIL!" dire warning
There's no such thing in systemd. Slackware (always the last to just on new trends) seems to be getting along fine without it.
There are CONSTANT statements that if you do not use systemd you will not be able to use primary Linux distros in the future, because all software will supposedly be gobbled up by it as a dependency... To try and now make out like those dont exist is pretty silly.
Given you only want to see complains as "whining" this indicates you do not want a free system.
systemd is LGPL FOSS, so it's just as Free as anything else. You seem to be using the appeal to emotion fallacy.
Again you are using half truths, or atleast feigning half understanding, or it may be possible that you dont understand the linux culture. It is pretty clear that he is talking about free in the sense of free beer, not free as in not paying for it.
Pretending any discord against systemd must be illogic and panic is just your childish method for not having to argue against the problems highlighted.
Because all the "problems" you cite are generally overblown or not problems at all. Please, show me where prominent distro maintainers are criticizing systemd and refusing to integrate it into their distros. The ramblings of some disgruntled random people on Slashdot are not equivalent to the opinions of experts in the field.
Now you are A) doing exactly what the quoted person stated ,pretending the problems are overblown or not problems at all, when there have clearly been (debug fiasco) and are issues. You then make it seem like the only person who can show a problem are distro maintainers. Maintainers are typically not the mass admins who have to support it, possibly trying to move the goal posts. There is no doubt that system d helps the maintainers, but it also harms the admins.
When you cant win, ad hominem.
I didn't like (and never used) Pulseaudio either. If I wanted to play sound over a network I'd share my media directory.
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.
There are lots of situations where sound is routed to something which isn't the usual ALSA driver:
- 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.
- bluetooth, which is VERY common on portable devices (but also might be usefull on dekstops) isn't even a kernel driver. Sound is handled by a deamon communicating with the bluetooth stack. It has much more in common with networked sound than with ALSA.
- 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.
What I wouldn't do is run an unnecessary audio layer requiring application support - and that can do nothing else - in the form of a sound daemon I never wanted and didn't ask for.
Pulseaudio doesn't require any special support. It can present an ALSA target to any ALSA-enabled software. Most current software don't even have a pulseaudio plugin, they just open the default ALSA device which happens to be one pulseaudio listends to and that just works.
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.
I moved away from Windows and towards open source years ago in order to have choice.
And you're still free to disable pulseaudio and use dmix instead, if you want.
Now indeed, for an init system, it's a bit more complicated to leave complete choice to the end user. Some specialist distro like Gentoo are able to offer you to switch between their default OpenRC and whatever you want.
But the amount of work and risk of bugs in untested paths is rather high. So don't expect other distros to offer instant switch between systemd and upstart.
I will have that choice whether or not most major distributions gargle the Poettering cock.
Instead of being vulgar, maybe you should ask yourself why so many distributions are switching to systemd.
Maybe, part of the reason would be that systemd solves actual real world problems that these distributions need fixed.
Maybe that's because systemd people and Lennart Poettering actually ship code, instead of just sitting the whole day bitching and cursing on internet forums.
Maybe if you didn't spent all your energy on whinning about systemd, and actually tried to *DO* something, to *FIX* the problems, and write an actual good solution, maybe your solution would be the one picked up by distros.
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.). In other words, it's not the PID 1 that get stuffed with innapropriate functionnality. It's the people who wrote the PID1 that are also writing other daemons for extra functionnality, all different parts of the same project.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I was in a meeting last week with some representatives of a large defense contractor and Microsoft. The two of them don't get along well. The defense contractor people (not the MS people) brought up the whole systemd thing as an equalizer between Windows and Linux, and not in a positive way.
The bottom line is that I have a hard time believing it, but Microsoft is actually making inroads in the server market again. Linux adoption where I work is pretty much stalled, and the things it is used for are mostly virtualization hosts, rather than stuff that actually performs a function. While the systemd thing is just a tiny blip compared to the other reasons this is happening, this shit does not help.
I'm also not going to waste my own capital evangelizing the OS if significant engineering effort is going into something that is, at least in the short term, reducing the reliability of the operating system. That's a stupid idea and pissing off your evangelists is, too. Everyone forgets where the market share came from...and figures that it is fungible with whatever stupid follow-on idea they have, once they have said share.
Red Hat is about to learn this the hard way.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
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.
Love the parroting of corporate propaganda, right out of Microsoft's playbook: "anybody who doesn't like vista/win8/ribbon/ooxml is just an old fuddy-duddy luddite, all the cool kids love our latest super-cool technology."
> As far as this "UNIX Philosphy", fuck that shit.
If you hate it so much, use ms-windows. I mean it. If you want a proprietary system that controls everything with one big super-complex blob, then use ms-windows and be happy, and leave everything UNIX-like alone.
BTW: the UNIX philosophy is not just dogma, it has a practical purpose and has worked very well.
... 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.
If low latency in professionnal audio setting is your target, then there's already specialized software for that: JACK.
It's specially designed for what you want, and as widespread usage in the field.
Or might as well go for a hardware solution.
Use the right tool for the right job. Otherwise you end up trying to cram extra requirement into a tool which wasn't designed for it.
There are even special distribution which are geared toward pro needs and are tuned with this kind of tools.
(Dynebolic as an example)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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.