[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)



On 11/16/2014 05:26 AM, Laurent Bigonville wrote:
Le Sat, 15 Nov 2014 20:21:49 -0500,
Marty <martyb@ix.netcom.com> a écrit :

On 11/15/2014 06:49 AM, Andrei POPESCU wrote:
[...]
>
> At least some of people rejecting systemd demand that it be removed
> completely, including libsystemd. How is it pro-choice to forbid me
> from being able to use a software at its full potential?

For me it's more about being unable to remove it completely, because
of vendor lock-in. There's no technical reason that I know of that
anything in userspace cannot modular, and replaceable, so when
something cannot be replaced then an alternative must be provided, or
else my default assumption is that vendor lock-in is in effect.

Well, yes there are technical reasons why you cannot remove a library
package when you have symbols provided by this library used in an
executable. You can still recompile the package and remove some
configure flag if you want to remove this dependency.

OTHO there is no technical reasons that I can see, to completely remove
libsystemd package. You have tenth of other libraries on your system
that, like libsystemd, turn them self into a noop if some some
functionality or daemon are not enable. I'm thinking here for example
about libselinux and libaudit (both also written by Red Had and the
NSA, OMG!!!11), and yet I fail to see any outcry here...

So as long as you cannot _prove_ that having libsystemd installed on
your machine is causing any issues, I'll personally mentally classify
your request as "I don't want to see any packages containing the
"systemd" string on my machine" and redirect these to /dev/null.

Except that proponents seem more prone to avoiding the hairball issue by just covering their eyes. ;)

My point is that in a modular design nothing should be so entrenched as to be irreplaceable. Absence of an alternate should not normally indicate impossibility of an alternate, but some discussions I've read about logind, udev and dbus are enough to raise serious concerns.

People who just say, "write your own, it's all FOSS" are missing the point, I think. Debian is not one guy working in his mom's basement. It's one of the world's largest software projects. When Debian is stumped, because its best developers and upstreams are caught in the entanglement hairball, and see no clear way out, the it's clear case of *Houston we have a problem.*


Reply to: