Re: [DNG] with or without libsystemd0

[Rick Moen]

Quoting fsmithred (fsmith...@gmail.com):

> Oh, you must have missed my last report. Surely, you would agree that
> executing an executable file is doing something.

No, I didn't miss that.  libsystemd0 didn't do anything, by your own
account.  By said account, some piece of GNOME infrastructure took some
action ('removable drives no longer appear on the desktop').

I'm not surprised.  GNOME is brittle, and a dependency hairball (as is
XFCE, because of core components in common with GNOME).  My opinion,
yours under royalty-free licensing if you want it.  ;->


You refer to '/lib/systemd/systemd-udevd' as 'an executable binary file
that libsystemd0 provides'.  This appears to be the cause of the
confusion.  That is _not_ a part of package libsystemd0.
https://packages.debian.org/stable/amd64/libsystemd0/filelist provides the list
(for the x86_64 package in current Debian-stable, as an example),
comprising one dynamic library, one symlink to that library, and two
small documentation files:

/lib/x86_64-linux-gnu/libsystemd.so.0
/lib/x86_64-linux-gnu/libsystemd.so.0.3.1
/usr/share/doc/libsystemd0/changelog.Debian.gz
/usr/share/doc/libsystemd0/copyright

Normally, when I say 'libsystemd0', I assume people mean
lib/x86_64-linux-gnu/libsystemd.so.0 (the symlink) or the binary it
points to, currently /lib/x86_64-linux-gnu/libsystemd.so.0.3.1 .  But
even taking the most expansive possible interpretation of what you meant
when you said 'an executable binary file that libsystemd0 provides',
that does _not_ include systemd-udevd, which is simply not in that
package at all.

As you will see in
https://packages.debian.org/stable/amd64/udev/filelist, that executable
is in package udev, not package libsystemd0.



> For the past two years, people have been saying that libsystemd0 is just a
> library

It's just a library.  But check the list of files for yourself.  Certainly
don't take my word for it.


> To summarize: libsystemd0 runs its program(s) even when systemd is not
> installed.

To summarise:  You made a mistake.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[Arnt Karlsen]

On Wed, 20 Jul 2016 18:39:57 -0400, fsmithred wrote in message 
<578ffdbd.4020...@gmail.com>:

> So the original question I had, as to whether libsystemd0 does
> anything when systemd is not installed, is still unanswered.


..think of it like you think of a football coming bouncing out 
across the road from between those parked cars you're about to 
pass... is there a playful kid or 3 chasing it... if you're not 
on the brakes hard, you probably shouldn't be driving at all.

..but then again there's stupid luck, there might be zero kids 
chasing that football and you might be mocked for for being too
damned paranoid by those who believe libsystemd0 etc will never 
do us harm, and believe the pötterings are merely working for 
Ed Snowdon as a plan B in case the NSA figures out Tor... 


..we don't know, so we must act upon imperfect beliefs, and back 
those up on our own spine and gut feelings and whatever bits we 
do learn.

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[fsmithred]

I'm top-posting on a bottom-post thread, and I'm replying to myself to
retract what I said below. The executable I found,
/lib/systemd/systemd-udevd, did not come with the libsystemd0 package. It
was already there.

If someone knows how to tell if a library was used by a program, I would
like to learn how that is done. Thanks.

-fsr


On 07/20/2016 06:18 AM, fsmithred wrote:
> On 07/19/2016 06:10 PM, Rick Moen wrote:
>> Saying libsystemd0 'does something' merely because higher-layer GNOME
>> code probed it for a function and then decided to do or not do something
>> based on what it found (my high-confidence surmise about your gvfs
>> anecdote) entails very peculiar construing of the verb 'to do' -- and
>> I'm pretty sure hardly anyone else uses the verb quite that way.
> 
> 
> Oh, you must have missed my last report. Surely, you would agree that
> executing an executable file is doing something.
> 
> For the past two years, people have been saying that libsystemd0 is just a
> library, and it does nothing if systemd is not installed or not running.
> I've been skeptical of such claims, but until yesterday, I wasn't sure.
> Neither one of those claims is accurate. Among the files that the
> libsystemd0 package provides, at least two of them are executable files.
> There may be more that aren't located in /lib/systemd/.
> 
> Here it is again.
> 
>> One more test - instead of 'chmod -R 000 /lib/systemd' I tried 'chmod -x
>> /lib/systemd/systemd-udevd' thus disabling an executable binary file that
>> libsystemd0 provides. Dropped to runlevel 1, ctrl-d to return to desktop,
>> and removable drives no longer appear on the desktop. 
> 
> I suppose it's possible that gvfs just checks for the executable bit on
> /lib/systemd/systemd-udevd and doesn't actually run that program, but I
> doubt that.
> 
> To summarize: libsystemd0 runs its program(s) even when systemd is not
> installed.
> 
> -fsr
> 

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[fsmithred]

