<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 17, 2015 at 12:24 PM, Luke Kenneth Casson Leighton <<a href="mailto:lkcl@lkcl.net" target="_blank">lkcl@lkcl.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">i don't know if you've seen this yet: <a href="http://news.slashdot.org/story/15/02/15/1959209/removing-libsystemd0-from-a-live-running-debian-system" target="_blank">http://news.slashdot.org/story/15/02/15/1959209/removing-libsystemd0-from-a-live-running-debian-system</a> 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: <a href="http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt" target="_blank">http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt</a> 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: * <a href="https://lists.debian.org/debian-devel/2015/02/msg00189.html" target="_blank">https://lists.debian.org/debian-devel/2015/02/msg00189.html</a> * <a href="http://forums.debian.net/viewtopic.php?f=20&t=119836" target="_blank">http://forums.debian.net/viewtopic.php?f=20&t=119836</a> 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. </blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 <a href="mailto:systemd-devel@lists.freedesktop.org">systemd-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/systemd-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> </blockquote></div> <div> </div>-- <div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"> --- Shawn Landden</div><div dir="ltr">ChurchOfGit.com</div></div></div></div> </div></div>