[mdlug] systemd

[Aaron Kulkis]

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

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]
systemd

     To: Jon Dowland <jmtd at debian.org>
     Cc: debian-devel at lists.debian.org
     Subject: systemd
     From: Kevin Toppins <Kevin.Toppins at gmail.com>
     Date: Wed, 21 Nov 2012 16:26:51 -0600
     Message-id: <CADkoAxgQmO96WgzwDGuwqnuSd-ad9w7beifstsGk9uCFMgGGxA at mail.gmail.com>

> Sadly it is obvious from the rest of this message that you are not up
> to speed on the topic here. If you want to usefully contribute to the
> topic, at a very least you should familiarise yourself with the prior
> threads about systemd to debian-devel. At a very, bare-minimum least.
> It would then of course be polite to other thread participants to make
> sure you are at least up to speed on what systemd is and how it works…
>
> > I think it is categorically important to *identify* and *convey to the
> > community*...
> >
> >  -> What role is systemd designed to facilitate?
>
> >  -> Do we know why we want to prevent a process from forking?
>
> This is something that pretty much goes without saying, if you are
> familiar with the technology which underpins what we're talking about.


First off, I don't have a sysvinit agenda. I know you didn't say that,
but I keep getting the feeling that is what these responses are
concluding, and therefore dismissing what I am saying.

I use gentoo with openrc. So I would like for you to consider my
reasons are something different than -> I am just trying to shoot down
anything that is not sysvinit.

I read through some of the systemd man page and a little of the
original design document. I think I have a rough idea of what systemd
thinks it is. But I am not able to form a sound foundation from the
ideas systemd describes.

It is very dangerous to go ahead with systemd if that first question
cannot be given an answer.

It seems to me that you are confusing my asking as me being ignorant
and stuck to archaic ideas (which I tried to show previously old idea
!= bad idea), when the real reason I am asking is to get you to think
about how this is designed and how it should work. If you can't
formulate them and write them down, we have an underthought design.

In engineering, there is a *very wise* expression when considering how
much thought to give to a design....

  -> If you can't put it in writing, then you don't understand it well enough.

Software engineering is no different.

Read the second listing as to what caused the Air France 447 crash in 2009.

https://en.wikipedia.org/wiki/Air_France_447#Final_report

  -> Inappropriate control inputs. (the sticks the pilot and copilot
each have were not coordinated to act together)

In flying (originally with mechanically linked controls), when the
pilot and copilot are in the cockpit, their control over the airplane
is synchronized. One pilot cannot pull up and the other pilot push
down. This has the purpose of letting one pilot know if the other is
making a mistake. People make mistakes, planes crash, we learned to
have to pilot & copilot with constant connection to each other so that
they could watch for errors.

What went wrong with Air France 447 is the *software* that controlled
the force feedback on the *digital stick* didn't give this any thought
and the pilot's control stick was not coupled together with the
copilot's control stick. Air France 447 crashed because a rookie pilot
pulled the stick the wrong way during a sensor error -> while the
experienced pilot held steady and the airplane's software *stupidly*
averaged the two inputs together. If it had synchronized it like the
mechanical sticks do, Air France 447 would not have crashed.

If they had thought it out....

  -> What design does the synchronized sticks fulfil and why is it like that?

  -> Should we perhaps consider it when coding the digital sticks?

  -> Why do we have 2 sets of sticks and only one is needed to fly the plane?


Not knowing how to *answer the question* of how to make 2 sticks fly
one plane, they just decided : we'll average them together. That makes
sense. Ok, moving on.....

If you can't give me an answer to my questions it might be that
systemd is so overly complicated and takes on so many separate roles
that it might be a disaster to lump them all together. I say might,
because unless you can show me how it won't, then it certainly needs
some more thought to its design, and certainly needs to answer my
questions with something besides *sigh, isn't it obvious you know
nothing...read documentation*

So I would appreciate it if you would consider that linux might be
used in some important technology, like deployment of airbags in cars
one day, and I would like you to be able to see that we might have a
problem with what all systemd is trying to take control over and how
that might require a bit more thought.

People went to the moon on 1960s technology, others designed the unix
model with 1960s technology. What they first had to master was
*understanding what it was they were doing* - they had to *comprehend*
it. They gave it thought. They *designed* it according to what *role*
it was supposed to serve.


There is real wisdom in that. So let's review the purpose of my
previous post in this sobering light one more time.


Has systemd considered that the *filesystem* in linux is the mechanism
in which programs can interact with other programs and other machines
as well...

Perhaps systemd should consider it might be trying to reinvent a
partially formed wheel and not recognize it.....

Certainly, systemd should consider that the filesystem is the
communication medium for a reason, and contemplate why, as opposed to
just asserting that really daemons just use sockets and we can ignore
that when one starts it might have a reason to talk to another and
just suppress that in a queue we provide....because systemd knows best
that really everybody just wants to have a fast startup and that's the
only reason it has staggered launch.... We will just average the
sticks together.

  -> This is the feeling I am getting when reading the original design
of systemd.

  -> Please step back and think this through.

If you think about the architecture of the domain in which all things
operate in linux, the filesystem is really an address book. Linux
keeps order as the programs converse among themselves.

Systemd is presuming to know best what all conversations will be and
is asserting itself in place of the communication mechanism that is
the filesystem.

Systemd is also presuming it knows how the daemons operate better than
the daemons know, and systemd presumes that it can makes these
decisions for them by declaring what they really need is just <x, y,
z>....

That is stated very close to the beginning of the system original
design. http://0pointer.de/blog/projects/systemd.html

I don't presume to know that -> really all the daemons just need to
use sockets and so we can go ahead and start them at the same time.
But systemd *does*.

I might be testing something with ssh and I need sshd isolated from
the internet. No internet connection but I need sshd, please don't
make my choices for me systemd, *I can reason myself as well*.


My previous post: http://lists.debian.org/debian-devel/2012/11/msg00563.html

I got that systemd claims to do damn near everything. What systemd
doesn't understand is being able to do anything is equivalent to no
restrictions on what you can do which leads to anarchy. Read my 2nd
post about udev. If there are no boundaries, what do you expect from
this? Systemd connects *everything* together. This is bad. They call
it progress. Don't listen to their intimidation, comprehend their
reason(s) and check it against the reasons I have in my last post. I
don't think they have better reasons. I ask, but I have *yet* to be
given an actual reason (not just a better one), I am getting no
rationale and that is very likely because none exists.

I am going to say that if we can't soundly answer the questions in my
previous post, we need to *halt* all work on systemd and form up a
*blueprint* so we really understand what systemd is trying to do and
how well that will work given the lessons we have learned from the
past.

Don't let this lead into another Air France 447 because they bullied
you into agreeing that : it's systemd -> therefore you should just use
it.


If I continue to get responses telling me that it's so simple if you
read the documentation, and you really are just ignorant and wasting
all of our time...

Or if someone tries to deflect the questions with pointing me to read
some previous thing (because they *can't* simply *answer* the
question).....

  -> That is a sign for EVERYONE to CUT AND RUN from systemd.

  -> They don't know what they are doing and they are trying to
suppress it, or they are getting angry because they can't express it.

  -> This is not a flame war, this is a wake up call that systemd is a
disaster of an almost idea. Yet systemd is aggressively trying to
conform you into using systemd.

  -> FREE UDEV and save linux from this disaster. Gentoo is forking
udev. Pick up the trail there and help them out. If we free udev, we
can simply ignore systemd and this problem is over. Wake up everybody.
Remember Air France 447.


-Kev

Reply to:

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

     Follow-Ups:
         Re: systemd
             From: Michael Biebl <biebl at debian.org>
         Re: systemd
             From: Josselin Mouette <joss at debian.org>
         Re: systemd
             From: Nikolaus Rath <Nikolaus at rath.org>
         Re: systemd
             From: Kevin Toppins <Kevin.Toppins at gmail.com>

     Prev by Date: Re: release goal for jessie! (Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
     Next by Date: Re: Gentoo guys starting a fork of udev
     Previous by thread: Bug#693919: ITP: r-cran-maldiquant -- GNU R package for quantitative analysis of mass spectrometry data
     Next by thread: Re: systemd
     Index(es):
         Date
         Thread