However, I believe the implementation is not great.
A couple specific observations:
* lots of binaries. /lib/systemd, the logs. This more than anything else is a
tragedy. Binaries get in the way of viewing, diagnosing, understanding and
changing things. It seems like premature optimization to me - I don't think
speed requires it. I think the majority are completely unnecessary.
* copying from launchd? Commercial software vendors ship binaries. They
are aligned with them. They resist disclosure, which protects from reverse
engineering, lawsuits and user modifications. Does that align with linux?
* the config files are a disorganized mess. It is like /etc/init.d but poorly
understood and then /etc/rc.d was lumped into the same directory and organization
became chaos. I looked at one system here and in /etc/systemd there are 16 directories,
23 symbolic links and just 11 files. Try unraveling the interdependencies.
additionally the config files (which mimic windows config files) lack depth.
Simple config files can have benefits, say if a GUI read and wrote them to change
settings, but I don't think that applies here. What I noticed is that they
cannot do anything, so additional logic requires an intermediate script or
compiled binary elsewhere.
* it is responsible for too many functions. I bet it didn't solve so many in
its first iteration, but sucked in more over time. It reminds me of the
accounting program that grew to rule everything in Tron.
I wonder if these problems could be resolved. It's hard to remove complexity
and add elegance later.
> lots of binaries. /lib/systemd, the logs. This more than anything else is a tragedy. Binaries get in the way of viewing, diagnosing, understanding and changing things
would you prefer sh/python/perl/lua scripts?
some (the suckless group) view C and make && make install the perfect way to observe and change things. (I like config files and runtime configurability.)
I kinda like how a good chunk of the community complains we are "too monolithic", and the other side of the community complains we have "too many binaries". We can't win with you guys, can we?
Multiple binaries can still be part of a monolithic system (just like multiple services can still be part of a monolithic system in the web services world). A well-archetected system has strong separation of concerns — and well-defined, reasonable interfaces — between components.
If I’m writing a piece of code and I start wanting to rewrite the world around it, that’s a sign that I’m probably doing the wrong thing.
In the case of systemd, you actually have a decent case that a lot of things in Linux and the rest of the POSIX world could stand to be improved. A good, clean, portable, systems-focused approach could tackle all those things head on.
It's that the plethora of binaries are too tightly coupled and are not at all modular or interchangeable, which is materially the same as being a monolith.
I think you are smart enough to know this, and are just feigning ignorance.
Not that it matters, but I'm really happy about systemd.
Sure I have to learn new things, sometimes stuff breaks, but that has always been the case. For me most problems were with upgrading Linux distributions.
Anyhow it's great to have less distribution specific stuff and less shell scripts. Thank you and all the other systemd devs.
However, I believe the implementation is not great.
A couple specific observations:
* lots of binaries. /lib/systemd, the logs. This more than anything else is a tragedy. Binaries get in the way of viewing, diagnosing, understanding and changing things. It seems like premature optimization to me - I don't think speed requires it. I think the majority are completely unnecessary.
* copying from launchd? Commercial software vendors ship binaries. They are aligned with them. They resist disclosure, which protects from reverse engineering, lawsuits and user modifications. Does that align with linux?
* the config files are a disorganized mess. It is like /etc/init.d but poorly understood and then /etc/rc.d was lumped into the same directory and organization became chaos. I looked at one system here and in /etc/systemd there are 16 directories, 23 symbolic links and just 11 files. Try unraveling the interdependencies.
additionally the config files (which mimic windows config files) lack depth. Simple config files can have benefits, say if a GUI read and wrote them to change settings, but I don't think that applies here. What I noticed is that they cannot do anything, so additional logic requires an intermediate script or compiled binary elsewhere.
* it is responsible for too many functions. I bet it didn't solve so many in its first iteration, but sucked in more over time. It reminds me of the accounting program that grew to rule everything in Tron.
I wonder if these problems could be resolved. It's hard to remove complexity and add elegance later.