Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sun, Nov 16, 2014 at 04:09:52PM -0500, The Wanderer wrote:
> On 11/16/2014 at 02:51 PM, Ludovic Meyer wrote:
>
> > On Sun, Nov 16, 2014 at 01:28:35PM -0500, The Wanderer wrote:
>
> [about the Linux kernel developers]
>
> >> They do, however, maintain their external interfaces - rigidly so,
> >> sometimes to what others might call the point of insanity. An
> >> intentionally user-visible API from the Linux kernel will
> >> essentially never change, and if an exception to that is ever made,
> >> it will be announced *years* in advance. That is one reason why
> >> they try to be *VERY* careful to get the user-facing interface
> >> "right", at least on some basic level, before ever pulling it into
> >> a released kernel.
> >>
> >> The kernel interfaces which kernel modules need to use are
> >> kernel-internal interfaces.
> >>
> >> The systemd interfaces described on the page you link to appear to
> >> be systemd-external interfaces.
> >
> > I know the difference, and I know this is just some tradeoff, there
> > is advantages and disadvantages on doing that, and if I was cynical,
> > I would postulate that companies like redhat do push for that model
> > of internal/external interfaces in the kernel, because this give a
> > reason to take entreprise distributions. ( ie, SLES, RHEL do have a
> > stable promise API for each release like Windows do, because
> > customers do pay also for that )
> >
> > My point is not that kernel or systemd devs are right or wrong. But
> > the point is that people who complain that systemd do not have a
> > internal interface yet forget that kernel do not have one since the
> > start and will not have in a near future.
>
> Er... were people complaining that systemd does not have a stable
> internal interface?
>
> I thought (given the context of that linked-to page) that the complaint
> was that systemd does not have a stable *external* interface.
I think it does. The real question is
- is this interface sufficient
- is the boundary the one we agree on
> With possible room for dispute about what constitutes an "interface",
> what qualifies as "stable", and maybe even what counts as "internal" vs.
> "external"... but I didn't see anything that I recognized as being a
> complaint about systemd's internal interfaces.
Let's take the one about logind. What people complain is that
logind requires systemd as pid1, and the reason about this is because
logind requires the internal and non stable interface of systemd, otherwise,
someone would be able to run it with another init, provided it implement the stable
interface (this particular interface that do not exist).
Or people do complain they cannot replace or remove journald. Again, because
there is no separation between the 2, because there is no documented
separation ie a external interface. I hope this clarify my point, but we seems to
agree on this, if I read well what you said just after.
> No one is even trying to implement something outside of the systemd
> project that talks to systemd's internal interfaces directly, AFAIK -
> unless systemd-shim does, but I didn't think systemd-shim talked to
> systemd itself at all, just to other tools provided by the systemd
> project.
>
> And if the interfaces which those tools use to talk to
> systemd-the-init-system are considered "internal" interfaces, which is a
> position for which an argument could be made, then that would simply
> bring up the argument that since those are separate tools the interfaces
> between them should be considered external to each tool. Whether or not
> that's a reasonable argument, and the extent to which it might be
> possible to treat those interfaces that way, could be a discussion worth
> having - but having it would require *getting* to that point first.
>
> --
> The Wanderer
>
> The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man. -- George Bernard Shaw
--
l.
Reply to: