ACHTUNG.

uselessd has entered the final stage of uselessness, its ultimate expression of nihilism - the state of deprecation and utter nonexistence. That's right - uselessd is dead.

The last release was uselessd-8 on November 16, 2014. An effort to revamp the IPC system away from D-Bus into using a byte stream-based fifodir protocol was staged for uselessd-9, but a growing lack of interest and realization that trying to mangle the systemd architecture into something more minimal was becoming increasingly fruitless and unwieldy lead to the project being orphaned. It was transferred to Tarnyko in January 2015, but no activity of any sort has been seen since then. For all practical purposes, it's over.

The author of uselessd has since been drafting plans and reading papers as part of a from-scratch design for a heterodox init system based on design principles from research OS and HPC that are uncommon to the Unix world. It will be released when it's done, which might take a while.

uselessd -- what it says on the tin, plus a complementary kitchen sink and flat tire

So, what is it?

uselessd (the useless daemon, or the daemon that uses less... depending on your viewpoint) is a project 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.

What do you have going for it?

See the NEWS file for in-depth changes, or the release announcements on the Dark n' Edgy forums.

• Support for compilation under musl and uClibc. This has meant eradicating plenty of GNUisms, including ones that spread out as deeply as requiring specific printf(3) semantics.

• No journald. Consequently, this also means no libqrencode and libmicrohttpd integration, nor hooking coredumps to the journal. The default log target for auxiliaries is now LOG_TARGET_SYSLOG_OR_KMSG.

  The main case against binary logs is their corruptibility. This happens more often than you’d think, due to not having any transaction consistency, as an RDBMS would. The advice of the systemd developers on handling this? Ignore it.

  Otherwise, the main legitimate case for binary logs (but actually journald in particular) is Forward Secure Sealing. This is no longer a dealbreaker, since rsyslog supports log signing through GuardTime since 3.7.9 now. You can also use a combination of OpenSSL or the NSS signtool plus logrotate jobs to verify log authenticity, though this is more intricate.

  Secondary concerns include /var/log/journal fragmentation (though this can be mitigated through the SystemMaxUse option in journald.conf and log rotation) and lack of a standard way to log to a database backend (though we speculate that some hacking with systemd-cat, FIFOs and shell script glue might do something similar, this has been untested and is rather fragile in theory).

• No libudev and udevd. Feel free to use whatever device node manager you prefer.

• Certain superfluous unit types removed, namely devices, timers, swaps, mounts and automounts.

  Device units are closely tied to udev (they are, in fact, enabled through udev rules by tagging devices defined through its interface) and are primarily used for mount ordering. Due to their limited usage and the fact that we want users to employ their device node manager of choice (whether it be eudev, mdev, smdev or whatever), we removed them. For those seeking device-based activation, udev (and consequently eudev) rules already handle that use case.

  Timer units were removed, because we do not feel we should handle crond/atd. There’s already some pretty powerful replacements for the standard and rather aging cron. You can check out fcron, in particular.

  Swap units were removed to minimize complexity and invasiveness. The usefulness of unit options for swaps is also somewhat overstated. In particular, many of the options (such as for controlling the execution environment) apply only to the swapon(8) binary itself. We recommend using the standard util-linux and sysctl settings, as they are sufficient.

  Automount units were again removed to minimize complexity, and so we can focus on a more well-defined purpose: processes. We recommend either standard autofs or the Berkeley Automounter (amd) as alternatives. As a consequence, the x-systemd.automount fstab(5) option is no longer available.

  Mount units were removed for the same justification as removing automount units. We shouldn’t be handling fstab(5). Keep in mind the x-systemd.device option is unavailable, as a result.

• Various unnecessary auxiliary daemons (hostnamed, timedated, localed, logind, etc.) have been stripped from the source tree level. All generators, sans getty-generator and rc-local-generator, have been removed, as well, either due to assuming libudev semantics, because of implementing faultily defined logic, or because they rely on unit types we do not use. In particular, system-update-generator implements an unnecessarily intricate and currently unused GnomeOS system for managing centralized system updates in the same vein as Microsoft Windows.

• Setup routines for various MAC/ACL systems, including SMACK, IMA and SELinux, are gone. We want to stick to a more clearly defined purpose, one that is agnostic of such elements. Nonetheless, we have retained SELinux access routines in D-Bus APIs and unit options for SMACK attributes in socket unit files to respect existing configurations.

