My problem with all these treatises on how software that "does a lot of things" is bad and more likely to fail, like frequently comes up in systemd discussions, is that while it is true in the abstract, these arguments never seem to account for things that people actually need to interact with.

Sure, it works great for libraries! Tiny libraries make for a very nice development experience and, with some reasonable dependency policies, very reliable and maintainable codebases. But that's because your target audience are *developers*; it's their *job* to pick the right tool for the job.

Your typical end user isn't a developer. They do not have the time or energy to allocate to painstakingly evaluate a "stack" of tools for every little thing they want to do.

They are looking to have a single program, a single UI, a single point of interaction with a coherent mental model, that allows them to complete their task from start to end. Where they can assume that the steps integrate, and they probably won't run into trouble on the common path.

And systems built to the "Unix philosophy" are notoriously bad at this! They are developed more or less in isolation - that is the point - and so they all have slightly different interaction modes, that are tailored to the specific task that the tool is meant to address. They may or may not integrate out of the box. If you're not a developer, this _sucks_.

So yes, by all means, modularize your libraries. Modularize your packages. Modularize every bit of internals you have! But don't try to universally apply the "Unix philosophy" to every piece of software without recognizing that *this is not actually what end users want to interact with*.

If you want your thing to actually be usable by people who aren't nerds, it *needs* to be usable through an application that does more than one thing. And this applies to anything a regular user might need to interact with directly; yes, including a service/system manager.

And if you insist that it is only a low-level tool, and people are expected to build end-user tools on top of that, then you actually need to make sure that it has a workable, reliable and consistent API to build against. None of this "custom string format you need to parse" crap.

(And yes, there are legitimate criticisms to be made of systemd governance. But "it doesn't follow the Unix philosophy" without further qualification is just about the worst argument you could be supporting it with.)

@joepie91 I'm not quite sure what kind of argument you are trying to make here...

- "end user" is ill defined. The end user who wants to have a single point of interaction, and does not care for details, is probably well advised to go to Apple computers. I have extreme doubts that the systemd program conglomerate would have any discernible benefit for such a person, compared to the other *ix tools.