← Back to context

Comment by actionfromafar

3 months ago

It could mean that, but it could start much simpler. Instead of trying to implement the whole API surface and behaviour, focus on a single consumer i.e. a single program which today depends on systemd.

Shim out enough for it to at least run in some capacity on something which does not have systemd.

Go from there.

6 comments

actionfromafar

Reply
danudey  3 months ago

Do you have examples of what you suggest, 'a single program which today depends on systemd' which would make sense to decouple from systemd?

The amount of work that a project would require over the long-term would be pretty substantial, so I assume that there are a lot of these things which you would suggest fixing over time to be rid of systemd, but I'm not certain what the end benefit of this work would be. Interested to hear more.

  • actionfromafar  3 months ago

    Gentoo has a little list¹, along with suggestions for modifications. Instead of modifying the programs, one could experiment with a shim library and leave the program code unmodified to see if that's a viable path towards portability. The end benefit would be portability to systems lacking systemd proper.

    (Now, the importance of portability is a separate question. If you want systemd to "eat the world" it's even a negative value.)

    1: https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd

    • Brian_K_White  3 months ago

      This kills me when, of course all these apps were already portable for decades and only just recently all now need a "viable path towards portability".

tadfisher  3 months ago

You'll find that there are very few such programs. This shouldn't be all that surprising, because most programs do not care what process started them or where stdout is logged.

The most prominent dependency on systemd components is Gnome on logind, which already has a shim.