> We know because there are other init systems that do follow these design principles much more closely.

Which one(s) would you recommend/suggest?

> go against the Unix philosophy

The Unix philosophy is not an end goal neither. It's not even something well defined. Everyone seems to have their own view on what it is. I personally take the "everything is a file" and "do one thing well and be composable" rules as a guideline, an ideal to consider when designing stuff, but not as a strict thing to adhere. It might be something that's nice to have in some contexts and something that's useless or even counter productive in others.

What I mean is that I take "does not follow the Unix philosophy" as something to look into to find potential improvements or design issues, but not as blocker or a counterpoint in itself.

To me, the Unix philosophy discussion is quite moot. Those discussions are often very vague. I don't care much that systemd follows the Unix philosophy or not. I'm more interested in what actual problems this does cause in practice.

You do, however, point out something practical here:

> An init system should do one thing (well): manage system services

I suppose one could consider that to manage system services well, you have to manage "everything". I also suppose systemd's scope is way bigger than "managing services", they do want to "fix/figure it all". It seems reasonable to me not to agree with any of these things.

I do believe the uniformisation systemd causes is a good thing, but I absolutely understand that the big scope can be seen as an issue, and I almost fully agree with your last paragraph. I would object to the statement that systemd is not a monolith and is composed of many programs is a moot point: this modularity still means that you can replace individual systemd programs with your own implementations if needs be…

… as long as you provide the expected features / APIs, yes, you are totally forced into this indeed. systemd is a de facto API. It brings / forces standardization at the cost of diversity. It broadens the standardization that comes with UNIX/POSIX and XDG. I'm sure this can be criticized in a few ways: the API design, the scope, the featureset, the way the project is lead…

The alternative to systemd is non-existent standardization and each alternative designs stuff its own way on their side. For the better and for the worse. I can see how systemd can be criticized for when we are in "the better" cases. I personally easily see the worse side where several projects (for instance desktop environments) would each have to implement features that come with systemd. And programs on top of these environments now have to implement APIs of each desktop environment to be well integrated.

This is more work for everyone.

I guess this is a diversity vs efficiency balance to strike and we don't all see it at the same place.

I suppose another alternative would be to have different people working on different implementations that are then grouped in some common "system core" package or set of standards that everyone adopts. I'd probably be happy with that, if this is at all possible.

You can keep the order of things even if you want to avoid using cat:

   < something filter step 1|filter step 2|filter step 3

What tool do you use to schedule tasks?

Have you written your own Cron in Ruby?

> This shows a lack of understanding.

I would say your comment either shows a lack of understanding, or that you completely missed the point.

> The example of "writing your own script" is no different to a non-systemd system. Why would a script work or not work based on systemd?

Of course, you can write the service itself in Python or Ruby or whatever regardless the service manager. The point is that with systemd, or upstart, or other service managers like this that make things more declarative (launchd?), you don't have to write a script to manage the service at all.

On systemd, you declare which services yours depend on, how to run it, which user should be used to run your service, and many things are handled for you, including many security mechanisms you don't need to think about and provide further config for this stuff that would be a mess to handle with the traditional way of writing a custom rc script per service.

The problem is not being able to write in languages like ruby or python. It's to have to write something at all.

systemd makes many things declarative that were historically procedural, potentially painful to debug, code.

This eases distro maintenance and I suppose is one of the top reasons most distros adopted it.

wrt the Unix philosophy, discussions about it related to systemd are often (always?) too abstract to be useful, I'd suggest talking about specific problematic points.