Things were already a complex mess of hacks and workarounds
needed to fight the inevitable rotting of archaic software.

The login of what's in, for example, /etc/rc3.d/ where the files names S
are for when it starts that run level and the K files are for when you
leave that run level are a kludge. The numbers are a kludge.
The idea that you linearly "do this then that then that then that" is
ludicrous.

The idea of SystemD that there is an target-objective and dependencies
makes me think of MAKE(1). Some of the dependencies _may_ have already
been met and their ordering matters, though some can be done in parallel.

The flexibility and generality of SystemD better reflects system
management that the simple run-levels. It frees you from the idea of a
hierarchy of states/levels and focuses on what facilities you want.

Looking at it as a collection of files so misses the point.

Looking at it as "something.after" so misses the point. In this case
you are back to the linear sequence thinking instead of the
target-objective thinking. I'm not saying that you couldn't construct a
linear set of dependencies, but SystemD is capable of much more that
that, more subtle and finer control.

--
Each success only buys an admission ticket to a more difficult problem.
-- Henry Kissinger, Wilson Library Bulletin, March 1979
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx