Was glad to see this; thanks! Systemd has made my Arch system overall much easier to administer, but the monolithism makes me nervous. It'll be interesting to see how things look once they've been broken up a bit.

I'm curious: are you trying to rescue a kernel of value from the systemd project where it improves on existing systems, or is this mostly a proof that it didn't need to be built so monolithically in the first place?

It's a little bit of both, coupled with the fact that I simply wanted a challenge, being a bored sap and all. This is probably the first remotely noteworthy thing I've done.

The end goal is to drive systemd into a direction that focuses succinctly on process management, having a portable base that can be transposed to other operating systems. Still quite some way to go, but hopefully it'll be done some day. But yeah, supplying systemd's core features for people who would like to have a conservatively developed and focused service manager that won't suddenly swallow the windowing system one day, is a key goal. Captures the gist of it.

Eventually I might transfer control to someone else and focus on my own interests. The eudev project lead has expressed some interest in us.

I'm one of those people who find most systemd opposition rather unconvincing, but good luck to you anyway.

I was surprised by the fact that you'd actually removed the mount and device unit logic from your fork. In my view, the init/service manager (with its dependency resolver) is the correct place for something like that because services depend on devices and mounted filesystems being available. How should those things be handled, if not there? Udev-triggered units and systemd generators seem to me a very clean way of handling the problem while maintaining backwards compatibility with /etc/fstab and other configuration sources.

systemd's purpose is to deprecate fstab(5) entirely through GPT partition discovery.

These things can already be accomplished through a device node manager, such as (e)udev. We just no longer handle maintaining it, because it doesn't belong here.

I don't see deprecating fstab as a bad thing, if it's possible. Less static configuration is pretty much universally good. It's also pretty much zero burden on systemd to maintain fstab compatibility indefinitely.

However, I was asking for specifics. Accomplished how, exactly?

udev can generate an event and run a shellscript or something when devices become available, but... then what? What processes the event and ensures correct behaviour for dependent services?

Let's say that upstream systemd adds further features to the core init code (eg. additional unit file syntax). Are you going to backport this code to uselessd? Or rewrite it? Or ignore new features?

Right now we're at a stage where we're not all that focused on adding completely new features, but cleaning up what exists. In general, whether or not we include a new unit option depends on how we gauge its usefulness.