copy&paste of one of Teodore Tso comments:

So I can't speak for Linus, but the reason why I can't trust systemd is
> that I don't believe that the systemd maintainers have "good taste" --- as
> used by Linus in his TED talk: ted.com - The mind behind Linux
> <https://www.ted.com/talks/linus_torvalds_the_mind_behind_linux>
>
> And it's not about how to code singly-linked lists, but as Linus says,
> it's something bigger. "Good taste is about really seeing the big patterns
> and kind of instinctively knowing what's the right way to do things." It's
> hard to explain, other than to give examples, and so that's why Linus gave
> the linked-list example and people immediately lock into that --- because
> it's concrete. But the "good taste" thing is a lot more than that; it's
> just that trying to define "good taste" and "good judgement" can be a very
> hard thing to do.
>
> For me a lot of "good taste" is about adding complexity when it's needed,
> and avoiding it when it's not needed. And if you do have complexity, making
> sure you have the tools so you can debug things when they break. And for me
> one of the things that I don't like about systemd is that it has added a
> lot of complexity, and when it breaks, trying to debug it can be almost
> impossible.
>
> For example, sometimes (it's flaky and intermittent) systemd will think
> that a device hasn't appeared, when it darned well has (you can see it in
> /dev), and so it will hang the boot and you can drop into single-user
> shell, but there's nothing you can do to debug it --- or force systemd to
> understand that, no really, the device is there, and you should let those
> unit files blocked on the device dependency to start. I've ultimately
> worked around the problem by removing all of my automatically mounted
> partitions (except for the root partition) from /etc/fstab, and adding the
> following to /etc/rc.local:
>
> (e2fsck -p /dev/callcc/build && mount /dev/callcc/build) &
> (e2fsck -p /dev/callcc/media && mount /dev/callcc/media) &
> .... etc.
>
> It's not that there was a bug, and I had to work around the bug. Bugs
> happen. They happened with Sysvinit scripts, but I always could debug them,
> because, well, they were shell scripts. It's the fact that systemd has
> added all of this extra complexity, and there is absolutely zero way of
> debugging it. For me, that's a sign of inexecrable taste.
>


On Mon, Jul 10, 2017 at 5:11 PM, Emiliano Marini <emilianomarini82@???
> wrote:

> I think it's clear he's talking about systemd when he says:
>
> "You all presumably know why."
>
> Plus, there is some interesting comments from Teodore Tso talking about systemd in G+ https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J
>
>
>
> On Mon, Jul 10, 2017 at 4:39 PM, Steve Litt <slitt@???>
> wrote:
>
>> What did Linux mean by "init"? A lot of people use the word "init"
>> synonomously with sysvinit, in which case this would appear to be bad
>> news for us. On the other hand, perhaps he use "init" to mean the init
>> system, regardless of brand. I can't tell from context.
>>
>> SteveT
>>
>>
>> On Mon, 10 Jul 2017 08:57:33 -0700
>> Bruce Perens <bruce@???> wrote:
>>
>> > The entire paragraph is even more damning:
>> >
>> > And yes, a large part of this may be that I no longer feel like I can
>> > trust "init" to do the sane thing. You all presumably know why.
>> >
>> >
>> > On Mon, Jul 10, 2017 at 7:20 AM, Emiliano Marini
>> > <emilianomarini82@???
>> > > wrote:
>> >
>> > > I no longer feel like I can
>> > > trust "init"
>> > >
>> > >
>> > >
>> > > https://lkml.org/lkml/2017/7/6/577
>> > >
>> > > _______________________________________________
>> > > Dng mailing list
>> > > Dng@???
>> > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>> > >
>> > >
>> _______________________________________________
>> Dng mailing list
>> Dng@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>
>