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.
I did just that. It took a few weeks to figure out how to work around all the kinks (as FreeBSD is primarily targeted at the server space), but I'm really glad I did. I have a full Xfce desktop with all of the programs I was using on Wheezy before. Rock solid stability. Might be a bit easier to try PC-BSD to get one's feet wet.
I've also really grown to like all of the new features: ZFS for easy multi-disk mirroring, encryption, and snapshots; pf for firewall rules; etc. There's also DTrace, jails, etc. The integration with the base utils is wonderful, and the documentation is top notch. I've also found the new package system to work as good as apt-get (pkg install {program-name} and you're done.) I liked it enough that I've even started using it for my servers as well.
Definitely give it a try if systemd bothers you as well.
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
I'm not philosophically opposed to what you're suggesting here. I am incensed, though, that it should be necessary.
So you think that you're entitled to getting software, free of cost, which is exactly the way you want it to be. The people who actually invest their time and effort into making these distros should, instead of doing what *they* think is the best course of action, do what *you* think is right, even though you don't feel like investing your time and effort into the project.
No, I think that people should follow my fucking example and listen to others, perhaps learning a little humility in the process.
I already told you I write FOSS; I scratch that itch when I need to. I have a fucking right to talk about this because I've walked the fucking walk. And I won't do you the indignity of asking whether you have as well.
I am trying to suggest that writing code is not the only useful role to be played in FOSS development. I am trying to suggest that we can't write all the code, all the time, so it behooves all developers to listen to their peers, if only to learn from their mistakes.
And now, you can perhaps go back and respond to the main question, which is why you think numbers matter in FOSS development?
All the people who maintain distros have considered and discarded your arguments. So why should I value your opinion over theirs?
Well, given that I told you that I've been a distro maintainer, your assertion is incorrect. Not all of us have discarded these arguments. Your assertion is a textbook case of No True Scotsman. But don't take my opinion in isolation; why not go ask Ian what his reservations are?
See, this is pretty much precisely my point. It's not that people's opinions are getting ignored. That happens all the time. It's that people aren't listening at all. And more to the point, that really critically important lessons of the past are being set aside merely because a small number of people have become convinced that they know a better way.
Again: in and of itself, that's not necessarily a problem. The problem here is that these particular people are wrong.
Crumb's Corollary: Never bring a knife to a bun fight.
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/
The other poster was wrong: dmix runs in user space. Linux never had kernel space mixing/resampling, unless you patch it with OSSv4.
Which means your post is bullshit.
"Because Lennart Poettering managed to make his friends doing GNOME development make GNOME depend on systemd, " - if you do some research, you'll find he actually enabled the software remain compatible with Consolekit but Gnome chose not to use it. read this for more info http://www.linuxvoice.com/inte...
its quite amazing (and disappointing) just how much mis-information is out there and that people do no research before jumping on the bandwagon
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
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
That said, we are talking about consumer grade setups, and the default of 350hz timer, and pulse works just fine for that.
Doing something that much more hardcore, re-compile the kernel, I do believe debian and ubuntu provide low-latency and realtime kernel along with packaging for related programs, and guides do exist for other distros.
I do believe if you are a highly trained technician, you can be expected to know your tools better than the average consumer who doesn't want to fuck with it. If you're getting paid, its also job security.
Try the settings - standard kernel options for linux don't work for this.
The only options that work today are using driver level code for audio processing or a real time Xenomai task.
Please support Thomas Gleixner via the Linux Foundation to help to fix this limitation of Linux: http://lwn.net/Articles/572740...
Until then, all high performance low latency audio processing in linux needs to not use any user level tasks.
Jeff
ipv6 is my vpn
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 ]