On 02/17/2015 at 11:28 AM, Luke Kenneth Casson Leighton wrote: > so, marco, you wrote: > >> Again, you clearly do not understand well how systemd works. > > marco: understanding or otherwise how systemd works is not the > point: the point is that there has been a unilateral decision across > virtually every single GNU/Linux distro to abandon and remove *any* > alternative to having libsystemd0 installed. historical precedent > in the software industry and beyond tells us that placing so much > power and trust in a single system and a single group should be > ringing alarm bells so loudly in your head that you should wake up > deaf after having first passed out with dizziness! :) > > so could i ask you, as i really genuinely don't understand, why is > it that the lack of choice here *doesn't* bother you? i'm not asking > for a technical review or a technically-based argument as to "why > libsystemd0 is better" - that has been debated many many times and > is entirely moot. i'm asking "why does *only* having libsystemd0 as > the sole exclusive startup method, removal of which prevents and > prohibits the use of a whopping FIFTEEN PERCENT of the available > debian software base, and where that exclusive exclusionary process > is being rapidly duplicated across virtually every single GNU/Linux > distribution that we know; why does that *not* make you pause for > thought that there might be something desperately and very badly > wrong?" libsystemd0 is not a startup method, or an init system. It's a shared library which permits detection of whether systemd (and the functionality which it provides) is present. There's certainly an undesirable ambiguity about what is meant by any given use of the term "systemd", since it can refer equally to the /lib/systemd/systemd binary, to the PID1 process (which is exactly the same as the previous thing AFAIK, except running as PID1 rather than as a more ordinary system citizen), to more-or-less the entire collection of software which is provided by the systemd project, or to the systemd project itself. But as far as I'm aware, this is the first time I've ever seen anyone refer to the PID1 process or the entire collection of software as 'libsystemd0'. You only harm your case by misusing and confusing terminology in that way. > russ writes: > >> Alas, the resulting distribution is still hopelessly compromised by >> the NSA, who might be even worse than Lennart Poettering. To see >> how deep the tendrils of US government infiltration go, just try >> removing libselinux1, and marvel at how much concerted malevolent >> effort has gone into destroying your freedom. > > and: > >> Or, alternately, you could research how and why one would use >> shared libraries in a binary distribution to support optional >> features. But that's boring, prosaic, and nowhere near as much fun >> to write about. > > ahhh russ - good maaan :) here we have a hint of a possible > solution, one where i'm going to need to speak to the systemd team > for a feature request / design decision (and can i ask you and anyone > else to do the same?). you've hit on what i believe is *the* perfect > and acceptable decision that is hinted at by the ridiculousness of > the drastic demonstration that i made [to modify and recompile debian > packages]. of *course* libsystemd0 should be dynamically loaded, and > the userspace applications make the decision *at runtime* as to what > to do! libsystemd0 _is_ dynamically loaded, precisely so that userspace applications can make the decision at runtime as to what to do. systemd (in either of the first two senses, above) is not, but unless I'm greatly mistaken, making that runtime detection possible is most if not all of the entire reason why libsystemd0 exists. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature