[systemd-devel] feature request: dlopen

[Luke Kenneth Casson Leighton]

On Mon, Feb 23, 2015 at 6:17 AM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> Luke Kenneth Casson Leighton [2015-02-23  2:08 +0000]:
>>  the problem, zbigniew, is that the intended use of this "silent noop"
>> feature - to make it *possible* to have an alternative PID1 - *hasn't
>> happened*.
>
> It sure has. Debian supports systemd, SysV init, and to a lesser
> degree OpenRC and upstart.

 see below, last paragraph.

>> any upstream software developer who has added in support for systemd
>> has done so by *ripping out* the former alternative code.  not a
>> single upstream system that i've seen has done *any* kind of
>> run-time detection *at all*.  it's all compile-time.
>
> libsystemd does that very run-time detection, and upstream software
> usually falls back to the "normal" way of opening sockets if socket
> activation via libsystemd fails (either because you aren't running
> systemd or the service isn't socket activated).

 see below, last paragraph.

>> aside from getting the message across to upstream developers about
>> doing runtime detection, i feel that what you guys really need to do
>> is to set up conferences with everyone, to talk - urgently - about
>> ways to ensure that the alternative systems which the wholesale
>> adoption of systemd has excluded may be reinstated as *runtime*
>> choices (not compile-time).
>
> You didn't follow, or see the results of the big Debian systemd debate
> at all, did you? :-)

 the one where people were violently rude to each other?  of course not.

> Pretty please do some actual research about the situtation first, and
> keep apart libsystemd (harmless, works with any init system) from
> systemd (the init system, pid 1, services around it, etc).

 martin, this is very condescending.  please don't do that again.  it
also misses the larger picture.

what the distros do is fait-accomplit driven by the decisions of the
upstream developers.   what the upstream developers do is
fait-accomplit driven by the decisions of their dependencies.
everyone has been working in near-isolation (which is normally fine
and absolutely nothing wrong with that), except that in this one very
specific unique instance it's resulted - *entirely by accident* the
abandonment of the alternatives to systemd.  if what you said was
genuinely true - that there is choice *within* the distros,
http://angband.pl/debian/, TriOS, and devuan would not exist.

l.