Great explanation of the improvements systemd made in ArchLinux
 

One of the init script maintainers in Archlinux explains why the switch to systemd was a good idea. Helps to understand some of the challenges facing the init process.

https://www.reddit.com/r/archlinux/c...ystemd/d3rhxlc

countdown to a flamefest ... 3 ... 2 ... 1 ...

Meh ... "Why bother?" The OP in the referenced thread brings up some excellent points, and he seems to speak from experience.

Some people have commented that "the former way of doing things" started to develop some seriously-thorny problems when computers became fast. Hard drives became fast, too ... and now we have SSSD, "even faster." Suddenly, timing holes and race-conditions began to develop, particularly in the startup-scripts (which have to deal with the fact that some devices take longer to initialize than others do, and so on). None of the various subsystems had explicit awareness of one another, nor was there an explicit mechanism for synchronization or parallelism.

Therefore, I happen to think that the people who embarked on systemd did have a legitimate goal. They had identified a problem that needed solving . . .

. . . especially when, as we have today, "I've got a rack-room full of five hundred of these beasts!" :eek:

But I do think that they wound up dipping a bit too generously into "scope creep." I'm not entirely persuaded that all of the components that are there, actually needed to be, and I long for greater choice in the matter.