I have a friend in my LUG who is RHEL sysadmin in a thin client environment (he's been adminning *nix systems for 25 years). Their servers are not running SystemD yet, but the clients are, and he reports that they boot noticeably more smoothly than they did with SysV. He does note that it is more difficult to troubleshoot, because he's used to troubleshooting SysV and has to learn a new vocabulary to talk to SystemD.

I share the same philosophical objections to SystemD that have been listed in this this thread. It galls me to say this, but the one thing SystemD seems to have in its favor is that it works.

Why does no-one fork it and turn it back into a more "Unixy" application?

systeme?

As far as I can see, because it keeps changing what it does and is not a stationary enough target to allow a maintainable fork.

And its replacement would be called systeme_d

Now that would confuse the Francophones.

Frankly, "it does work," and for many situations it is an improvement.

The core issue that was being addressed is that there are a number of different subsystems, all (of course) owned by "process #1," that are essential to the operation of Linux. But, they all worked differently, all used individual configuration files, had no established way to communicate with one another, and could not easily work together. And, if you're tasked with maintaining hundreds of these machines, in what is supposed to be a "seamless" computing cluster, that becomes a big deal. The project has a well-defined way for the various processes to communicate, to synchronize their activities, and otherwise to work together. It is significantly more powerful than "good ol' cron." I think that the people who are working on it do have a very clear picture of what legacy issues they are trying to improve.

The main problem that I have with the project is simply that it isn't modular. It's all or nothing. Granted, modularity would increase the complexity of a thing that is already complex.

1 members found this post helpful.

No, there weren't "different subsystems, all owned by "process #1"". Each subsystem was a separate process.

Each was a separate project.

VERY modular.

The problems systemd is addressing is not something a single project can do very well. It still fails frequently, and is VERY hard to diagnose or repair.

2 members found this post helpful.