SoylentNews is people
SoylentNews
A developer affiliated with boycottsystemd.org has announced and released a fork of systemd, sardonically named uselessd.
The gist of it:
uselessd (the useless daemon, or the daemon that uses less... depending on your viewpoint) is a project which aims to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism. Basically, it’s systemd with the superfluous stuff cut out, a (relatively) coherent idea of what it wants to be, support for non-glibc platforms and an approach that aims to minimize complicated design.
uselessd is still in its early stages and it is not recommended for regular use or system integration, but nonetheless, below is what we have thus far.
They then go on to tout being able to compile on libc implementations besides glibc, stripping out unnecessary daemons and unit classes, working without udev or the journal, replacing systemd-fsck with a service file, and early work on a FreeBSD port (though not yet running).
Responses from the wider Linux community are yet to be heard.
(Score: 4, Interesting) by sjames on Sunday September 21 2014, @08:35AM
To get it out of the way, I am one of those people who develops linux systems and end up having to deal with systemd's hairball of dependencies. So don't complain when I complain.
Users SHOUL:D complain, and loudly. That hairball makes it much harder to even try to create something better than systemd. How would you have felt if sysvinit was that sort of hairball and replacing it with systemd made random other seemingly unrelated stuff break (such as your desktop)? So user may lose out on something much better later because systemd wedged itself so far up their backsides it can't be removed.
Admins likewise have every right to complain. If the system doesn't come up properly, it's on them to somehow make it come up. They care very much about the init process. Here again, users have a right to complain too. If the system doesn't come up, they're going to want that fixed quickly and effectively. They aren't going to get much work done if systemd is throwing some sort of fit and nobody knows why because the blob sitting at PID 1 resists debugging.
Had systemd been thoughtfully designed, it would expect to be run by init and then do the rest of the bringup through scripts and a helper program or two (for example, a helper that creates a cgroup, runs the daemon in it, then monitors it and acts as a controller.
I don't hate Stallman because emacs isn't a critical piece of system software and nothing depends on it. I can install it or not (and personally, I choose not).
(Score: 2) by mtrycz on Sunday September 21 2014, @10:05AM
Hey thanks for the heads up: I wasn't aware that systemd resisted debugging.
Looks like there's no better way to serve a backdoor at this point.
In capitalist America, ads view YOU!
(Score: 1) by fritsd on Sunday September 21 2014, @05:57PM
I am more or less ignorant about systemd, but I do know that it takes over the syslog function as well.
Also, pulseaudio libpulse0 now depends on libsystemd-id128-0 and libsystemd-journal0. It all gets tied together so much..
I haven't had time to look at the patch where the Debian package of pulseaudio starts to depend on libsystemd-journal0 but I'm curious because I know the same people are working on both projects.
I will do my best to see if this uselessd thingy would work for me.
(Score: 0) by Anonymous Coward on Monday September 22 2014, @03:06AM
What a fucking mess.
(Score: 0) by Anonymous Coward on Monday September 22 2014, @09:13AM
Systemd is a huge binary blob, where as both sysv-based and bsd-based init systems are a simple binary (on the scale of a couple of bugs being found per decade) that hand everything important over to shell scripts.
A unix admin is more or less a shell script expert, often with minimal C skills.
Debugging a shell script is on level with turning off the coffee machine for these guys, where as C code with any level of complexity would likely result in sending mails to the developers and spending a lot of time waiting for replies.
(Score: 1) by chris.alex.thomas on Sunday September 21 2014, @10:36AM
it took all of ten seconds to open google, type "systemd debugging" and found this
https://activedoc.opensuse.org/book/opensuse-reference/chapter-8-the-systemd-daemon [opensuse.org]
I suppose you could have done the same and know how to debug it if you have problems.
and are you still talking about PID1 ??? barely any part of systemd runs as pid1, it's all branched off and the benefits far outweigh the problems, I've also had a problem with my system which was practically impossible to fix and it was using the old init.....systemd is faster and better designed than the old sysvinit.....
(Score: 0) by Anonymous Coward on Sunday September 21 2014, @01:08PM
Did you actually read what you linked to? Have you ever done any actual shell script or software debugging on Linux?
Debugging init scripts sounds FAR easier than doing that sort of systemd debugging that's described. Binary log files? Jesus Christ, that has just made debugging 8x harder, even if there are tools to work with those binary log files. And what's to say that these complex tools are even working if the system is really screwed up? Nothing! Yet we can usually rely on sh and ed to be working, since they follow the UNIX philosophy by doing one thing, and doing it really damn well.
(Score: 0) by Anonymous Coward on Sunday September 21 2014, @03:03PM
I know very little about systemd, but I have been a unix dev for 20+ years now and one thing I am qualified to say is that binary log files are a terrible, terrible thing. They should only ever be used when the alternative is no log files. They are so unfriendly to developers, and it has a way of biting you in the ass when you least expect it. Being able to manually run them through a translator is only good enough for the most low-impact bugs.
(Score: 2) by sjames on Sunday September 21 2014, @04:01PM
So, when I want it to go step by step and stop in-between each step,.....
How about if I resort to init=/bin/bash and then wish to start the services manually? It seems systemd can't do it's thing without that chunk sitting on PID1 (where my shell is)
I'll be sure to use all those pretty tools as soon as the system comes up far enough that I can. I gues if the problem prevents getting to that state your solution is to reinstall Window^w Linux?