Re: [DNG] with or without libsystemd0
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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