On 07/20/2016 06:44 AM, Jaromil wrote:
> On Wed, 20 Jul 2016, fsmithred wrote:
> 
>> On 07/19/2016 06:10 PM, Rick Moen wrote:
>>> Saying libsystemd0 'does something' merely because higher-layer GNOME
>>> code probed it for a function and then decided to do or not do something
>>> based on what it found (my high-confidence surmise about your gvfs
>>> anecdote) entails very peculiar construing of the verb 'to do' -- and
>>> I'm pretty sure hardly anyone else uses the verb quite that way.
>>
>>
>> Oh, you must have missed my last report. Surely, you would agree that
>> executing an executable file is doing something.
> 
> technically speaking, one doesn't even need to "run an executable" to
> execute code. Either by shared-lib linking or by dynamic loading
> (dlopen), a program linking a library can execute code provided by the
> library in its own stack. Such code will run with the exact same
> access than the calling code (access to file descriptors, processes
> etc.).
> 
>>
>> For the past two years, people have been saying that libsystemd0 is just a
>> library, and it does nothing if systemd is not installed or not running.
>> I've been skeptical of such claims, but until yesterday, I wasn't sure.
>> Neither one of those claims is accurate. Among the files that the
>> libsystemd0 package provides, at least two of them are executable files.
>> There may be more that aren't located in /lib/systemd/.
> 
> [...]
> 
>> To summarize: libsystemd0 runs its program(s) even when systemd is not
>> installed.
> 
> This may be incorrect, as I don't see any execve() in libsystemd.
> 
> What we can say is that libsystemd0 runs its code, called by other
> programs, even when systemd is not installed.
> 
> ciao!
> 
> ___

Well, I was all set to argue with you, and I checked again. I must admit
that I made a mistake. The executable file I found,
/lib/systemd/systemd-udevd, did not come with the libsystemd0 package. It
was already there.

I apologize for starting a small shitstorm over my mistake.

Yeah, I understand that a library can be called by more than one program,
but how can we know if a library has been called? Keep track of the last
access time on the file? Some other way?

So the original question I had, as to whether libsystemd0 does anything
when systemd is not installed, is still unanswered.

-fsr


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[Didier Kryn]

Le 20/07/2016 13:57, Rowland Penny a écrit :
libsystemd0 is a .so file and (as far as I am aware) is just a library 
of subroutines. If you tried to directly run libsystemd0, it probably 
wouldn't do anything, but if another program was to use one of the 
'subroutines' , it would do whatever the 'subroutine' was designed to do. 


The concern is what the library call actually performs.

Does it perform it directly in the function or does this function 
invoke an application to do it? I think this is secondary.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[Arnt Gulbrandsen]

Didier Kryn writes:

Le 20/07/2016 12:51, Rowland Penny a écrit :

libsystemd0 doesn't run anything, it just provides code.


Funny! What does this code "do". Is it just returning  
dummy values without doing anythig more? I have doubts.


You misunderstand. The code doesn't contain dlopen(), execve() or other 
ways to run plugins, daemons, helpers, etc. If you link with it, WYSIWYG. 
It's quite unlike systemd, which loads so many plugins, daemons and helpers 
that you have no real way to S what that you G.


I'd rather not have libsystemd0. Every unneeded file is one extra thing to 
check when there's a bug, etc. I'm just saying that libsystemd0 is not 
horrendous in the way systemd is.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[Rowland Penny]

On 20/07/16 12:51, Didier Kryn wrote:

Le 20/07/2016 12:51, Rowland Penny a écrit :

libsystemd0 doesn't run anything, it just provides code.


Funny! What does this code "do". Is it just returning  dummy 
values without doing anythig more? I have doubts.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


libsystemd0 is a .so file and (as far as I am aware) is just a library 
of subroutines. If you tried to directly run libsystemd0, it probably 
wouldn't do anything, but if another program was to use one of the 
'subroutines' , it would do whatever the 'subroutine' was designed to do.


Of course, the above could be a load of rubbish, but it my understanding 
of what a .so file is for.


Rowland

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[Didier Kryn]

Le 20/07/2016 12:51, Rowland Penny a écrit :

libsystemd0 doesn't run anything, it just provides code.


Funny! What does this code "do". Is it just returning  dummy values 
without doing anythig more? I have doubts.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[Rowland Penny]

On 20/07/16 11:44, Jaromil wrote:

On Wed, 20 Jul 2016, fsmithred wrote:


On 07/19/2016 06:10 PM, Rick Moen wrote:

