:: Re: [DNG] Why Debian 8 Pinning is (…
Inizio della pagina
Delete this message
Reply to this message
Autore: Rick Moen
Data:  
To: dng
Oggetto: Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Rainer Weikusat (rweikusat@???):

> That's neither 'abstract' nor 'teleological' as you yourself nicely
> demonstrated by immediately coming up with an equivalent but different
> term after reinterpreting my statement in a way it clearly wasn't meant
> to be understood by exploiting ambiguities inherent in natural language.


Seems pretty darned teleological and abstract to me. More to the
immediate point, the bigger problem is that it distracts from _process_:
In my experience computing is fundamentally about process -- about what
things _actually do_ -- and arguing over 'purposes' doesn't get the work
done, and smells rather suspiciously of ideological advocacy.

> The purpose of a door handle is to enable people to open doors. That's
> technical and not 'teleological'.


Sometimes, the 'purpose' of a door handle is to be something I hang my
coat from.

However, _clearly_ the purpose of eyeglasses is to support embezzling. ;->

(If you think the latter example is fanciful, consider prosecutors who
decree that convicted computer criminals must be banned from using computers
and the Internet because those are analogous to burglar tools -- in the
jargon are 'instrumentalities of crime'. I have seen this happen in a
number of cases, advised one such overzealous prosecutor, during a
debate about public policy, that moral consistency would require him to
_also_ ask the court to confiscate eyeglasses from convicted embezzlers.
Both are items with a large variety of functions, not just as tools for
committing crimes.)


> > As has been abundantly documented, without systemd itself present,
> > /lib/[$ARCH]/libsystemd.so.0 does basically nothing at all, as it cannot
> > do anything.
>
> Likewise, the base purpose (or function) of a shared library is to
> enable the runtime linker to resolve certain symbols so that a program
> requiring them can be started.


Fine, let's take that as assumed true. IMO, you are getting onto more
solid ground, here, as you are speaking of what things _do_ rather than
their 'purposes'. So, I appreciate that.

> Take sd_notify as an example. That's
>
> ,----
> | int sd_notify(int unset_environment, const char *state);
> |
> | sd_notify() may be called by a service to notify the service manager
> | about state changes.
> `----
> https://www.freedesktop.org/software/systemd/man/sd_notify.html
>
> Calls to sd_notify are not useful to anyone except people using 'service
> managers' implementing the complementary functionality, IOW, to anyone
> not using systemd. libsystemd enables them to be inserted into
> applications without openly compromising support for systems without
> systemd as it provides the required symbols.


So, without systemd, that call is vestigial, i.e., it _does nothing_.
Which confirms what we believed that we knew before.

> Regarding systemd as a documented API, libsystemd is nothing but an
> alternate implementation of it and an alternate implementation created
> and maintained by the exact same people.


Your phrase 'an alternative implementation of it' appears murky to this
easily confused system administrator. I'm not entirely clear on what
the 'it' in this context is -- perhaps 'API'? If so, concepts like
'API' strike me as needlessly abstract and unclear in this context, thus
risking a shortage of clarity -- doubtless me being annoyingly literal
and overfond of the concrete and specific.

To the best of my imperfect understanding, you have once again, as in
many other semi-dissections of this library I vaguely recall from
pro/anti-system disputations around 3-4 years ago, traced out glue code
in libsystemd0 that without systemd does nothing at all. Which is the
inevitable end-result of such discussion in my experience after one
casts aside rhetorical maneouvering.

Personally, I'm aiming to get the lib off my systems as somewhere in my
long priority list -- but I don't see it as being substantially worse in
the meantime than the Kerberos5 libraries also hauled in by overbroad
package dependencies but likewise doing nothing at all. Frankly, I
consider udev more significant by a country mile -- or, make that a
country kilometre, since we're now living in the 21st Century.

-- 
Cheers,                                      Luftputebåten min er full av ål.
Rick Moen
rick@???
McQ!  (4x80)