Re: systemd is here to stay, get over it now
Matthias Urlichs wrote:
>Thorsten Glaser:
>> systemd is a backdoor in that, like the availability of Steam
>> games for DDs, it has a chance to hinder the progress of all
>> projects done in the spare time of the people affected.
>Yeah. It "has a chance".
Yes. (I was more or less referring to this discussion as time
killer, though.)
>It also "has a chance" to give people a big chunk of spare time back,
... maybe...
>because they can find and fix their daemon startup bugs a whole lot
>faster (and more consistently) than with SysVinit.
In SYSV init, I can just use "set -x". That just rocks.
(But anyway, I do not wish to discuss this here - there
are more suitable places/threads.)
>> systemd is a backdoor in that, by means of vendor lock-in
>
>Which vendor are you talking about, exactly?
"vendor lock-in" is an atomic expression, meaning the mechanism
to have one thing from vendor X depend on one other thing from
vendor X, which depends on just another thing from vendor X,
without being able to exchange components against those from
another vendor.
Good example here is autoconf 2.62 and later, which depend on
GNU m4, although previous versions also worked with BSD m4.
(There are patches, so 2.62 works but 2.63 doesn't, now.)
GNU software in general is the most prominent example of "vendor
lock-in" I know. The vendor in this case is the GNU project.
In the systemd case, it's systemd, obviously.
>The solution to any grave bug will be, like with any piece of userland
>software, to fix that bug and restart systemd. You can't do that with the
If you can fix the bug, sure. If not... or not in time...
>Again: You want diversity and a non-systemd Debian? Fine.
>Then shut up and help with the work required to get there,
With Debian as it is now, there is nothing needed (except
to upload the prevent-systemd package in its next iteration).
Debian as it is now works just fine without systemd. If *you*
want to change that, it's *you* who are breaking it.
bye,
//mirabilos
Reply to: