The list of dropped components is quite large. The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together.

I think Systemd has a view that those things should reliably work together. I do not fancy a revival of the past where the user has to cobble a mesh of hopefully compatible libraries to achieve the same, taking weeks to study the Arch manual and resolving tons of gotcha's, all to be broken by next week's update.

The integration of all this stuff is now actively under test and maintenance with systemd.

And yes, the mentioned services also have an impact on the scope of service managing. Because if you have a unit that depends on a disk that needs to be unencrypted, this has to be resolved somehow in the right time.

I personally have had no need for systemd-resolved, but I think for *desktop* the list of droppable components is not large.

So maybe we should first have a conversation about the *desktop* vs *container-os* purpose?

This is an impressive project especially considering there are only 4 contributors. In my opinion this should have existed prior to systemd as it is more modular and very much optional "The Suite may run either as an init system or as an auxiliary service management system under another init system." This would have been a much better direction to go on Redhat in my opinion. I might still be using CentOS or one of the forks had systemd gone this direction. Just a personal preference of course but this does not feel forced and does not appear to commandeer functionality that should not be in the init process. It's also interesting to see it implemented in Alpine Linux already though I do not see it in the edge repo guess I have to build it. I use Alpine for all my VM and bare metal servers. This may be worth tinkering with. After this is extensively battle hardened I would like to see this as an installation option in Alpine, perhaps by setting a variable much like other installation options. There are also some interesting notes in Myths and Truths [1]

I hope they are still actively developing this. last 5 commit dates which appear low for an alpha. Maybe we need to contribute to this or raise funding.

    Date:   Fri Aug 16 18:55:06 2024 +0100
    Date:   Mon Aug 12 22:33:49 2024 +0200
    Date:   Tue Feb 1 12:31:57 2022 +0000
    Date:   Tue Feb 1 12:31:42 2022 +0000
    Date:   Thu Dec 2 18:43:39 2021 +0000

[1] - https://github.com/InitWare/InitWare/wiki/Myths-and-Truths

This actually is kind of cool imo. There are things I like about systemd, and things I don’t. And this seems to fit much more closely around the things liked. Wish I had the time to play more with it on Linux. Would love to see Debian switch to something like this. Always felt like Debian was stuck between “all in” or “go without”. This would have been a nice middle ground choice to have had back in those days.

Writing software specifically for the BSDs then licensing it LGPL is like trying to sell them chilled, bottled poison from a roadside stand. What were they thinking?

That said, this sounds like what systemd should have been: a service control manager and nothing more, before they got a thirst for power and wanted to control any and every thing about the system.

But one of those already exists, it's called launchd, as long as you don't mind XML vs Windows INI syntax.

Could someone who's more familiar with this project explain the advantages? To me, the main advantages of systemd are

1) It enables better separation of concerns, Twelve-Factor App style. For example, user-installed programs no longer need to connect to a logging daemon or execute a complex daemonization dance [1]. They can just run like a normal command-line program and dump logs to stderr.

2) It cuts down on integration problems, shell script glue, and the amount of different config syntaxes you have to know. Its architecture is modular with over 100 different binaries, so you can still pick-and-choose components and do privilege separation, but because these components are all coming from the same vendor, you know they're going to work well together.

3) It can do certain things far more reliably because it's willing to use Linux-specific APIs. For example, thanks to cgroups v2, it can supervise a process correctly no matter what kind of weird forking strategy the process is using.

Since this project is intended to be compatible across Unix-like systems, it won't be able to use Linux-specific APIs, so advantage 3 is gone. It looks like it dropped many components of systemd, so advantage 2 is partially gone too. Is this project just about getting some cross-cutting concerns into the init system and having better scheduling of service startup?

[1] https://www.freedesktop.org/software/systemd/man/latest/daem...