Writing code is a creative process. Obviously creator's attitudes infuse the creations.
Comparison to handwriting is a poor one, if somewhat evocative. It's more like writer's style.
Some creators adopt YAGNI philosophy, writing code that is simple, easy to understand, but doesn't suggest any expansion paths, and can turn to spaghetti if the expansions are managed. Some reinvent every wheel, writing every function themselves, others take the "golden hammer" to the extreme and create a dependency hell, trying to create a small centralized core that does everything using library functions. Some create rigid user interface following optimal use cases (actual or mistakenly imagined), others take customizability to the extreme, making the interface unusable mess until you take half an hour to configure it and remove all the crap you don't need. Some make programs that do only what says on the box and nothing more, others create APIs or operating systems disguised as applications.
Systemd started as a very simple, neat idea:
- create an alternative for initV that parallelizes startup of services;
- to speed up startup more, not to delay startup of services waiting until other services initialized, provide socket management, creating sockets "customer" programs would wait for, then bind them to their standard "providers" once they started up.
- do away with rigid sequence, instead manage startup as a set of dependencies to reach a certain state.
The idea was very sound and nice. Except it didn't end there.
- Some services needed these sockets actually working and not just present. So let's replace the provider and create own replacement as a part of systemd! And screw well established strategy, we're rewriting it our way! Here, take the binary log files!
- Some services didn't really work with the "dependency tree" strategy, since ancient times written as sequences of operations. These couldn't be easily parallelized. So screw your firewall, have ours!
- Some services used alternate communication methods that sockets. Kill them off, replace with systemd functions!
- Some of them would centralize startup of other services as needed. But that's our job! Die, inetd with your easy config!
And even if each "motion" by itself had a valid justification, the replacements offered by systemd are sub-par. Primarily because systemd developers don't believe in simple, straightforward, easy configurations. It's their attitude rubbing off.
A decent system does offer a lot of flexibility, with all kinds of obscure options, but it primarily offers sensible defaults for every obscure option, so you can get your basic work done in 2-3 lines, and if that's not sufficient, you will find what more can and needs to be done, never forcing you to state the obvious. Systemd though doesn't. You need to alliterate every little thing you want it to do, because the defaults just aren't there. And with some of its demands being quite obscure, it's often hard to find *what* the defaults should be. "Why should we make it easy if we can make it hard? If nobody ever has to write all these little details, they'll never know we had to work to implement handling them!"