On Sun, Feb 21, 2016 at 08:34:59PM +0100, Laurent Bercot wrote:
> That's awesome! thanks for spreading the good word :)
Many thanks for your appreciation then :)
> I would offer to proofread your slides, if you have any, but if
> you're giving the lecture in Chinese, my help would be very limited. :)
In fact, I often directly use the outline as the slide, ie. my slides
(if any) often look just like outlines. And unfortunately, my oral
English is worse than terrible, so the lecture would be in Chinese :(
> A few questions / requests for details, related to your outline:
>
> 1.1.2.1: in "signal handling", I assume you're talking about both
> SIGCHLD management (to reap orphans and restart supervised processes)
> and SIGINT/SIGUSR1/SIGUSR2 management (for the shutdown procedure) ?
Plus PID 1 can choose to block SIGKILL...
> 2.2.1: I think chainloading would be better addressed when you talk
> about run scripts - that's where it shines. s6-rc, and more generally
> a service manager, isn't closely related. In the s6-rc implementation,
> execline is only used in the oneshot scripts because it allows me to
> precompile them in the simple cases - but really, scripts can be
> written in any language, and I don't want people to assume that s6-rc
> is tied to execline when it's not (I mean, it's used internally, but
> users don't have to know the language to use s6-rc).
Well, that's a matter of topic organisation. I plan to talk about the
service directory, the scan directory and s6-svc(1) / s6-svscanctl(1) in
the s6 part (`notification-fd' would be mentioned, thus part 2.1.2);
once the specification of the service directory becomes familiar to the
audience, the s6-rc service definition directory would be an easy
extension, which lefts space for other related topics.
And for "other related topics", here I chose service directory
deployment (because s6-rc seems to represent your preferred variant of
it) and execline (because `./run' and `./finish' in s6 can be any
executable, but `./up' and `./down' in s6-rc oneshots must be
execlineb(1) scripts even if they can still call other executables).
I do not quite have the habit of rehearsing lectures, but I reckon this
organisation might make 2.1 and 2.2 somewhat even in time duration.
> 2.3: I feel like your content is more about fd-holding than logging
> itself. Personally, I would make a section about fd-holding, and another
> section about logging, even if the latter ends up being very short. In
> the logging section, you could address things like the logging chain,
> the need for services to log to stderr, and your current 2.3.3 about
> syslogd, for instance.
Again a matter of organisation: as shown above, I just happen to prefer
to organise topics into chunks of similar sizes :)
> 2.4: I don't know Plan 9 but keep hearing good things about it. If,
> whenever you have the time, you could sum up the similarities between
> DJBesque design and the Plan 9 spirit, I'd really appreciate it.
I am, admittedly, mainly a high-level programming (shell, python, LaTeX,
etc.) guy, but just got very fond of the Unix philosophy through early
training in shell scripting, so the items in part 2.4 are purely
phenomenological. Nevertheless, "question the interfaces" (as you
summarised) is among the most important things that I have felt in both
DJB-styled software and Plan 9.
> 3.2: what's this about emptyenv -p and setproctitle ? (Maybe the answer
> is in the tgz, which I haven't looked at. If it is the case, just say so
> and I'll have a look.)
Part 3 is dedicated to deployment details, and 3.2 is about trivia with
particular services: dcron dies without `./nosetsid'; openssh and
openntpd, which may change process titles to `sshd: username [priv]' /
`ntpd: ntp engine' / etc. (as can be seen with ps(1), htop(1), etc.),
when run with all environment variables cleared with emptyenv(1), are
found to only display truncated titles in above-mentioned utilities, and
retaining $PATH seems to somehow resolve this issue.
> Congratulations again for your work,
And thanks again :)
--
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Received on Mon Feb 22 2016 - 01:35:07 UTC