Date: Sat, 27 Aug 2016 17:37:14 +0100 From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com> To: Adrian Chadd <adrian@freebsd.org>, Supervision <supervision@list.skarnet.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Linuxisms in s6 Message-ID: <cf1cbc74-d4f3-3522-68a2-603c00539cd6@NTLWorld.com> In-Reply-To: <CAJ-Vmo=1mLANmtOhXS9v1h5tVHt%2BjMPvge2A5Pb_zLGP7mLvAw@mail.gmail.com> References: <37d5159b-4957-42f8-2252-fa53d7446bb6@NTLWorld.com> <CAJ-Vmom1hsUxkXUwAn48E7B2zB_0TCPFiq_ud2Rhym5gvxzWDQ@mail.gmail.com> <20160825194820.GI92256@e-new.0x20.net> <CAJ-Vmo=1mLANmtOhXS9v1h5tVHt%2BjMPvge2A5Pb_zLGP7mLvAw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Adrian Chadd: > Sure, but I'm looking for something more generic than just devd. Like, > notifications about events like "default route is up" can be done by > sniffing the rtsock, but notifications like "ntpdate has updated the > date, we can now do crypto services" doesn't happen there right now. > You're reinventing upstart. The lesson of upstart is that whilst the event-driven paradigm looks like the bright shiny future, once one gets down to the details it is a lot harder than it at first appears. I strongly recommended learning about upstart, and especially learning the problems that people hit with it, to anyone going down the same route. The Debian systemd Hoo-Hah had some lengthy discussion of upstart. (I regret not having bookmarked the discussion that I once came across, where someone opined that xe preferred systemd to upstart because at a Linux conference the systemd presentation had been exciting and had been put forward as the wave of the future, where upstart had been presented as old-school, traditional, and boring. Ironically, this person wasn't aware that the designs are exactly the opposite of that. upstart has the novel event-driven design where the system is configured with the information that event A triggers programs P, Q, and R, and the system starts by raising a "first event", that runs programs, that raise further events, that run further programs. Whereas it is systemd that has the conventional design, shared by Mewburn rc and others, of starting from a goal, working through a dependency tree, and doing topological sorts.) The Debian people chose to improve a non-event-driven architecture instead. It's a lesson to be learned from SMF, in fact. One can have a lot more additional abstract targets, such as "/milestone/name-services" and "/milestone/system-clock", and dependencies to and from them. The world is not 2 to 4 run levels plus "DAEMON", "NETWORKING", and "$local-fs". That said, something like this hypothetical "/milestone/system-clock" is a milestone that would need to be reached *very* early on in the bootstrap process. Fixing up the clock is something that both the nosh system manager and systemd handle themselves directly, outwith of service management. More on this in a moment.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cf1cbc74-d4f3-3522-68a2-603c00539cd6>