>I think Linus is right when it comes to systemd as an init, but really
>that is not the problem.

>The real problem is that systemd is not just an init, it is or is
>rapidly becoming, a locked in operating system frame work, looking for a
>friendly kernel and a desktop environment.

>People setting it up as an init system question and comparison either
>are part of the problem or have no (expletive deleted) clue when it
>comes to the big picture.

>If another broader question about systemd "the blob" rather than "the
>init" was asked I wonder what the response would have been?


>Clarke





Hello, Clarke! Great to see you again.

If I might offer a slightly different perspective, I think that systemd is
really only part of a much larger and far more longstanding problem that has
never really been addressed by Debian and a few others.

The reason that systemd causes so many problems on Linux distributions is
because the distribution makers give certain packages a special preference
over the alternatives. The lock-in that you describe really comes from the
fact that when a distributor makes a preferential choice, that becomes the
"de-facto standard" for that distribution, not necessarily the software
itself. System 5 is just one of about 5 different init possibilities.
Sendmail/Postfix or EXIM could be cited as another example as mail ackages
seldom work seamlessly for support for all three. The same could be said of
KDE and Akondi - by default on Debian and just about everywhere else, it
insists on installing MySQL over PostgreSQL or NoSQL.



What you are really getting when you use a traditional binary Linux
distribution is really only what binary chains that distributor wants to
support.



Personally, I think that the only solution is the replacement of the package
manager with something more akin to a version manager, where you can have
multiple versions of the same binary package chains with differing
dependencies based on what the user's needs are. Since that would include
init systems, things like scripts for a particular daemon would be separate
package, installed automatically by looking at what init is installed.



Just my 2 cents.



T.J.