• systemd-fsck has been replaced with a service file that starts /sbin/fsck to fsck devices. In essence, this isn’t much different from what systemd-fsck already did, but with the overhead of a middle man executable interfacing with /sbin/fsck cut out. This also means that the systemd-defined sysctl parameters for its fsck are gone, and you should use the old ones (/forcefsck, etc.) instead.

• [IN PROGRESS; EARLY STAGES] Partial support for FreeBSD when it comes to stage 2 init (process supervision and management) is in early development. Nothing to write home at all about at this point, but see below for details.

See also the highly scattered and schizophrenic development notes at our BitBucket repo root directory.

What version of systemd is uselessd based on?

systemd-208-stable. We chose this, because it predates kdbus integration into PID1, the sd-bus API, networkd and a whole host of other cruft that has been growing quite profusely since then. Most baffling has been the recent inclusion of prerequisites for moving in kmscon, as well as the addition of a graphics card device access layer.

208 is also the default on Fedora 20, and had the longest support cycle of any other release that we’re aware of. We’ve backported certain bugfixes, though, as well as dropping support for TCP Wrappers.

As such, systemd options introduced after 208 will not work, though the vast majority of services will be just fine, due to using only a handful of basic ones on average. We may integrate certain newer ones, and even some of our own in the future.

Are my boot times safe?

Since the socket activation core and transaction logic has not been radically altered, your boot times are safe. In fact, because we don’t have journald, it’s likely they’ll be consistently faster as a result of not having a /var/log/journal that gets clogged, and that needs to be periodically truncated or limited on the configuration level.

On the other hand, we have eschewed the systemd-readahead implementation due to libudev usage. Though readahead in general is no silver bullet, if you’d like to use it, you’ll have to tune it through the conventional readahead(2) system call, instead (e.g. through a utility such as blockdev(8)), e.g. for caching block sizes larger than 128KB by default.

Interestingly, this decision appears to have been well foreseen on our side, as the systemd developers themselves are considering removing this feature.

Where do I obtain uselessd?

Our sources are on Bitbucket, and we offer a tarball at the Downloads section.

How do I install uselessd on Linux?

See docs/INSTALL_INSTRUCTIONS_LINUX.txt.

How do I convert an existing systemd installation to uselessd?

This will vary depending on exact configuration, but the general install instructions apply. You will need to eviscerate unsupported units and deactivate the journal, most likely, among other things.

What is this about FreeBSD you say?

uselessd is planned to work as a primitive stage 2 init (process manager) on FreeBSD. Stage 1 is inherently unportable requires a total overhaul in regards to low-level system logic (with systemd assuming lots of mount points and virtual file systems that aren’t present, is designed with an initramfs in mind and many other things). Stage 3 can always be achieved by having a sloppy shim around the standard tools like shutdown, halt, poweroff, etc.

So far, uselessd compiles on BSD libc with a kiloton of warnings, with lots of gaps and comments in the code, and macros/substitutions in other places. All in all, it is an eldritch abomination. A slightly patched version of Canonical’s systemd-shim is provided and works well enough to emulate the org.freedesktop.systemd1 D-Bus interface. Some of the binaries provide diagnostic information, but at present we are trying to find ways to bring up the Manager interface in the whole buggy affair, in order for systemctl to send method calls. Nonetheless, you are absolutely welcome and encouraged to play around with it in its present state, and we hope to get somewhere eventually.

In the meantime, you can check out the nosh project, which has goal of providing systemd-esque features on *BSD and Linux, while using a process management scheme more akin to daemontools, runit and s6. It features a systemd unit translator, socket activation, its own minimalistic logger, systemd-style targets, tools to manipulate and rate limit processes, and other things.

What the hell was the porting process like?

Quite arduous. It wasn’t impossible, obviously. At the end of the day, it’s software. But its heavy use of Linux-specific interfaces such as sysfs, procfs, epoll(7), prctl(2), magic numbers, filesystem flags and macros, reboot macros, keyboard interrupt codes, POSIX 1003.1e capabilities, cgroups and cgroupfs, plus a fuckton more, proved it to be a non-trivial task.

Nonetheless, even if the practical gains might be little (it’s still too early to tell), we believe it was a nice learning experience, and it’s also useful in the sense that we’re on our way to surgically mold a relatively cross-platform (OS) base for uselessd to, hopefully, work well as a process supervisor on non-Linux systems, in the future.

How do I install the FreeBSD port of uselessd?

Because of its very early and unstable nature (read: it doesn't work), we do not officially package it yet. You’ll have to clone it from our Git repo (the bsd-devel branch) and compile from there. We do provide some basic instructions for doing so at docs/INSTALL_INSTRUCTIONS_FREEBSD.txt.

Should I use uselessd as my main initd/system manager?

The FreeBSD port is just an early dumping ground at this point, but we absolutely encourage tinkering with it.

For the Linux build, it should be safe, but we’d recommend you wait a little bit until things stabilize some more. Nonetheless, we want testers and people to assist us, so knock yourself out.

Who’s behind uselessd?

Only one person. A total nobody. The boycottsystemd.org page itself was spontaneously conjured on IRC by multiple people, but the uselessd project is the work of only one of them. You can find me on the Dark n Edgy forums as V.R. and I go by commit logs as The Initfinder General. No, I am not Billy Estes. He only owns the boycottsystemd.org domain.

How do I use uselessd?

uselessd is the first init system that comes with no use.

In actuality, pretty much all the things that you know from systemd-208 are transferable, minus daemons and unit options that aren’t there anymore.

What about GNOME and software that depends on systemd interfaces?

By now, the systembsd project should have raised a fair amount of attention. It's still in its early stages, and logind will take a while to reimplement until a proper solution is found that does not require PAM.

In the meantime, there’s also OpenRC-settingsd and systemd-shim, though the former appears to be outdated.

To be quite fair, we advise against using GNOME altogether.

Any other viable sysvinit alternatives?

We mentioned nosh above, which looks like it has the most potential to be a systemd killer. It is, however, in desperate need of support and publicity.

Otherwise, plenty. “systemd or sysvinit” is a false dichotomy. We list some at http://boycottsystemd.org.

uselessd is meant to address the issue of using systemd without intrusive functionality and feature creep, with portability in mind, and coherent, conservative design principles and focus. We never expected initd to become this controversial, but ultimately it did. Getting out of this mess won’t be pleasant, but the Linux userland is known for its highly iterative and constantly evolving/recycling nature. Alternatives are bound to gain more traction, and the systemd interface replacements will likely speed up the process.

Either way, we see the whole debacle having a fate similar to HALd and devfsd, but with a stronger backlash.

What the hell? What are the motivations for forking this?

We’re opinionated and socially maladjusted dwellers who lead monotonous lives and are trying to bring some variety in our existences by seeing if we can win a Darwin Award, or at least rustle your jimmies.

More seriously, forking systemd is certainly a kooky thing to do, but we feel it had to be done, as a blunt statement (and because of our aforementioned qualities). Even in this light, uselessd is not just a political protest. We aim to make it usable and as a solid alternative for people who want the features the systemd core provides (socket activation, parallel execution, resource limiting, cgroups, the declarative configuration syntax, etc.) without the unnecessarily intrusive features, as well as maintaining a conservative development philosophy that prioritizes conciseness and focus over an ever-rolling gargantuan for system-critical software like this.

Nonetheless, we do believe there are problems with the state of contemporary Linux application development, both philosophical and technical in nature. Linux has become a de facto hub for Windows refugees, who seem to have brought the baggage with them. Opaque service libraries, intrusive, all-encompassing and poorly documented system daemons and frameworks, laughable pipe dreams of a “year of the Linux desktop”, among many other things plague the Linux userland today. Paradoxically, despite Linux not offering any significant innovation, it is the most prone to constant reinvention and what Jamie Zawinski described as the CADT (Cascade of Attention Deficit Teenagers) model.

The “init war” was a farce and never properly fought to begin with, mostly just presented as a false trichotomy between systemd, sysvinit and Upstart. Previous attempts to solve the problem (such as Richard Lightman’s now historical depinit(8))) were neglected, and it wasn’t until systemd arrived and began consolidating functionality and leeching itself into other applications was it either quietly adopted, or in Debian’s case, a rather entertaining debate ensued. The fact that systemd offloaded a lot of work for distro maintainers was probably the main motivation for its adoption. Distro maintainers are lazy.

Nonetheless, the common belief that shell script-based boot is inherently prone to buggy and ugly boilerplate code is a false one. It is true in the case of sysvinit, but not in BSD init, where most common functions are abstracted away in a file named /etc/rc.subr, which is then imported as a module. Initscripts often tend to be up to 3-4 lines of code, even shorter than systemd services. There is also no restrictive concept of runlevels, nor a cryptic inittab syntax.

Most core Linux applications and even the kernel are developed by a handful of companies, largely by Red Hat (who inherited much of the work on GNU after acquiring Cygnus Solutions, thus also leading GNOME and various other projects), who also support the opaque Freedesktop.org standards.

systemd is designed to be perpetually rolling software, not all that different from a kernel in user space, as was elucidated in a 2014 GNOME Asia talk. It has no clearly defined purpose beyond that other than the vague “basic building block to make an OS from”, though vagueness is probably a feature in of itself to justify intrusive functionality. The systemd developers don’t see software as a solution, they see it as a zero-sum game. A battle after battle to be won.

The end goal appears to be the creation of what we dub a Grand Unified Linux Operating System (GULOS) and the destruction of the Linux distribution altogether beyond cosmetic changes. GnomeOS, in particular. The latter is actually a thing that GNOME aspire to accomplish.

But, this is a rant for a different time. We’ll write more on this as we go.

What’s wrong with the cathedral model? We should make Linux a cathedral! You know, like *BSD!

Well then, go and work on BSD. They actually need the manpower, anyway. But what’s more, BSD was designed from the groundup to be a cathedral, and it works damn well as one. Trying to violently shoehorn Linux into a cathedral with lots of hackery is not going to make anything better, it’s only going to tangle up everything and make it a mess. Linux has always been naturally suited to the bazaar, and there’s nothing wrong with that: different paradigms mean different solutions and a higher variety of problems that can be solved.

But, but, *BSD isn’t relevant anymore! Nobody uses it!

If everyone had the same attitude as you back in 1991, nobody would be using Linux, either. Not that your premise is even true to begin with.

Why do you hate America progress?

We don’t. We just expect some improvement to go with our progress that outweighs the cons.

Stop impeding on the standardization of Linux distributions!

Wasn’t there a famous and overused comic involving stick figures on the folly of standardization?... Nah, couldn’t be.

Also, how did LSB work out for you? Take it away, Ulrich!

Is uselessd actually an elaborate false flag operation by Red Hat to discredit their opponents and install a New World Order?

...Fuck.

How do I contribute?

We’re currently hosting development on Bitbucket. You can find our repository here. There’s some relevant documentation and disjointed developer logs scattered as text files, but nothing comprehensive yet. Work takes place at the linux-devel and bsd-devel branches. Manual pages are only hastily patched up and mostly identical to systemd’s, beyond some substitutions and removals of irrelevant ones.

We use drone.io as our CI system (at least at present), and we welcome bug reports, bug fixes, patches and anything you have. We gladly await to see your contributions.

What is there to do?

Nothing too specific yet, but yes. Our TODO list isn’t particularly impressive, but here’s some general things we’re planning for:

• Getting the Manager interface running on FreeBSD.
• Integration into other operating systems, including NetBSD, OpenBSD and Debian GNU/Hurd.
• Refactoring of the core and shared files.
• Testing on dietlibc. Setting up a diet-based system takes some effort. If you have time and resources, be sure to try it out and send us patches (more like pull requests in this case, but what the hell...)!
• Get the uselessd Linux build to run as a userland process supervisor, without necessitating that it serves as PID1, as well.

These are more long term goals and kind of general, but we'll iterate as we move on. Join us.

How do I contact you?

You can find us on IRC at #uselessd on irc.darknedgy.net. Development questions, support and chit-chatting go there.

You can also meet us at the uselessd board at http://forums.darknedgy.net. You can use it as an impromptu mailing list, as well as for general Unix chicanery.

Yet again, you can also contact us at tarnyko@tarnyko.net for any inquiries. The uselessd developer will respond to you ASAP, or someone else associated with the address.

Why do I keep seeing the expression "information system" on IRC and in the page title here?

Billy was implementing a "wtf is" functionality for our IRC bot, where upon invoking the command "wtf is" with a parameter (an acronym), it would retrieve the acronym's definition from a flat file database. Upon testing it, we found that it would respond to every query with "information system" - the default match, meaning "not found". This was due to Billy being a weird person, and who can't write regexes.

As such, "information system" is now our stock response for stupid or RTFM inquiries.