Re: [dev] Never Ending Systemd Chronicles

From: Kurt Van Dijck <dev.kurt_AT_vandijck-laurijssen.be>
Date: Mon, 8 Aug 2016 10:53:25 +0200

--- Original message ---
> Date: Sun, 7 Aug 2016 22:57:27 -0400
> From: Alex Pilon <alp_AT_alexpilon.ca>
>
> On Fri, Aug 05, 2016 at 01:12:12PM +0200, Hadrien LACOUR wrote:
> > But when you had to modify or write unit files, it wasn't fun.
>
> Dead easy. And you can even add to the definition rather than rewriting.
>
> > Even if most of the vocabulary is simple, the number of keywords is
> > simply too high;
>
> So is the number of things in your $PATH…
>
> anyhow, man systemd.directives, be momentarily dumbfounded by the number
> of them, then shut up and forward slash.
>
> > while a shell script can be understood by anybody.
>
> Bullshit. How often have I had to check people's lockfile code, or
> manual isolation? How often have I had to manually kill things all over
> the place because somebody's shitty daemon spawned a subprocess that
> daemonized itself or because the shitty pidfile wasn't updated (not
> *only* solved by systemd, thank goodness)? And don't get me started on
> non-robust shell scripting that I've sometime had to read. I'm tired of
> that nonsense.

Using pid files is not proposed here, and you repeat the critics against
it. Why?

You're also suggesting that writing systemd unit files can be done by
anybody (using man pages) and you state that shell scripts cannot be
written by those people?

Accept that by average, people don't read man pages when it works out of
the box. That applies to shell scripts _AND_ systemd units.
And also accept that people solve more problems using shell scripts
than writing systemd files.

Advanced things including locks etc. is in all cases reserved for
advanced users.

>
> Having policy built on top of mechanism is a Good Thing™, though your
> attempt may look like regurgitated dog's breakfast. Having mechanism
> alone is not a good thing, and except for trivial systems, is such a
> clear sign of immature design.

"Policy" belongs to the overall system design, and should not be confused
with "components" or "mechanism".
Components that only work within strict policies ignore the reality that
not all systems benefit that same policy. top-level applications make an
exception here. I'd accept systemd as top level application, not as pid 1.

Did you, by the way, propose that e.g. Android should switch to systemd
too. Your argument seems to propose that everyone should obey to
systemd's policy design.

Kurt
Received on Mon Aug 08 2016 - 10:53:25 CEST