I respect that you are free to make up your mind, and I do not want
that fundamental freedom to go away. So I ask you, please, just give
this more than a passing thought.
I know that this is debian's list, but please just look at what I am
trying to get you to see.
This is not so much about gentoo and debian, more so about a major
disaster with systemd compromising the designed model that made linux
work in the first place. Really, something that affects us all.
Thu, 22 Nov 2012 00:48:35 +0100 from Josselin Mouette <email@example.com>
> I’m not going to answer to all of your weird or unrelated claims, but
> there’s one extremely relevant to your point of view.
If *any* question is answered, it should be....
-> What role is systemd designed to facilitate?
This is not a trick question. This *unanswered* question is a canary
in a coal mine.
They are not obscure. They are not unrelated.
They are tests of merit that show us that systemd is very flawed if
people keep deflecting the questions.
If we don't have an alternative to systemd, then we are forced to use
systemd and no one can simply *just* *say* what *role* systemd is
supposed to take on? This is catastrophically bad.
Do you understand that the questions are meant to help *you* to
*realize* there is a *major problem* with systemd? They are not meant
to annoy you or argue trivial points. If you think they are annoying
or trivial, I would recommend you read the points I make about the
2009 crash of Air France 447 in my last post.
If systemd is sound in how it is designed, those questions should not
be insanely difficult to answer.
I am hoping to get you to see that people are not answering them
because systemd is not designed around a sound foundation. It
snowballs different and *separate* designs together and it is picking
up speed until finally the only way to make systemd work with linux is
for systemd to completely replace the functionality of most of linux.
They are trying to make it work, yet they are dragging more and more
external things into the mix to work with systemd. Lack of clear and
sound design. Warning to give this some pause and consider things used
to work before systemd. Systemd is constantly reworking how it works
when it constantly realizes that more and more things don't
interoperate quite as smoothly as it seemed. That is what a blueprint
can direct you to check *before* you start building crap randomly.
That is why a blueprint needs to be given for how systemd works before
you go any further with using or developing systemd.
Systemd seems much more an impulsive jump to optimize everything and
to make everything faster and all kinds of mechanisms are getting
shortcutted to achieve that. Look at all the new ways we can do things
differently -> this is building on impulse. Blueprint shows how the
mechanisms interoperate and how they operate with other *external*
mechanisms. They help you spot *problems* before they occur.
Systemd is *internalizing* everything, because whatever idea systemd
is trying to realize doesn't work unless they do. This should indicate
that the designed architecture of why things were separated has been
compromised with one thing doing the jobs of everything. I ask role
because it should only fit one role. Something else should be built to
serve a *different* role. A new kind of role can be invented, I am
open to that possibility. But *any* role should be specified so the
logic of how systemd is supposed to work can be explored and problems
can be fixed in the design phase. It is *foolish* to *ignore* this
point I am making. Please see I am trying to stop you from going
through the door labeled disaster by getting you to recognize the
signs from a distance.
> I think you started heads on with a fundamental misunderstanding.
> The .service file is not systemd having “knowledge” on a given daemon.
> It describes the behavior of the daemon. It is written by the same
> people as the daemon itself.
I never said having knowledge.
I said *presuming* to have knowledge.
-> Wikitionary : Presume : To perform, do (something) without
authority; to lay claim to without permission.
The problem with you thinking it's not systemd presuming to know is that.....
-> The authors have to write the file to specifications established
They _have_ to make it fit within the lines drawn by systemd. That's
pretty presumptuous if you think of all the different ways things can
work and yet you have to conform to this specification.
Do you see a problem for new ideas to grow in this environment? If
systemd ties in with everything, then everything has to change with
any one change and changes become so impossibly difficult, lock in
People, systemd is not an improvement to....anything, because it
cannot be *narrowed down* to what it is trying to *improve*. This
should tell you this is a bad idea right there.
I would appreciate it if you would give this and my other posts some
reflection. I think we have a problem. I am hoping others will begin
to recognize it, or at least consider how systemd rationalizes itself
against the questions I ask here...