Saying libsystemd0 'does something' merely because higher-layer GNOME
code probed it for a function and then decided to do or not do something
based on what it found (my high-confidence surmise about your gvfs
anecdote) entails very peculiar construing of the verb 'to do' -- and
I'm pretty sure hardly anyone else uses the verb quite that way.


Oh, you must have missed my last report. Surely, you would agree that
executing an executable file is doing something.

technically speaking, one doesn't even need to "run an executable" to
execute code. Either by shared-lib linking or by dynamic loading
(dlopen), a program linking a library can execute code provided by the
library in its own stack. Such code will run with the exact same
access than the calling code (access to file descriptors, processes
etc.).


For the past two years, people have been saying that libsystemd0 is just a
library, and it does nothing if systemd is not installed or not running.
I've been skeptical of such claims, but until yesterday, I wasn't sure.
Neither one of those claims is accurate. Among the files that the
libsystemd0 package provides, at least two of them are executable files.
There may be more that aren't located in /lib/systemd/.

[...]


To summarize: libsystemd0 runs its program(s) even when systemd is not
installed.

This may be incorrect, as I don't see any execve() in libsystemd.

What we can say is that libsystemd0 runs its code, called by other
programs, even when systemd is not installed.




No, I don't think that is correct, I think you could say that other 
programs can use code in libsystemd0, even if systemd isn't installed.

libsystemd0 doesn't run anything, it just provides code.

Rowland
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[Jaromil]

On Wed, 20 Jul 2016, fsmithred wrote:

> On 07/19/2016 06:10 PM, Rick Moen wrote:
> > Saying libsystemd0 'does something' merely because higher-layer GNOME
> > code probed it for a function and then decided to do or not do something
> > based on what it found (my high-confidence surmise about your gvfs
> > anecdote) entails very peculiar construing of the verb 'to do' -- and
> > I'm pretty sure hardly anyone else uses the verb quite that way.
> 
> 
> Oh, you must have missed my last report. Surely, you would agree that
> executing an executable file is doing something.

technically speaking, one doesn't even need to "run an executable" to
execute code. Either by shared-lib linking or by dynamic loading
(dlopen), a program linking a library can execute code provided by the
library in its own stack. Such code will run with the exact same
access than the calling code (access to file descriptors, processes
etc.).

> 
> For the past two years, people have been saying that libsystemd0 is just a
> library, and it does nothing if systemd is not installed or not running.
> I've been skeptical of such claims, but until yesterday, I wasn't sure.
> Neither one of those claims is accurate. Among the files that the
> libsystemd0 package provides, at least two of them are executable files.
> There may be more that aren't located in /lib/systemd/.

[...]

> To summarize: libsystemd0 runs its program(s) even when systemd is not
> installed.

This may be incorrect, as I don't see any execve() in libsystemd.

What we can say is that libsystemd0 runs its code, called by other
programs, even when systemd is not installed.

ciao!

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[fsmithred]

On 07/19/2016 06:10 PM, Rick Moen wrote:
> Saying libsystemd0 'does something' merely because higher-layer GNOME
> code probed it for a function and then decided to do or not do something
> based on what it found (my high-confidence surmise about your gvfs
> anecdote) entails very peculiar construing of the verb 'to do' -- and
> I'm pretty sure hardly anyone else uses the verb quite that way.


Oh, you must have missed my last report. Surely, you would agree that
executing an executable file is doing something.

For the past two years, people have been saying that libsystemd0 is just a
library, and it does nothing if systemd is not installed or not running.
I've been skeptical of such claims, but until yesterday, I wasn't sure.
Neither one of those claims is accurate. Among the files that the
libsystemd0 package provides, at least two of them are executable files.
There may be more that aren't located in /lib/systemd/.

Here it is again.

> One more test - instead of 'chmod -R 000 /lib/systemd' I tried 'chmod -x
> /lib/systemd/systemd-udevd' thus disabling an executable binary file that
> libsystemd0 provides. Dropped to runlevel 1, ctrl-d to return to desktop,
> and removable drives no longer appear on the desktop. 

I suppose it's possible that gvfs just checks for the executable bit on
/lib/systemd/systemd-udevd and doesn't actually run that program, but I
doubt that.

To summarize: libsystemd0 runs its program(s) even when systemd is not
installed.

-fsr

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[Rick Moen]

Quoting fsmithred (fsmith...@gmail.com):

> Yeah, I know there's a lot of gnome in xfce, and gnome virtual file
> system does sound familiar. Happily, I've been getting along fine
> without gvfs since upgrading to devuan jessie about six months ago.
> I'm ok with xfce like this, and I'm ok with a plain window manager.
> I've used several in the past.
> 
> In fact, the experiment was a success. I wanted to test the often
> repeated assertion that libsystemd0 doesn't do anything if systemd is
> not installed. Now I know that it's not true. You provided information
> that helped me do that. Thank you for posting it.

