[mdlug] Systemd

[Aaron Kulkis]

<https://lists.debian.org/debian-devel/2012/11/msg00624.html>

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]
Re: Systemd

     To: Chow Loong Jin <hyperair at debian.org>
     Cc: debian-devel at lists.debian.org
     Subject: Re: Systemd
     From: Kevin Toppins <Kevin.Toppins at gmail.com>
     Date: Thu, 22 Nov 2012 01:29:39 -0600
     Message-id: <CADkoAxhNHwFEkRvB27O3jy9pXAKxL=2hTj+RXKgTMTHxAGNNcQ at mail.gmail.com>

Thu, 22 Nov 2012 12:56:09 +0800 from Chow Loong Jin <hyperair at debian.org>

> >  -> What role is systemd designed to facilitate?
>
> An init daemon. But why don't you ask yourself -- what role(s) should an init
> daemon play anyway?


Thank you.



Everyone raising a fuss and not many seeing the focus I am trying to
direct you towards -> this *had* to be answered by someone other than
myself.

Let's (just to show what I mean), consider an init daemon facilitates
the role of [daemon launch facility] or something like that. Singular
concept.

I phrased that question with role as a *singular* concept for specific
reasons. I won't state them again because you've kindly just answered
my question, but I want to focus your attention now towards this last
rationale....

  -> If there is more than one role, they should be *identified* and
*distinctly* separated into individual ones, and if they interact with
themselves or things external, the mechanisms for how they interact
should be specified. Things that perform different roles should be
considered different entities and separate from one another.

  -> If this cannot be done (as in it's not so easy to write it out),
that is a *very strong* indication the design is not understood well
enough for things to move forward with it. This is what I mean when I
say the engineering wisdom of : if you can't put it in writing, then
you don't understand it well enough.


I am afraid the fundamental idea behind systemd has mobilized people
into action without a really concrete idea of just *what* is systemd's
*role* and what are the ways it interacts with things performing other
roles in linux. It looks like systemd takes on a bunch of roles and
that makes it very difficult to really understand what it is.

I think if it's not so easy to detail out the separate roles that are
involved here, it's not so easy to spot complex problems with it down
the road.

If you can trace out all of the different roles involved, and the
follow along all the ways they interconnect, disastrous problems
become (more) detectable.

This is what I am trying to get you to consider. Everyone gets upset
that I don't know what I'm talking about and all I'm trying to do is
see if you can easily put it *into words* what's going on, and it's
the *people are getting pissed* responses that make me think systemd
needs a lot more thought to how it is designed.


I will leave you alone now that you recognize the point of the questions.

I appreciate your patience with me.

I am sorry to get on your last nerves. I pray something good comes
from the uproar I have caused. I hope this has some positive effect.


-Kev

Reply to:

     debian-devel at lists.debian.org
     Kevin Toppins (on-list)
     Kevin Toppins (off-list)

     Prev by Date: Re: debian mate
     Next by Date: Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
     Previous by thread: Re: Systemd
     Next by thread: Fwd: Re: ITP: qmapcontrol -- Qt/Qtopia widget for using map data
     Index(es):
         Date
         Thread