[dane-pgp]

You say that the mono-repo contains a collection of "related" projects, but how many of those projects is it possible to install and use without installing and using at least one other project from the same repo?

It's possible to have a system with "ls" and without "grep", and vice versa, at least in principle. More importantly, it's possible to replace "ls" with a competing implementation, without having to change "grep". The systemd ecosystem is not structured in a way that lets alternatives be explored.

[newnewpdro]

As cycloptic mentioned, journald is one of the few tightly-coupled components.

The difference is the utilities you mention interoperate at the level of bare UNIX pipes and execv/argv. Systemd components are largely integrated via dbus (UNIX domain sockets), as they're mostly services, daemons, which users don't generally interact with via execv/argv.

You're comparing apples and oranges here, and I'd like to note that GNU has already consolidated a lot of those CLI utilities into monorepos and I expect more consolidation like that to happen in the future as it's a natural evolution as the system stabilizes and active developers move on to other projects.

I think your argument would be more valid if systemd weren't establishing stable dbus interfaces, and instead were inventing all sorts of snowflake, constantly changing interfaces, but that simply isn't the case.

We already have examples of systemd components being forked and used independent of the project, to fulfill some of those interfaces without bringing in the entirety of systemd. [0] [1] I have mixed feelings about those efforts, but it at least demonstrates an ability to relatively trivially break off pieces you like and leave out the stuff you don't.

[0] https://wiki.gentoo.org/wiki/Eudev

[1] https://wiki.gentoo.org/wiki/Elogind

[mook]

> I think your argument would be more valid if systemd weren't establishing stable dbus interfaces, and instead were inventing all sorts of snowflake, constantly changing interfaces, but that simply isn't the case.

This didn't _used_ to be the case, but then I just looked it up, and… Yay, it actually is now! † I just want to say thanks (to the whole systemd team) for that!

† https://systemd.io/PORTABILITY_AND_STABILITY/ — the last time I checked was when the freedesktop.org page was still current, so it had been a while.

[cycloptic]

>but how many of those projects is it possible to install and use without installing and using at least one other project from the same repo?

Nearly all of them. Have you actually tried to do this? The only thing I can think of off the top of my head that won't really work separately is journald.

[marcan_42]

People actually doing this (i.e. trying to use systemd components on a non-systemd system) end up forking the critical bits and pieces, because trying to build and use them directly from upstream doesn't work well.

See: https://github.com/elogind/elogind https://github.com/gentoo/eudev

So yes, systemd is a mono-repo containing a bunch of loosely-coupled projects, but they are still coupled too tightly to sanely distribute and use separately without a fork.

[newnewpdro]

> but they are still coupled too tightly to sanely distribute and use separately without a fork.

That's not true, forking becomes necessary when what you actually want is a different implementation fulfilling the same dbus interface.

If you just wanted intact systemd-logind and none of the rest, you could fairly trivially build systemd from source and package just logind and libsystemd and get on with your life. Maybe you'd have to carry some patches to inhibit some things like cgroups meddling in the systemd way, but that's no different than what say Debian does for practically every upstream tarball it packages.

Those projects have in a very real sense forked the components for the purposes of modifying their implementations in ways too substantial for some small packaging-time patches to cover.

I'd argue that it actually speaks to the modularity and organization of systemd's code that forking was a more attractive option for these folks than starting over with just the dbus interface in hand.