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.

When the original programmers felt their program was mostly done and stepped away, others came in, a new breed, and diverted the trajectory of the projects.

Well engineered software projects eventually are completed. And then people shouting that anything not actively "maintained" is "depreciated" come in and attempt and succede in using software for political gain or control.

Most of the "Debian Developers" are not the same sort of people that started debian. They are often not programmers.

We who actually write software are looked down by them. The people who use software are looked down upon by them. They are now a middle man, using their position for control, rather than for helping. Like a bad government.

The Debian social contract even says the distro is for the sake of the users.

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.