Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sun, Nov 16, 2014 at 01:28:35PM -0500, The Wanderer wrote:
> On 11/16/2014 at 11:23 AM, Ludovic Meyer wrote:
>
> > On Sun, Nov 16, 2014 at 09:43:23PM +0900, Joel Rees wrote:
> >
> >> I have been informed off-list that some might misinterpret
> >> something I wrote here, so I will attempt to clarify a few things.
> >>
> >> On Fri, Nov 14, 2014 at 8:59 AM, Joel Rees <joel.rees@gmail.com>
> >> wrote:
>
> >>> This all would have been okay for them, if they had followed
> >>> proper engineering (management) principles. As long as they were
> >>> an independent maverick, they could do what they want. That was
> >>> correct, that was good.
> >>
> >> I want to repeat that. As long as they kept their work out of the
> >> mainstream, it was no problem.
> >
> > Your definition of mainstream is strange. So far, I didn't see
> > systemd being on something else than Linux, and GNU/Linux is not
> > mainstream ( android is, but systemd is out of android ).
> >
> > So they kept it out of mainstream, unless you define mainstream as
> > "being used by users", in which way I would love to see how you get
> > user feedback without having users in the first place.
>
> I suspect that he meant "the mainstream of Linux", which is reasonable
> considering the scope of the discussion.
Sure, and what does he mean by that ?
because I suspect also that Android, being Linux based, is not the mainstream
he is speaking about. So is Debian more mainstream that Ubuntu ? Is Debian
more mainstream than Mageia or Opensuse ?
if he want to be clearly understood, and I think we all want that, he must
be a bit more clearer in what he say.
> >> They could refine their API as they went and the repercussions were
> >> limited to their own source tree. That means they could redefine
> >> the API as necessary without interfering with the day-to-day
> >> operations of thousands, or even hundreds of thousands of users.
> >>
> >> The more users you have, the harder it is to fix an API error.
> >
> > yeah, and that's why there is a table :
> > http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
> >
> > now, the linux kernel do not have such table, and prevent anyone
> > from writing a out of kernel module due to that, despites requests.
>
> One important distinction:
>
> The Linux kernel recognizes and maintains a separation between internal
> and external interfaces.
>
> They refuse to stabilize and fix on, or I think even particularly to
> document (beyond the source code itself), the internal interfaces. Doing
> so would constrain them from making structural and design improvements
> when and as they think that is necessary.
I know the arguments, but this doesn't contradict the fact that there is
demand for such interfaces. This is also something that windows, solaris
or mac osx offer, and that help hardware vendors to support
their systems, and companies to offer software (firewall, antivirus
are the example that came to mind, but i am not dealing with
windows anymore).
Now, that's indeed a costly approach due to the reduced agility,
and while I am sure this can be surely automated, I can see why
kernel coders do not want to take care of that ( coders in general
would prefer not care of boring stuff and constraints, as we
can see in the free software world, who is hard to consume unless you
have group between users and coders to make thing usable ).
> 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.
And this, despites having (IMHO) a bigger need for
a internal interface of the kernel than one for systemd.
By bigger needs, I mean that there is a lot more of people wanting to
have out of tree modules, while I guess we wouldn't see more than 5
differents reimplementation of some systemd components.
( and again, having people wanting a internal interface doesn't mean they
should have one, if kernel devs prefer their freedom to innovate, that's
their privileges ).
So yes, systemd do have the same policy as kernel, except no one
write huge wall of text about kernel devs attitude and policy anymore,
and even celebrate them.
--
l.
Reply to: