[systemd-devel] feature request: dlopen

[Shawn Landden]

On Tue, Feb 17, 2015 at 12:24 PM, Luke Kenneth Casson Leighton <
lkcl at lkcl.net> wrote:

> i don't know if you've seen this yet:
>
> http://news.slashdot.org/story/15/02/15/1959209/removing-libsystemd0-from-a-live-running-debian-system
>
> my name's luke leighton, i'm a software libre advocate, and the first
> major contribution that i made to software libre was to help bridge
> the impossible chasm between the microsoft world and the unix world,
> back in 1996 to 1999, by implementing and documenting NT Domains as
> well as a proper Network Neighbourhood (features of which,
> interestingly, have since been completely reimplemented in the form of
> avahi and zeroconf).
>
> i now tend to keep to myself except in circumstances where i perceive
> something similar occurring in the software libre community: a
> polarisation or an opportunity to extend (or reduce) the reach of
> software libre.  a decision that has been made which makes the lives
> of huge numbers of ordinary users and systems administrators
> incredibly difficult, forcing them to make impossible decisions - that
> sort of thing.
>
>  i note that there was announcement recently that the systemd team
> 'listens to users', so i am taking you at your word on that.
>
> now, i'm keenly aware of the views (technical and more) of systemd:
> i'm aware that there have been polls.  most of them remind me of
> mother theresa's refusal to go to a "war protest" rally - she pointed
> out that next time they had a *peace* rally, to give her a call.
>
> so i'm not going to "protest" - i'm going to try a different approach.
> i'd like you to look at this list of debian packages that are
> dependent on libsystemd0:
>
> http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt
>
> it's an enormous list, comprising some 15% of the packages present in
> debian today.  it includes apache2-dev, bluetooth / bluez, the gimp,
> php, *all* of the video players (xine, mplayer, vlc), *all* of the
> games and 3D packages that use SDL or pulseaudio (which is most of
> them), *all* of the major desktop environments including xfce4, lxde,
> Gnome and KDE/Plasma, cups-daemon, one of the anti-virus daemons, most
> of the music software packages and services, most of the VoIP clients,
> the android SDK, the eclipse IDE, OpenJDK 7, erlang, Apache
> Tomcat..... i'm just absolutely blown away by the extent of the
> dependencies.
>
> oh - and php as well.  what the heck php5 is doing with a hard
> dependency on libsystemd0 i cannot imagine.
>
> now, because those are hard compile-time dependencies, the only
> possibility for the average debian user who chooses *not* to have
> libsystemd0 present on their system is for them to simply... not use
> *anything* on that list of over four and a half THOUSAND packages.
>
> i think the most important question to ask you at this point is: as a
> team, were you aware of the extent to which libsystemd0 has become a
> hard compile-time dependency on so many critical software packages in
> use today?
>
> and the second question, which is just as important, is: does this
> shock or alarm you enough to appreciate why people find the rapid
> introduction of libsystemd0 to be so objectionable?  before answering,
> please bear in mind that i have done an analysis of a similar library
> and runtime (which i worked with a decade ago and am a minor
> contributor on): libselinux1 and SE/LInux.
>
> i can tell you right now that the way in which SE/Linux was introduced
> is *genuinely* completely different from the one that has brought us
> libsystemd0 (and has nothing to do with the technical debate, merits
> or otherwise of the software *or* its alternatives).
>
>  in fact, the way in which libselinux1 was introduced - the careful
> research, the definition of its scope, how its instigators stuck to a
> clear roadmap, and its gradual introduction as an *optional* component
> that could be tested, deployed and rolled back *without* inconvenience
> or attempting to reverse impossiblly challenging or irreversible
> decisions if found to be troublesome, could be said (with
> understatement) to be a humbling model that libsystemd0 should learn
> from, retrospectively, very very fast.
>
> now, since beginning to write this a couple of days ago, i have
> encountered this:
> * https://lists.debian.org/debian-devel/2015/02/msg00189.html
> * http://forums.debian.net/viewtopic.php?f=20&t=119836
>
> there, we see that a debian developer has created unofficial packages
> that, if installed, provide replacements for key strategic packages
> entirely recompiled *without* systemd and without libsystemd0 being
> present.
>
> the key here is that they *are* entirely unofficial, making the
> decision to install them a difficult one, and flat-out impossible for
> many deployments where there are rules and contracts in place that
> prevent and prohibit the use even of debian-backports, let alone
> unofficial repositories.
>
> also, adam's work is only going to get harder and harder as time goes
> by, as the depth and extent of systemd's reach increases.  so, whilst
> it's a good thing that adam has achieved what he has, it can
> definitely be said to be a "stop-gap measure" - allowing a *small
> subset* of users and administrators some interim relief whilst this is
> properly resolved.
>
> moving on: in what adam wrote (rather hot-headedly, initially), he
> goes on to mention that it would be perfectly reasonable to replicate
> the effects of how he removed libsystemd0, in a way that would be far
> less disruptive to end-users and sysadmins, and far less divisive:
> dynamic library loading.
>
The vast majority of packages that are currently using libsystemd are using
it for interacting with systemd socket activation. The code for this is
very short, and initially it was only supported for packages to just copy
sd-daemon.c and sd-daemon.h into their projects (this is still supported
and how I added systemd socket activation support to criu for example).
sd-bus is part of libsystemd and thus alot more packages are going to start
using it, but the vast majority of packages currently using libsystemd
could have that dependancy patched out.

>
> the technique's nothing new: it's extremely common and as experienced
> software libre developers i'm sure you've even written code in the
> past or maintain some now that uses dlopen to great effect.
>
> as i am partly writing to a public audience who may not be so
> knowledgeable, please excuse me for describing that the advantages,
> are, as you know, that a pre-compiled package may, at runtime, detect
> what is available to it and use it. it may even be configured via a
> config option to disable the use of that functionality at runtime even
> if the dynamic library is present.  you know this.
>
> so can i leave it with you to consider whether the current situation
> is tolerable or not?  that situation is unfortunately one of closing
> your doors to the voices that are telling you (mostly incoherently, so
> its hardly surprising that you choose to ignore them!) that there
> really *is* a problem here that is *not* going to go away, no matter
> how much you might wish it to, and no matter how much you may be
> *saying* that you listen to users.  in other words: whilst the voices
> may be incoherent or even abusive, it's only when they stop will you
> know that you did something right :)
>
> i am one of the few people who can cut through all that, who has gone
> to the trouble of digging into why libsystemd0 is found to be so
> objectionable.  my take on the matter is that the technical arguments
> - benefits or otherwise - of systemd and its alternatives - is
> completely irrelevant.  over time people *will* develop alternatives
> (and are already doing so: mdev, eudev, uselessd, openrc and many
> more).
>
> no, i feel that it really does have nothing to do with the technical
> benefits of the available options: what people are finding completely
> objectionable is that they have *no good choices*.  it's "use systemd
> or go away" - and unfortunately almost without exception (slackware
> and FreeBSD being two notable ones) that "piss off" attitude is being
> replicated across *the entire GNU/Linux Distro world*.  the situation
> is completely unprecedented and without parallel in the short history
> of software libre (and that's something that, honestly, i find to be
> really shocking, hence why i am contacting you).
>
> overall, they feel that they're being forced into the use of something
> that they feel has not been properly thought through, is still under
> development, is increasing in scope in a way that alarms them due to
> there being no other choices, causes them some huge inconvenience that
> they'd rather have a bit more time to consider but they are *not being
> given that chance*, and much more.
>
> this is a rapidly untenable escalating situation that is having an
> adverse detrimental effect that i feel is *your* responsibility to
> defuse.... and quickly.  and you may do so through the simple process
> of converting a couple of userspace applications within your control
> over to use the well-known dynamic-library-loading technique.
>
> i have to tell you: i even heard, on slashdot, that microsoft is now
> using - to significant success - the situation surrounding systemd as
> a sales pitch to have GNU/linux systems successfully replaced with
> windows servers.  that GNU/linux is being relegated to the hypervisor
> / management role of windows systems which are successfully claimed to
> be much more dependable.  systemd is being used to successfully
> *scare* people into buying windows - back into the arms of the
> monopoly power i worked incredibly hard to give people a way to move
> away from.  i have to say: I'm Officially Not Happy With You (tm) for
> that :)
>
> i hope... my hope is that, by providing you with these insights and a
> potential and easily-deployed solution (in going through all the
> packages and hard-removing libsystemd0, adam was in a unique position
> to evaluate the dlopen option and found it to be technically easy to
> do), i hope that i have shocked you into taking immediate action.  my
> hope here is that you will realise the gravity and enormity of the
> situation that the software libre world faces right now, sufficient
> that you will give this absolute top priority above everything else
> that cannot be immediately put on hold.
>
> i am subscribed to this list on "nomail", and will follow it on gmane.
> as you are experienced software developers i would not presume to
> interfere with how to go about dynamically-loading of libsystemd0,
> however if you would appreciate the benefit of my experience (which
> comes in part from one of the software libre world's more experienced
> unix portability experts, andrew tridgell), i will be more than happy
> to help as i can.
>
> l.
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>



-- 

---
Shawn Landden
ChurchOfGit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150222/9739627d/attachment.html>