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 <emilianomarin...@gmail.com > 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 <sl...@troubleshooters.com> > 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 <br...@perens.com> 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 >> > <emilianomarin...@gmail.com >> > > wrote: >> > >> > > I no longer feel like I can >> > > trust "init" >> > > >> > > >> > > >> > > https://lkml.org/lkml/2017/7/6/577 >> > > >> > > _______________________________________________ >> > > Dng mailing list >> > > Dng@lists.dyne.org >> > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> > > >> > > >> _______________________________________________ >> Dng mailing list >> Dng@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> > >
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
