uselessd - a fork of systemd

by
Anonymous Coward
in linux on (#2SNR)
A fork of systemd has recently emerged, calling itself "uselessd (the useless daemon, or the daemon that uses less... depending on your viewpoint)".

They describe the project as such:
uselessd 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 list features such as support for musl libc and uClibc, decoupling from journald and udevd, removal of superfluous unit types and daemons unrelated to process management, as well as the preliminary foundation for potential future ports to non-Linux systems.

This is certainly an interesting development in the entire systemd saga.
Reply 17 comments

I dare you to do better (Score: 1)

by bryan@pipedot.org on 2014-09-20 22:15 (#2SP1)

Seems the best way to promote new development is to release something that fails or that everyone despises.

OpenSSL fails -> LibreSSL released; upstream cleanup and fixes pushed out.
TrueCrypt closes -> DoxBox released.
Gnome sucks -> XFCE, LXDE, and other alternative desktops benefit.
Upstart falls short -> systemd developed.
systemd despised -> a number of new init development projects emerge.

Re: I dare you to do better (Score: 3, Funny)

by zafiro17@pipedot.org on 2014-09-21 00:27 (#2SP7)

Dice unleashes Slashdot Beta, everyone scatters. Pipedot born ...

Cool (Score: 0)

by Anonymous Coward on 2014-09-21 06:06 (#2SPG)

Considering the criticism of systemd I am surprised I haven't heard of something like this earlier.

Checking it out.

Re: Cool (Score: 0)

by Anonymous Coward on 2014-09-21 11:53 (#2SPR)

systemd == systematic invasion. The other init systems were held to ransom because systemd kidnapped udev. This is a sane 'enough is enough' development to stop further encroachment.

Ignore Corruption?? (Score: 0)

by Anonymous Coward on 2014-09-21 14:19 (#2SQ1)

Look I'm still kind of a Linux/BSD noob, but their first link to the Systemd bugtracker is kind of compelling, no?

The single most important system management tool, basic logging, is turned binary, and SystemD developers' official response to log corruption and complete unreadability is literally "ignore it"??

This is okay with all the distros? What the frak is going on out there?

Re: Ignore Corruption?? (Score: 2, Funny)

by zafiro17@pipedot.org on 2014-09-21 19:23 (#2SQ7)

Agreed, totally agreed. It's like the dev team has been invaded by aliens who have brought a totally different set of coding values with them, like "opacity isn't a problem" and "we love single points of failure."

I don't get it either.

Re: Ignore Corruption?? (Score: 2, Informative)

by evilviper@pipedot.org on 2014-09-23 06:00 (#2STB)

You don't have to use systemd for logging, you can continue using rsyslogd and plain-text logs if you so choose.

Re: Ignore Corruption?? (Score: 0)

by Anonymous Coward on 2014-09-23 11:42 (#2STS)

So you're saying it's opt-out, like spam, and the Mafia, and taxes? Kind of missing the point of an inherently poor design and unaccountable developer, no?

Re: Ignore Corruption?? (Score: 1)

by evilviper@pipedot.org on 2014-09-23 22:54 (#2SVE)

So you're saying it's opt-out
No, it's opt-in. It's not going to automatically shut-off your syslog. Now, what distros choose to use as their default is a different matter, its they who are making these default decisions for you.
Kind of missing the point of an inherently poor design and unaccountable developer, no?
No. Problems don't actually need to be fixed upstream, distros can patch anything about systemd they want, before packaging it for their platform. That's where Ice Weasel comes from. I don't see anything inherently poor about the design... Binary log files are no more risky than plain text, and any logger can have bugs.

Did you know that rsyslogd will bring down your whole damn system if you use TCP logging over the network, but the destination stops accepting?

Re: Ignore Corruption?? (Score: 0)

by Anonymous Coward on 2014-09-24 00:13 (#2SVG)

Huh? I was saying one had to "opt out" of having the log files be binary. You don't seem to be saying anything different? They are binary by default. One has to choose to turn off the binary logging. That's opt-out. One has to opt-in to the old-fashioned way, no?

Or are you saying they ALSO have text logging by default, doubling up all the logging?

Are you also really saying that a corrupted binary file is every bit as parseable, salvageable, and recoverable as a text file with short or malformed lines towards the tail? I'm not seeing it.

Re: Ignore Corruption?? (Score: 1)

by evilviper@pipedot.org on 2014-09-24 06:31 (#2SVV)

systemd DOES NOT LOG TO DISK BY DEFAULT.
Is that clear enough?

If your distro opts to configure it to do so (out of the box for you), that's a different matter entirely, and one you'll have to take-up with them. They could keep rsyslogd in-use just as easily.

And yes, binary files are just as recoverable as text files. The only difference between text and binary is a 7 vs 8-bit character space, and the standard character defined for line-endings. Otherwise, there is no difference between binary and text files. This is entry-level stuff, first week of programming 101.

Re: Ignore Corruption?? (Score: 0)

by Anonymous Coward on 2014-09-24 10:02 (#2SW0)

Your first week was a bit different to mine. We learn program structure and how to run the compiler.

Re: Ignore Corruption?? (Score: 0)

by Anonymous Coward on 2014-09-24 10:58 (#2SW1)

But that's nonsense. Binary implies the files are not sequential but stored in data structures with random access and placement. You seem to be implying that binary files are written to sequentially. Nope. Maybe in SyatemD's case I don't know.

Re: Ignore Corruption?? (Score: 2, Insightful)

by evilviper@pipedot.org on 2014-09-24 12:15 (#2SW3)

"Binary file" implies no such thing.

Text files can be written with random access in complicated data structures as well. The most impenetrable XML file is plain-text, after all.

Re: Ignore Corruption?? (Score: 0)

by Anonymous Coward on 2014-09-24 12:55 (#2SW4)

Agreed about XML of course, and yes text "log files" COULD be written randomly, but they're not. I don't know about systrmd's binary log files, which is why I'm asking. It would seem silly to switch to a binary format and continue to do nothing more than append uncompressed ASCII equivalent byte strings to the end of a file. I just doubt the systemd logs work that way, but I do not know. Thanks for the feedback.

Re: Ignore Corruption?? (Score: 1, Informative)

by Anonymous Coward on 2014-09-24 18:54 (#2SWD)

Well, at least one user (on Reddit, sorry) says the whole darned thing becomes unrecoverable. I suppose one could find or write recovery tools to try to get back some of the data. (With text logs the recovery tool is called VIM.)

http://www.reddit.com/r/linux/comments/1y6q0l/systemds_binary_logs_and_corruption/

Re: Ignore Corruption?? (Score: 1)

by zafiro17@pipedot.org on 2014-09-27 20:32 (#2SZJ)

Ha ha! I just "recovered" this week: installed PC-BSD (FreeBSD) on my work machine. No more systemd! (Unfortunately, no VMWare, either - haven't decided what to do about that yet, especially since I paid for it).