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: 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.