You're entirely welcome.

Saying libsystemd0 'does something' merely because higher-layer GNOME
code probed it for a function and then decided to do or not do something
based on what it found (my high-confidence surmise about your gvfs
anecdote) entails very peculiar construing of the verb 'to do' -- and
I'm pretty sure hardly anyone else uses the verb quite that way.

That would be like saying I 'did something' while asleep because someone
recorded my snoring and then used a clip of it as rhythm line for a pop
song.  (Polyrhythmic, no doubt.)

Again, my reaction to such things (such as you mentioned, not to my
snoring) would be (and is) to kick GNOME and anything sharing its core
-- such as MATE, Cinnamon, Unity, or XFCE -- to the curb (or kerb, on
the civilised side of the Atlantic[1]), but suit yourself, of course.

[1] http://grammarist.com/spelling/curb-kerb/

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[fsmithred]

On 07/19/2016 01:51 PM, Rick Moen wrote:
> Quoting fsmithred (fsmith...@gmail.com):
> 
>> Rick, I don't understand your reasoning here. What I see is that gvfs
>> can do something when the real libsystemd0 is installed that it can't
>> do without libsystemd0 - that is, it shows removable drives on the
>> desktop.  The presence of systemd itself is not required for this -
>> it's not installed.
>>
>> Gnome probably has nothing at all to do with this. The only gnome
>> packages installed here are gnome-accessibility-themes, gnome-icons,
>> libgnome-keyring and libsoup-gnome. I'm running xfce desktop.
> 
> You know why, some years back, I stepped carefully away from XFCE4?
> Because it uses (shares) a very great deal of GNOME's core software
> infrastructure.
> 
> You know what 'gvfs' is short for?  GNOME virtual file system.  Now you
> know.  (Sorry to be the bearer of bad news.)
> 
> I'm sorry that the GNOME brittle software used in your DE breaks a bit
> when you kick away a piece of what it checks for, but that's
> unfortunately exactly what I have come to expect it to do, even when the
> label on the tin says 'XFCE'.
> 
> I wish you luck with your experiment, but I'd honestly recommend trying
> something else, instead.  LXQt seems promising for people who like DEs,
> or Enlightenment.  (Personally, I'm just not a DE person.)
> 
> Above is of course entirely my opinion.  You'll do what you wish, and
> 'Good on ya!' as the Aussies say.
> 

Yeah, I know there's a lot of gnome in xfce, and gnome virtual file system
does sound familiar. Happily, I've been getting along fine without gvfs
since upgrading to devuan jessie about six months ago. I'm ok with xfce
like this, and I'm ok with a plain window manager. I've used several in
the past.

In fact, the experiment was a success. I wanted to test the often repeated
assertion that libsystemd0 doesn't do anything if systemd is not
installed. Now I know that it's not true. You provided information that
helped me do that. Thank you for posting it.

-fsr


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[Rick Moen]

Quoting fsmithred (fsmith...@gmail.com):

> Rick, I don't understand your reasoning here. What I see is that gvfs
> can do something when the real libsystemd0 is installed that it can't
> do without libsystemd0 - that is, it shows removable drives on the
> desktop.  The presence of systemd itself is not required for this -
> it's not installed.
> 
> Gnome probably has nothing at all to do with this. The only gnome
> packages installed here are gnome-accessibility-themes, gnome-icons,
> libgnome-keyring and libsoup-gnome. I'm running xfce desktop.

You know why, some years back, I stepped carefully away from XFCE4?
Because it uses (shares) a very great deal of GNOME's core software
infrastructure.

You know what 'gvfs' is short for?  GNOME virtual file system.  Now you
know.  (Sorry to be the bearer of bad news.)

I'm sorry that the GNOME brittle software used in your DE breaks a bit
when you kick away a piece of what it checks for, but that's
unfortunately exactly what I have come to expect it to do, even when the
label on the tin says 'XFCE'.

I wish you luck with your experiment, but I'd honestly recommend trying
something else, instead.  LXQt seems promising for people who like DEs,
or Enlightenment.  (Personally, I'm just not a DE person.)

Above is of course entirely my opinion.  You'll do what you wish, and
'Good on ya!' as the Aussies say.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[Rick Moen]

Quoting Simon Hobson (li...@thehobsons.co.uk):
> Rick Moen  wrote:
> 
> > Remember that bit I posted about how /usr/bin/ssh makes dynamic library
> > calls to sonames of two Kerberos libraries, even on the overwhelming
> > majority of systems that do not implement Kerberos?
> ...
> > 'Trust' in the sense you use the word just isn't in that.
> 
> But it is.
> Have you actually checked any (or all) of the libraries to be sure ? 

This is a bit silly, so-broad-as-to-be-meaningless application of the word
'trust'.  I don't, in the general case, personally inspect any of the
binaries or libraries on my systems, nor in the general case do I
compile those myself, nor do I perform local diverse double-compiling to
prevent application of Ken Thompson's 1984 'Reflections on Trusting
Trust' moby hack, either.

https://www.schneier.com/blog/archives/2006/01/countering_trus.html
https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

Now, are we done with the ritual paranoia dance?

> The point is, which you seem to keep missing, is that I do not have 
> this level of trust in anyone pushing systemd.

No, I 'get' your oft-repeated personal opinion.  I'm just not impressed
with the allegedly sinister, alleged threat of distro-maintained
interface glue package libsystemd0.  Nor am I impressed with the alleged
problem of any 'amount of noise surrounding' that topic or any other.

Because I have a few clues about software and open source, and have
reasonable confidence I follow what's going on, on an ongoing basis.

> Plus, as someone else pointed out, to permit libsystemd0 (or equivs
> *IFF* it doesn't break packages - which it does with ClamAV) is
> tacitly accepting that these packages are OK to blindly depend on it. 

You seem to be using some strange, emotionally tinged sense of the words
'accept' and 'OK'.

Am I tacitly 'accepting' that Kerberos libraries are 'OK' on my
Kerberos-less systems because I am 'accepting' the dynamic library links
in /usr/bin/ssh?  I don't even really know what that means.  

I tolerate the fact that the dynamic library call to two
locally-pointless Kerberos libraries exist, in the sense that I've not
rushed out and recompiled/rebuilt package openssh-client to eliminate
the vestigial and basically meaningless library dependency.  Which in
turn because I'm a bit busy and have other, better things to worry about.

If I _really_ needed a new hobby, I suppose I could run Gentoo/Funtoo
and spend my idle hours on USE flags and running compiles to eliminate
every vestigial library call -- but I don't.

> If the packagers can package that dependency and not get pushback from
> the users, then there's no incentive to consider if it might not be
> "right".

And why the Gehenna would they do that?  Do they have some blood feud
with your clan?  To my knowledge, they don't with mine.  I lead a rather
more blessedly boring life, and have time for things like gardening, and
occasionally administering Linux systems.

I don't even have it in for the Kerberos people, and to my knowledge
they have only benign (if complex and poorly documented) plans for my
greater metropolitan region -- though I keep a wary eye to the south
where dread Stanford University lies, a hotbed of Kerberos radicalism.
They even do AFS there!  (Perhaps they can be forced to pay for a border
fence.)

> It comes back to - how much is it "programmers are lazy" vs how much
> is "well actually it is real work".

Please figure that out and report back to us.  I'll mail you a shiny
pre-Ted Heath-era pre-decimalisation penny for your efforts.  ;->

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[fsmithred]

On 07/19/2016 07:30 AM, fsmithred wrote:
> On 07/18/2016 04:36 PM, Rick Moen wrote:
>> Quoting Hendrik Boom (hend...@topoi.pooq.com):
>>> On Mon, Jul 18, 2016 at 08:54:44AM -0400, fsmithred wrote:
>>
 Pretty cool trick. I tried it and got mixed results. I'm running without
 libsystemd0 here, so I can't have gvfs-daemons. That means there's no
 trash icon on the desktop and removable drives don't show up on the
 desktop when they're plugged it.

 With a dummy equivs libsystemd0, I get a trash icon that works, but the
 removable drives don't show up on the desktop. When I remove the dummy
 package and install the real libsystemd0, removables show up and
 mount/eject work as expected.
>>>
>>> So it does look as if libsystemd0  does do something.
>>
>> That doesn't logically follow.  My guesstimate is that some GNOME
>> plumbing is checking for some library function before it offers
>> the user 'removable drives [...] on the desktop'.  For libsystemd0
>> library functions to _do_ anything reportedly requires systemd be
>> present to be reached below the library, i.e., the lib is just interface
>> glue.
>>
>> If you really want to know for certain, read the calling and answering
>> source code.  (I won't bother, because I really have no interest at all
>> in GNOME, and prefer to avoid it.)
>>
>> GNOME is a brittle dependency hairball.  Surely that fact is clear, if
>> nothing else is.
>>
> 
> Rick, I don't understand your reasoning here. What I see is that gvfs can
> do something when the real libsystemd0 is installed that it can't do
> without libsystemd0 - that is, it shows removable drives on the desktop.
> The presence of systemd itself is not required for this - it's not installed.
> 
> Gnome probably has nothing at all to do with this. The only gnome packages
> installed here are gnome-accessibility-themes, gnome-icons,
> libgnome-keyring and libsoup-gnome. I'm running xfce desktop.
> 
> The next experiment I did was to chmod -R 000 /lib/systemd/. I'm running
> this on a live-usb, so I can't reboot without losing changes. I tried
> restarting udev and dbus one at a time, and additional usb drives still
> show up on the desktop. Tried logging out of the desktop and back in, and
> the drives still show up. Then I dropped to runlevel 1 and then went back
> to 2 and got to the desktop. The removalble drives stopped showing up on
> the desktop. I don't know what had to restart to make the permission
> changes take effect.
> 
> One odd thing: Fixed drives that are not in fstab show up on the desktop.
> This was not affected by the change in permissions on /lib/systemd, but it
> did depend on the presence of the real libsystemd0. Those drives don't
> show up on the desktop with the dummy libsystemd0 package.
> 
> I tried reading the source code for libsystemd0, but I don't read C, so I
> got nothing out of it.
> 
> -fsr
> 
> 

One more test - instead of 'chmod -R 000 /lib/systemd' I tried 'chmod -x
/lib/systemd/systemd-udevd' thus disabling an executable binary file that
libsystemd0 provides. Dropped to runlevel 1, ctrl-d to return to desktop,
and removable drives no longer appear on the desktop.

-fsr

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[fsmithred]

On 07/18/2016 04:36 PM, Rick Moen wrote:
> Quoting Hendrik Boom (hend...@topoi.pooq.com):
>> On Mon, Jul 18, 2016 at 08:54:44AM -0400, fsmithred wrote:
> 
>>> Pretty cool trick. I tried it and got mixed results. I'm running without
>>> libsystemd0 here, so I can't have gvfs-daemons. That means there's no
>>> trash icon on the desktop and removable drives don't show up on the
>>> desktop when they're plugged it.
>>>
>>> With a dummy equivs libsystemd0, I get a trash icon that works, but the
>>> removable drives don't show up on the desktop. When I remove the dummy
>>> package and install the real libsystemd0, removables show up and
>>> mount/eject work as expected.
>>
>> So it does look as if libsystemd0  does do something.
> 
> That doesn't logically follow.  My guesstimate is that some GNOME
> plumbing is checking for some library function before it offers
> the user 'removable drives [...] on the desktop'.  For libsystemd0
> library functions to _do_ anything reportedly requires systemd be
> present to be reached below the library, i.e., the lib is just interface
> glue.
> 
> If you really want to know for certain, read the calling and answering
> source code.  (I won't bother, because I really have no interest at all
> in GNOME, and prefer to avoid it.)
> 
> GNOME is a brittle dependency hairball.  Surely that fact is clear, if
> nothing else is.
> 

Rick, I don't understand your reasoning here. What I see is that gvfs can
do something when the real libsystemd0 is installed that it can't do
without libsystemd0 - that is, it shows removable drives on the desktop.
The presence of systemd itself is not required for this - it's not installed.

Gnome probably has nothing at all to do with this. The only gnome packages
installed here are gnome-accessibility-themes, gnome-icons,
libgnome-keyring and libsoup-gnome. I'm running xfce desktop.

The next experiment I did was to chmod -R 000 /lib/systemd/. I'm running
this on a live-usb, so I can't reboot without losing changes. I tried
restarting udev and dbus one at a time, and additional usb drives still
show up on the desktop. Tried logging out of the desktop and back in, and
the drives still show up. Then I dropped to runlevel 1 and then went back
to 2 and got to the desktop. The removalble drives stopped showing up on
the desktop. I don't know what had to restart to make the permission
changes take effect.

One odd thing: Fixed drives that are not in fstab show up on the desktop.
This was not affected by the change in permissions on /lib/systemd, but it
did depend on the presence of the real libsystemd0. Those drives don't
show up on the desktop with the dummy libsystemd0 package.

I tried reading the source code for libsystemd0, but I don't read C, so I
got nothing out of it.

-fsr


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[Simon Hobson]

Rick Moen  wrote:

> Remember that bit I posted about how /usr/bin/ssh makes dynamic library
> calls to sonames of two Kerberos libraries, even on the overwhelming
> majority of systems that do not implement Kerberos?
...
> 'Trust' in the sense you use the word just isn't in that.

But it is.
Have you actually checked any (or all) of the libraries to be sure ? I suspect 
not - because inherently you "trust" that these are projects from reasonable 
people following the "do one thing ..." philosophy. Additionally you trust that 
if they did try anything, you'd get to hear about it.

I almost certainly apply more trust than you do in this wort of thing - because 
you clearly have more skills in the area of programming than I have and so I 
have to put some trust in others to "do the right thing" in terms of what makes 
it into a distro package.

The point is, which you seem to keep missing, is that I do not have this level 
of trust in anyone pushing systemd. And given the amount of noise surrounding 
systemd, I additionally can't trust that if someone untoward did slip into 
libsystemd that I'd hear about it in all the noise.

Plus, as someone else pointed out, to permit libsystemd0 (or equivs *IFF* it 
doesn't break packages - which it does with ClamAV) is tacitly accepting that 
these packages are OK to blindly depend on it. If the packagers can package 
that dependency and not get pushback from the users, then there's no incentive 
to consider if it might not be "right".


But one thing that hasn't been answered by anyone, and I'm sure there must be a 
couple of people here with the level of knowledge to answer it ...
How hard is it to replace a "call function_x_in_library_y" and die if library Y 
is missing, with something like "if_library_y_exists then call function_x" or 
"call function_x_in_library_y and handle failure gracefully if library Y isn't 
there" ?

When I raised this with ClamAV, the answer was "it's just one call, if SystemD 
is installed we never call anything else" - which implies that the cost of 
making it a soft dependency can't be that high. Ie, if you only cal it once, 
then the cost of checking first is only one check during start up !

It comes back to - how much is it "programmers are lazy" vs how much is "well 
actually it is real work".

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[Rick Moen]

Quoting Simon Hobson (li...@thehobsons.co.uk):

> Rick Moen  wrote:
> 
> > That doesn't logically follow.  My guesstimate is that some GNOME
> > plumbing is checking for some library function before it offers
> > the user 'removable drives [...] on the desktop'.  For libsystemd0
> > library functions to _do_ anything reportedly requires systemd be
> > present to be reached below the library, i.e., the lib is just interface
> > glue.
> 
> That is another possibility.

All my reading suggests it's exactly the situation.  Mind you, I haven't
looked into the matter deeply, as my attention has been needed on
countless other things.

> However, for that to be the case then they must be doing the "check if
> X exists before calling X" technique that I believe must be possible
> (simply because so many pieces of software have soft dependencies on
> optional modules).
>
> So if they are doing that with something in systemd itself, there is
> no reason not to do it with libsystemd0.

Programmers are lazy.  ;->

> But either way, even if libsystemd itself doesn't do (present tense) anything,

I have high confidence I'd have heard, were that the case.

> ...I have zero trust that it will remain that way.

I have high confidence I would hear, were that newly the case.

And then I'd remove the thing and substitute an equivs entry, about five
minutes after I heard.

Remember that bit I posted about how /usr/bin/ssh makes dynamic library
calls to sonames of two Kerberos libraries, even on the overwhelming
majority of systems that do not implement Kerberos?  That was one nearby
example from my own system, from among _countless others_ I could have
pointed to.  It's not a dire conspiracy; it's just regular, somewhat
overly inclusive default practices common among distro packagers.  I'm
not going to become actively paranoid about libgssapi_krb5.so.2 and
libkrb5.so.3 packagers, nor about upstream Kerberos5 coders, just
because either could 'shift some code into libkrb5.so.3'.  

Note that, even _if_ I thought upstream Kerberos5 coders were engaged in
a sinister conspiracy to take over all Linux distributions and
jeopardise our precious bodily fluids, I would not easily distrust
_both_ upstream Kerberos5 coders and distro Kerberos library (package)
maintainers who are, after all, gatekeepers.  Maybe you have time for
that degree of highly selective paranoia, but I don't.  I have to deal
with real threats.

But in the bizarre and (I thin) unlikely event of that being noneteless
the case, I'm confident I'd hear about it promptly, and I'd fix it
promptly.  ('This is Unix.  Stop acting so helpless.'  -- D.J.
Bernstein.)

'Trust' in the sense you use the word just isn't in that.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[Simon Hobson]

Rick Moen  wrote:

>> So it does look as if libsystemd0  does do something.
> 
> That doesn't logically follow.  My guesstimate is that some GNOME
> plumbing is checking for some library function before it offers
> the user 'removable drives [...] on the desktop'.  For libsystemd0
> library functions to _do_ anything reportedly requires systemd be
> present to be reached below the library, i.e., the lib is just interface
> glue.

That is another possibility.
However, for that to be the case then they must be doing the "check if X exists 
before calling X" technique that I believe must be possible (simply because so 
many pieces of software have soft dependencies on optional modules).

So if they are doing that with something in systemd itself, there is no reason 
not to do it with libsystemd0.

But either way, even if libsystemd itself doesn't do (present tense) anything, 
I have zero trust that it will remain that way. Supposing 
${desktop_environment} could really use a function for something (perhaps tied 
into Udev) - what's to stop the systemd guys "being helpful" and shifting some 
code into libsystemd ? Not a lot really - udev on one side, desktop environemnt 
on the other, and some "helpful" routines in between.

Breaks all the "standard practice" of only having glue in the library, rides 
roughshod over admin preferences, so we trust the systemd guys to never do it - 
right ?



Edward Bartolo  wrote:

> Libsystemd0 can be shrunk in cases only a few exported functions are
> needed. That is exactly what I did when systemd became mandatory in
> Debian around two years ago.  I used tools like ld, nm and grep to
> find which functions where used from libsystemd0. (See my howto on
> forums.debian.net). Knowing the names of the functions I copied them
> into a source file, obviously, wrote the exports statement and
> compiled the resulting source file. Then, I used a symbolic link
> pointing to tiny libsystemd0.
> 
> Now, someone may point fingers to denigrate what I wrote because it
> may not look professional to their tastes.

Not at all. It's one way round the "problem", and neatly gets round the 
potential for libsystemd being silently expanded into more than just glue.

However, it's another form of sticky tape to hold things together rather than 
fixing the problem at source.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[Edward Bartolo]

Hi,

Libsystemd0 can be shrunk in cases only a few exported functions are
needed. That is exactly what I did when systemd became mandatory in
Debian around two years ago.  I used tools like ld, nm and grep to
find which functions where used from libsystemd0. (See my howto on
forums.debian.net). Knowing the names of the functions I copied them
into a source file, obviously, wrote the exports statement and
compiled the resulting source file. Then, I used a symbolic link
pointing to tiny libsystemd0.

Now, someone may point fingers to denigrate what I wrote because it
may not look professional to their tastes. What counts is it worked
proving my logical evaluation was correct, irrespective of some
equating me to a pre-computing science child, notwithstanding I
produced an original package that works reliable using a technique
that no one used before.

Those who abuse me will be banned immediately from my email account:
you don't deserve to be listened to. This holds for everyone, Devuan
developer or not. Here, I am communicating with supposedly intelligent
adults who are responsible for their actions. They should know and
understand what they write. Many internet fora block such abuse
together with the abuser / bully.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] with or without libsystemd0

[Rick Moen]

Quoting Hendrik Boom (hend...@topoi.pooq.com):
> On Mon, Jul 18, 2016 at 08:54:44AM -0400, fsmithred wrote:

> > Pretty cool trick. I tried it and got mixed results. I'm running without
> > libsystemd0 here, so I can't have gvfs-daemons. That means there's no
> > trash icon on the desktop and removable drives don't show up on the
> > desktop when they're plugged it.
> > 
> > With a dummy equivs libsystemd0, I get a trash icon that works, but the
> > removable drives don't show up on the desktop. When I remove the dummy
> > package and install the real libsystemd0, removables show up and
> > mount/eject work as expected.
> 
> So it does look as if libsystemd0  does do something.

That doesn't logically follow.  My guesstimate is that some GNOME
plumbing is checking for some library function before it offers
the user 'removable drives [...] on the desktop'.  For libsystemd0
library functions to _do_ anything reportedly requires systemd be
present to be reached below the library, i.e., the lib is just interface
glue.

If you really want to know for certain, read the calling and answering
source code.  (I won't bother, because I really have no interest at all
in GNOME, and prefer to avoid it.)

GNOME is a brittle dependency hairball.  Surely that fact is clear, if
nothing else is.

-- 
Cheers,  « On donne des conseils, mais on ne 
Rick Moendonne point la sagesse d'en profiter. »
r...@linuxmafia.com -- La Rochefoucauld
McQ! (4x80)   
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] with or without libsystemd0

[Hendrik Boom]

On Mon, Jul 18, 2016 at 08:54:44AM -0400, fsmithred wrote:
> On 07/16/2016 05:12 AM, Rick Moen wrote:
> > You probably wouldn't even like removing libsystemd0 entirely and
> > replacing it with an 'equivs' recipe, which could also be done if one
> > really, really, really were concerned.
> > 
> > But, for those interested in that technique, see:  'How To Satisfy
> > Debian Dependencies Without Installing The Stupid Package' on
> > http://shallowsky.com/blog/linux/install/blocking-deb-dependencies.html
> 
> 
> Pretty cool trick. I tried it and got mixed results. I'm running without
> libsystemd0 here, so I can't have gvfs-daemons. That means there's no
> trash icon on the desktop and removable drives don't show up on the
> desktop when they're plugged it.
> 
> With a dummy equivs libsystemd0, I get a trash icon that works, but the
> removable drives don't show up on the desktop. When I remove the dummy
> package and install the real libsystemd0, removables show up and
> mount/eject work as expected.

So it does look as if libsystemd0  does do something.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng