Am Samstag, 29. November 2014, 01:32:22 schrieb Zbigniew Jędrzejewski-Szmek:
> On Thu, Nov 27, 2014 at 10:02:06PM +0100, Martin Steigerwald wrote:
> > And well, I also wonder why systemd --user functionality is in the *same*
> > binary than the PID 1 stuff… but well… I brought this upstream to no
> > avail.
>
> OK, since this is a different forum, let me go over the reasons once again.
>
> The code paths in systemd which differ between --system and --user are
> relatively small. One part that is the table of paths where to load
> units from (/etc/systemd/system vs. /etc/systemd/user, /run/systemd/system
> vs $XDG_RUNTIME_DIR/systemd/user, etc). Another part says (grossly
> simplyfying) if ("--system" && !test_mode && !virtualized_in_container())
> setup_filesystems();
> But those are just a few (important, but still) parts of the code. The
> majority, like the unit dependency logic, starting of processes,
> notifications from services, opening of sockets, watching of paths,
> etc, etc, are all shared. Actually systemd --user is probably closer
> to systemd --system running in a container than to systemd --system
> running on the host, because both run without full privileges and
> simply skip mounting of various things and other low-level setup.
>
> In this scenario it is natural to structure the code as a single binary
> that conditionalized parts of it logic as necessary.
Thank you for your explaination. I do not agree, as it still seems to be done
this way out of technical convenience. And I think thats not enough of a
reason. And, in addition to that this is PID 1, not the usual application –
and even there… in KDE / Plasma world developers are spending *a lot of
energy* over the last years and still to separate out things which leads to
KDE Frameworks 5, i.e. to specifically do things that aren´t convenient in the
short run.
However, some questions:
So the systemd --user functionality does not add much to the binary size? And
is the detection of the use case systemd binary runs in reliable? What
additional failure cases for the necessary PID 1 functionality does combining
these functionalities create?
> > At least the logind stuff appears to be separate:
> Yes, logind does not share many high-level code paths with the systemd
> binary, so it is natural to keep them separate.
>
> OTOH, systemd and systemd-logind use the same primitives like string
> handling, configuration file parsing (including the logic of drop-in
> directories and /etc-overrides-/run-overrides-/usr/lib), and a bunch
> of other utility functions, which are provided by the shared systemd
> libraries, so it is much easier to develop them in a single repository.
>
> I hope this explains things.
None of like string handling and configuration file parsing seems to be that
special that it needs to be implemented (again?) just for systemd in my
oppinion. The problem of INI file parsing has been solved before, the problem
of string handling as well, a dozen of times maybe.
Well, I hear your explaination and I value your point of view. I acknowledge
it.
Yet, I do not agree.
So maybe at this time, we can just keep it at that. Especially as these are
upstream decisions.
But, in the end here it is about how Debian deals with upstream decisions like
this, and I think here it is where the gross disagreements are.
I personally would feel much more comfortable about systemd, if its upstream
developers made the necessary work for modularization, cross platform
portatibility and so on. Cause not doing so creates *additional* work and
*codepaths* in other software as long as systemd provides functionality that
other software would use like logind as ConsoleKit replacement.
KDE and GNOME if to stay portable need several code paths for using systemd on
Linux and something else elsewhere additional stuff, like the session handling
things. Thus systemd pushes responsibility for platform adaptability upwards
in the stack, and urges other systems to re-implement the same interfaces…
without, actually having seeked any agreement on those with the BSD or Hurd
folks.
And that concerns me. Its a mechanism to offer new functionality with a new
software (systemd), then try to convince others to use it, and then requiring
all other platforms where systemd does not run to play catch up and use the
same interfaces or try to port higher level application which rely on this
functionality themselves. And I think I am perfectly able to proove this kind
of behavior of systemd upstream by providing links.
But enough of this, technical arguments have been made already. Let me try to
move beyond that:
Now, you can acknowledge my concern or not.
But I think in either case it is healthy for me to accept you have or having
explained a different oppinion (is it yours?). And healthy for you to accept
that I have a different oppinion.
I still do not see any solution for the concerns and polarity the way systemd
upstream developers handle things like this triggers. And that is the main
danger here. Actually I see it triggering, read carefully, triggering, not
causing, a split of the Debian community into two parts. And I find this highly
unhealthy for the project. I am really *deeply* concerned about this outcome.
Debian has been through a lot of things I bet, but I never ever saw anything
like this. A discussion as harsh and bitter and long and still not having come
to a solution.
For acknowledgement of the different oppinions I highly applaud the decision to
have mutiple init systems for Jessie at least. The other distribution that
switched as far as I read didn´t even care about that.
Would it be easier or technically convenient to just support just one system?
Likely. Would it be more healthy for the project as a whole: I don´t think so.
So I applaud for that.
And even without a decision on whether packages may depend on a specific init
system *running*, I plead package managers to try to have packages working
with mutiple init systems.
And I find it very important to find a way to agree on disagreeing and value
each others oppinions. That way, healing can happen.
So again, I acknowledge the oppinion you voiced. I can even understand the
reasoning behind it – yeah, from a certain viewpoint it makes sense
technically. Even though I do not agree with it. And it doesn´t address my
concern.
And thats it: The way systemd upstream handles the concerns doesn´t address
the concerns raised. And thats why these concerns are brought up again and
again and again. And that much is obvious. One has to put both hands before
the eyes not to see that. Thats the thing about producing the same outcome
again and again and again I tried to explain earlier. The way how systemd
upstream developers handle things produce the same outcome again and again and
again. The way the concerned ones voice their concern – I try to do it in a
different way, but well… I am a human being too and time will tell whether I
can bring my point across – also produces the same outcome again and again and
again. Which outcome is it?
The outcome is *resistance* on *both* sides. On *both* sides.
I easily triggered resistance of Lennart and other systemd developers by just
trying to *channel* concerns upstream on systemd-devel. So its obvious to me
that systemd upstream developers handle concerns with resistance. And I easily
also felt resistance inside myself against systemd as I experienced this
process, more resistance than before even. I didn´t have a very strong
oppionion about systemd before, but I was concerned with the amount of
polarity it triggers. And after my attempt to address upstream directly I
understand why it does so.
*** Its a social issue much more than a technical one. ***
Any pure discussion on the *technical* level is in *no* way able to *address*
these underlying *social* issue.
Thats the whole point of it.
Thus any discussion on *only* the technical level is a *waste of energy* in my
eyes. Can you agree? I bet you experienced that already.
Yet systemd upstream is not even *willing* to *address* or even just
*acknowledge* this social issue. That is at least my impression. I have been
told to stay purely technical on the systemd upstream mailing list several
times. And for me it felt like this: "Your concern is invalid, go away". And
that is what is happening here. That is why people bring up these concerns
again and again and again.
I see Lennart venting about the harshness in the Linux community in a Google
Plus post, yet he has called me "being a dick" himself as I just tried to
channel these concerns which even haven´t been purely mine. I just summarized
some concerns of the countless threads on debian-user at that time. I may have
used some bold language myself, but I tried very carefully to stay away from
personal discussions. Yet I got this response.
The issue is at least partly *social* and limiting it to the *technical* level
is not going to solve it. It requires maturity to handle it, it requires
maturity to heal it. And that is what is missing right now, IMHO. On *both*
sides.
For any progress I think it is necessary to look beyond this resistance.
Acknowledging the different oppinions and actually *valuing* them all as
*valid* for me is a first important step:
So can you acknowledge my concern *without* telling me that my oppinion is
technically wrong? Can you agree to disagree?
I hope I can. The systemd upstream decisions aren´t "wrong". They are just the
way they are. And I do not agree with some (!) of them.
The way systemd developers handle things is *one* way. The way concerned ones
refer to as the UNIX way to handle things is *another* way. *Different* ways.
And there is disagreement on which way to follow. So how does Debian as a
community handle this *disagreement*? By continuing to fight over each other?
That does not help. The disagreement is there. Its obvious. And no magic spell
on the earth will make it go away in an instant. So its important to see how
to handle it. Debian developers made the decision to discuss this instead of
deciding on a particular way with a GR. So any discussion about how to do this
I think is *highly* on topic on debian-devel.
I just made a few packages. And I still have sysvinit-core as an alternative
installed. I didn´t boot it in a time, but I am confident it would still work.
So as long as neither KDE / Plasma nor something else forces me to run
systemd, I think I will look at how it goes and report bugs – like I did
already. KDE / Plasma developers abstracted away low level stuff before… I
still do not use PulseAudio on my systems cause it creates various issues that
simply go away with not using it (all reported… and mostly ignored in a
similar way as systemd upstream developers sometimes handled bug reports).
But for me it is important to have a choice there. To be able to step back
from systemd at any time I want or view as necessary. And I think keeping that
freedom to choose, even if it causes additional work is a good way to
acknowledge for the different oppinions and allow time for healing to happen.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2834028.3p4HvuWzVm@merkaba
