[systemd-devel] feature request: dlopen

[Tobias Hunger]

Hello Luke,

On Mon, Feb 23, 2015 at 12:58 AM, Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>> I understood most of these dependencies to be indirect: Packages that
>> depend on other packages that in turn depend on libsystemd. Is that
>> correct?
>
>  that's right.  so, what that means is that the actual number of
> packages which would need to be converted to dynamic loading is
> actually very small (about 100), and the remaining 4,483 would be fine
> (not need any work done on them at all).

Good. At least all sides agree on the facts:-)

>  they made it possible to remove systemd entirely.  they had to
> recompile cups, stunnel, udisks2, upower, util-linux and many more...
> here's the list:
>
>   http://angband.pl/debian/dists/nosystemd/main/binary-amd64/Packages
>
>  but here's the problem: because there is no dynamic run-time
> decisions possible here, people are forced to adding that (unofficial)
> repo and to risk their systems in the process.  reverting is also just
> as risky.

Libsystemd provides the code that does the runtime detection. The
alternative is to copy and paste the code contained in that library
into those 100 binaries directly, with all the negative consequences.

>> Libsystemd's job is basically to provide exactly what you ask for: A
>> wrapper around systemd functionality, that fails gracefully in case
>> systemd is not used.
>
>  honestly, i find it hard to argue with that.  i think i know what the
> problem is.  the problem is, i believe, that the detection is not
> user-controllable.  question: does libsystemd have a config-file
> option that it reads, where if "systemd = disabled" is present, for
> example, it is effectively equivalent to not having systemd installed?

Libsystemd is fully user control-able: Run systemd as PID1 and
libsystemd does something for you, run anything else as PID1 and it
turns into a noop. Not running systemd as PID1 does state "I do not
want to use systemd" pretty clearly, doesn't it? I see no need to
repeat that statement of intent in some config file.

Again: That seems to be exactly the behavior you are asking for.

>  in many ways it doesn't matter that i (or anyone else) finds the
> solution objectionable.  what should matter - to you - is that i (or
> anyone else) wishes to make that choice [we might have a solution
> above btw as you can see].

I am afraid you lost me.

You want to not use systemd: Fine. You want to not have any code from
the systemd repository on your system? Fine, too. You want to use a
distribution that does not include systemd code? Fine, I can get that,
I am lazy, too.

But where is the relation between "your distribution does not provide
you with packages without any systemd code that you want" and
systemd-the-project?

Distributions do include a lot of packages with dependencies that make
sense for part of the user base only, provided it does not hurt the
other users too much. This is exactly such a case: Users of systemd
get to use socket activation and whatnot, users that do not use
systemd get a library onto their system that eats a bit of disk space
and RAM and does nothing otherwise.

How does this particular decision of your distribution cause you so
much anguish, while you are ok with packages dragging in other
dependencies you do not strictly need? Why is this a matter of choice
here and not elsewhere?

>  .... i think... really, although technically what i am asking
> *appears* to be "achieved in an equivalent fashion", they're not
> entirely the same.
>
>  bear with me whist i think this through, ok?
>
>  my thoughts go like this: virtually every GNU/Linux distro has gone
> for a mutually-exclusive all-or-nothing choice: systemd or out.  even
> Debian has had to provide systemd-shim to quotes stop the whiners
> quotes.  it has "Breaks: systemd < 209" in the package file.  they
> *did not* notice that systemd may be easily disabled by not running as
> PID 1.

So far we talked about libsystemd as a dependency to core packages in Debian.

You are now widening the scope of this discussion. Is that your intention?

You are heading of into systemd-logind land at this point. This is a
very different discussion, as it does effect users and not-users in a
very different way than libsystemd does.

I would be looking forward to having that with you, but we should keep
that in a separate thread and do not mix the topics.

>> I would personally like to see a "libinitd" which brings the socket
>> activation features that is provided to daemons as part of libsystemd
>> to other init systems (that can support those). That would make it so
>> much easier for upstreams to support more than one init system. But I
>> would expect that to be implemented by the teams working on
>> alternatives to systemd or by distributions centered around other init
>> systems.
>
>  i would _love_ to see a situation where there is more dialog and
> collaboration between the developers of systemd and the maintainers of
> the alternatives.

So would I, but I actually think the people that are willing to
discuss to engage in such a discussion are already doing so.

And before a libinit is possible other init systems might need to
provide features like socket activation, etc. first so that there is
something one can unify in one interface.

>  and that i think, guys, is part of the problem.  the development of
> systemd is progressing at such a fast pace, with no dialog with any of
> the peers (developers of openrc, maintainers of sysvinit, depinit -
> currently me - no-one) that there are people - really experienced
> people -really freaking out right now, and they don't fully understand
> why.

Yes, systemd is progressing at a  fast pace. But I personally do feel
well informed. There is a *lot* of discussion going on with all kinds
of people. There is "dialog with any of the peers", right here in this
list. There is more going on in person-to-person meetings, at
conferences and whatnot.

Communication is a two-way street. You can not force people to "listen
to the gospel of systemd", you can only reach out and offer to discuss
with anybody willing to engage in such a discussion.

>  they know that something's wrong, but are having a real hard time
> putting their finger on it.  that's led to some er... charitably we
> can call them debates ... that have resulted in really senior
> dedicated people who have spend in almost all cases over a _decade_ of
> their lives on debian... quitting their role and involvement.  and the
> software libre community as a whole is seriously diminished by the
> loss of their input.

This is yet another matter. Let's please keep that separate from libsystemd.

>> Sure. I am looking forward to that! I am convinced a bit of
>> competition and fresh ideas will do systemd a hell of a lot of good:-)
>
>  the problem is, systemd conversion is so near-exclusive and so rapid
> that there won't *be* any competition.

Oh, there is: Most of it admittedly outside of Linux.

>  the "competition" needs to have a user-base on which to progress and
> be developed.  even a small break in continuity would mean, instantly,
> bit-rot that would make it incredibly hard to reinstate the
> alternatives.

I am convinced that you do can get a user-base for anything that is
not completely crazy:-) And even if it is completely crazy you will
find some fans. Behold the power of the internet:-)

Challengers need to provide value for developers as well as users. So
far all fail on the developers front (at least as far as I can tell):
They must at least provide an idea how to address the points that
systemd and its surrounding infrastructure tackles. Most projects I
looked into are still stuck in a state of denial ("No, systemd does
not address any problems" or "No, that thing systemd tackles is not a
problem").

>  that should have the systemd team very very alarmed.  that nightmare
> scenario where you will *have* no major competition is happening RIGHT
> NOW.

I do not see the situation that dire: There are quite a few systems
outside Linux left that can be used as inspiration.

>  ... and i feel that all of the analyses miss the point, which is,
> primarily, that the rapid [and accidental] exlusionary adoption of
> systemd right across the board is destroying - almost wholesale - the
> alternatives.
>
>  with no userbase, they won't *have* user or developer mindshare by
> which continued work can be justified to consider including them in
> any major distribution.

I am not sure whether that is a bad thing or just something we did not
have before.

Everybody that cares to work on drivers or kernel schedulers does
converge in the linux kernel area. Why is it bad that everybody that
cares about the Linux plumbing layer converges into the systemd space?

Having one master repository for the Linux kernel has not stopped it
from integrating new ideas all the time. As long as the same is true
for systemd I am fine with that.

Yes, this is not what we used to do, but what we used to do was not
perfect either, so I am open to give this approach a try.

>  which leaves anyone who feels that the way that they use and maintain
> their current GNU/Linux distro (be it desktop or server) is better off
> not having systemd *despite* the advantages of systemd, being
> completely and utterly screwed.
>
>  and... betrayed, if i am absolutely honest.

I am sad that you feel this way, but am somewhat unsure what I can do
about this.

>  well, apart from saying "really, you should have listened more
> carefully before rushing ahead" - a statement which doesn't help fix
> the problem *now* but may help others in the future (reading this on
> archives) to avoid a similar situation (one might hope), i feel that
> it really is down to everyone to work out how to make sure that other
> init systems can be included - at runtime - before it really _is_ too
> late.

Do you see any concrete points where the systemd project could have
handled the situation differently?

All they did was to provide some code that the developers of the
project thought to be useful. Other developers agreed with them and
adopted their code. That is how open source projects work. Why is this
one different?

>> My experience is that many people out there are beyond
>> a rational debate at this point.
>
>  they've only become irrational because they felt like they were being
> ignored or betrayed.  and this really is quite a complex subject that
> many perfectly rational people have been... simply unable to
> comprehend [i'm good at analysing cross-project dependencies and
> issues, and even i am having difficulty getting to the bottom of what
> the hell is really going on here].

This is getting way outside my social competence comfort zone:-) I
have to skip at this point.

>> I am afraid we will have to sit this out.
>
>  sitting this one out is only going to make matters worse.  you're on the clock.

It did work when this horrible, complex abomination called sysv-rc was
introduced to replace the nice, simple and easy to understand BSD
style init script we had before:-)

Ah, the good old times. That was a huge controversy, too -- at least
for the much smaller community we were back then.

Best Regards,
Tobias