how much of puppy requires dbus?

[nosystemdthanks]

so the last time i used puppy, it was puppy tahr-- i havent tried xenial and whether this is answered about tahr or answered about xenial, thats fine. even if the answer isnt the same-- either way.

dbus is in a lot of stuff now, its even in the kate text editor (im a little surprised) but puppy is usually light on extras because it doesnt need them.)

i can check, but im guessing puppy (tahr, xenial) uses dbus. if not, cool! if so: i figured, but how much stuff in puppy actually uses it? if you were trying to remove dbus from puppy, would it be really difficult?

i asked this in the programming section as im pretty sure this is where people will have the answer.

thanks.

[Keef]

Running a reverse ldd on Radky's dpup Stretch, reveals 69!

Code: Select all

/usr/bin/cancel
/usr/bin/compton
/usr/bin/cupstestdsc
/usr/bin/cupstestppd
/usr/bin/dbus-monitor
/usr/bin/dbus-send
/usr/bin/dbus-uuidgen
/usr/bin/directomatic
/usr/bin/dunst
/usr/bin/ffmpeg
/usr/bin/ffplay
/usr/bin/ffprobe
/usr/bin/ffserver
/usr/bin/foomatic-rip
/usr/bin/galculator
/usr/bin/gconf-merge-tree
/usr/bin/gconftool
/usr/bin/gconftool-2
/usr/bin/ghostscript
/usr/bin/gnome-alsamixer-bin
/usr/bin/gs
/usr/bin/gsc
/usr/bin/gsettings-data-convert
/usr/bin/gsx
/usr/bin/gtklp
/usr/bin/gtklpq
/usr/bin/hexchat
/usr/bin/lp
/usr/bin/lpoptions
/usr/bin/lpq
/usr/bin/lpr
/usr/bin/lprm
/usr/bin/lpstat
/usr/bin/mhwaveedit
/usr/bin/mplayer
/usr/bin/mpv
/usr/bin/net
/usr/bin/pcmanfm
/usr/bin/planner
/usr/bin/pnmixer
/usr/bin/ppdc
/usr/bin/ppdhtml
/usr/bin/ppdi
/usr/bin/ppdmerge
/usr/bin/ppdpo
/usr/bin/rsvg-view-3
/usr/bin/smbstatus
/usr/bin/uget-gtk
/usr/bin/dbus-binding-tool
/usr/bin/glade
/usr/bin/glade-previewer
/sbin/wpa_supplicant
/usr/sbin/accept
/usr/sbin/cupsaccept
/usr/sbin/cupsaddsmb
/usr/sbin/cupsctl
/usr/sbin/cupsd
/usr/sbin/cupsdisable
/usr/sbin/cupsenable
/usr/sbin/cupsfilter
/usr/sbin/cupsreject
/usr/sbin/lpadmin
/usr/sbin/lpc
/usr/sbin/lpdomatic
/usr/sbin/lpinfo
/usr/sbin/lpmove
/usr/sbin/reject
/usr/sbin/smbd
/usr/games/xsoldier

Don't have tahr or xenial installed, but imagine they may be similar.

[s243a]

If you don't mind using an older version of puppylinux, Warry doesn't have it. Also check to see if some of the versions of Quirky kept it out.

[nosystemdthanks]

thats actually well on our way to a great answer, thank you-- im far less shocked that a dpup (although im a fan of dpup) has dbus because debian is very heavily infested with superfluous ipc.

the saving grace really might be woof-ce and tahr or xenial here. i do totally understand that tahr is ubuntu and ubuntu is from debian.

the difference (if any at all) is the process tahr goes through as opposed to the process dpup goes through. for whatever reason, im still hoping that dpup is less conservative and more likely to have dbus. but at this point i might just open up tahr and check it out-- in the next day or two. thank you.

If you don't mind using an older version of puppylinux, Warry doesn't have it.

thank you, thats progress!

[darry19662018]

Hi nosystemdthanks,

Only Pup I know of would be as mentioned the old Wary series based on T2 packages there was a Puppy package you could install called nobus which replaced dbus by one of our forum members who has long gone may be someone can enlighten??

[nosystemdthanks]

in fairness to all the helpful people who chimed in (thank you) heres the results from tahr (i presume with good reason that its even worse in xenial...)

i was hoping that woof cleaned this all out, but it was purely a guess on my part. its not like woof is *adding* this stuff. im sure it would be removed if that were the decision that made the best sense.

my first distro (of my own) was based on puppy, and the indirect result of asking questions just like this one. today, i found out that puppy tahr (while free of systemd) still had some .service files. i have yet to figure out exactly why machines without systemd even need .service files, but puppy is not alone in this. (heck, the setup im using now has .service files.)

puppy tahr (32 bit)

Code: Select all

    27	/etc/dbus-1
    28	/etc/dbus-1/session.conf
    29	/etc/dbus-1/system.conf
    30	/etc/dbus-1/system.d

    47	/lib/libdbus-1.so.3
    48	/lib/libdbus-1.so.3.7.6

    54	/opt/palemoon/components/libdbusservice.so
    69	/root/.packages/builtin_files/dbus-bin
    70	/root/.packages/builtin_files/dbus-glib
    71	/root/.packages/builtin_files/dbus-libs
    76	/root/.packages/builtin_files/libdbusmenu

    91	/usr/bin/dbus-cleanup-sockets
    92	/usr/bin/dbus-daemon
    93	/usr/bin/dbus-launch
    94	/usr/bin/dbus-monitor
    95	/usr/bin/dbus-send
    96	/usr/bin/dbus-uuidgen

   100	/usr/bin/gdbus
   113	/usr/bin/qdbus
   114	/usr/bin/qdbuscpp2xml
   115	/usr/bin/qdbusviewer
   116	/usr/bin/qdbusxml2cpp

   242	/usr/lib/libdbus-1.so
   243	/usr/lib/libdbus-glib-1.so
   244	/usr/lib/libdbus-glib-1.so.2
   245	/usr/lib/libdbus-glib-1.so.2.2.2
   246	/usr/lib/libdbusmenu-glib.so.4
   247	/usr/lib/libdbusmenu-glib.so.4.0.12
   248	/usr/lib/libdbusmenu-gtk.so.4
   249	/usr/lib/libdbusmenu-gtk.so.4.0.12
   251	/usr/lib/libdconf-dbus-1.so.0
   252	/usr/lib/libdconf-dbus-1.so.0.0.0

   306	/usr/lib/qt4/bin/qdbus
   309	/usr/lib/qt4/plugins/script/libqtscriptdbus.so

   314	/usr/lib/vlc/plugins/control/libdbus_plugin.so
   315	/usr/lib/vlc/plugins/misc/libdbus_screensaver_plugin.so
   317	/usr/libexec/dbus-1
   318	/usr/libexec/dbus-daemon-launch-helper
   321	/usr/sbin/cdburner-wizard

   326	/usr/share/dbus-1
   327	/usr/share/dbus-1/services
   328	/usr/share/dbus-1/services/ca.desrt.dconf.service
   329	/usr/share/dbus-1/services/gnome-vfs-daemon.service
   330	/usr/share/dbus-1/services/org.gnome.GConf.service
   331	/usr/share/dbus-1/services/org.hexchat.service.service
   332	/usr/share/dbus-1/services/org.knopwob.dunst.service
   333	/usr/share/dbus-1/system-services
   334	/usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service
   335	/usr/share/dbus-1/system-services/fi.w1.wpa_supplicant1.service

   353	/usr/share/themes/oxygen-gtk/gtk-3.0/special-icons/standardbutton-closetab-16.png
   354	/usr/share/themes/oxygen-gtk/gtk-3.0/special-icons/standardbutton-closetab-down-16.png
   355	/usr/share/themes/oxygen-gtk/gtk-3.0/special-icons/standardbutton-closetab-hover-16.png

   358	/var/lib/dbus
   360	/var/run/dbus

[tallboy]

Lucid 5.2.8.7

Code: Select all

: 21:00 ~ ; db
dbus-binding-tool     dbus-launch           dbus-uuidgen
dbus-cleanup-sockets  dbus-monitor          dbwrap_tool
dbus-daemon           dbus-send             
: 21:00 ~ ; db

Search by pfind: 26 entries

Code: Select all

/etc/dbus-1
/opt/palemoon/components/libdbusservice.so
/root/.dbus
/root/.packages/builtin_files/dbus
/root/.packages/builtin_files/dbus-glib
/usr/bin/dbus-binding-tool
/usr/bin/dbus-cleanup-sockets
/usr/bin/dbus-daemon
/usr/bin/dbus-launch
/usr/bin/dbus-monitor
/usr/bin/dbus-send
/usr/bin/dbus-uuidgen
/usr/include/audacious/dbus.h
/usr/include/audacious/dbus-service.h
/usr/lib/cups/notifier/dbus
/usr/libexec/dbus-1
/usr/libexec/dbus-daemon-launch-helper
/usr/lib/gio/modules/libgvfsdbus.so
/usr/lib/libdbus-1.so.3
/usr/lib/libdbus-1.so.3.4.0
/usr/lib/libdbus-glib-1.so.2
/usr/lib/libdbus-glib-1.so.2.1.0
/usr/share/dbus-1
/usr/share/doc/gnome-mplayer/dbus.txt
/var/lib/dbus
/var/run/dbus

Audacious is my personal addition, I don't know if that 'contaminated' Lucid. But in good, old Cups?

[nosystemdthanks]

oh yeah you should expect dbus whenever theres cups, yes.

i wouldnt say that dbus is really avoidable when cups is installed, and cups isnt the only thing like that. kde and gnome certainly need dbus (i believe thats what it was made for originally.)

you can find a list of stuff thats likely to require dbus here: https://www.freedesktop.org/wiki/Software/DbusProjects/

i dont believe this will be of real concern to any puppy user. its just something im thinking about.

thanks again. fwiw ive got the information i needed, if someone wants to discuss this further i have no problem with that, i cant promise it will be interesting.

[anikin]

Posting from self-built Devuan:

Code: Select all

root@debian:# apt-get purge dbus systemd
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Package 'dbus' is not installed, so not removed
Package 'systemd' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 345 not upgraded.
root@debian:#

However, I must disappoint some of you folks - I am very much pro systemd and dislike the ideological BS behind the Devuan/anti systemd movement. But I do like the Devuan forum, their knowledgeable team and the technical stuff they discuss.

[drunkjedi]

I am going Off-topic somewhat.
I want to check dbus use in Fatdog, But...

Running a reverse ldd on Radky's dpup Stretch, reveals 69!

How do you reverse ldd???

I searched on web, not found much.
On one newsgroup someone gave a tcl script, I think it runs ldd on all executables or something....

Code: Select all

#!/usr/bin/tclsh

set bins {}
foreach p [split $::env(PATH) :] {
lappend bins [file join $p *]
}

foreach f [eval [list glob -nocomplain] $bins] {
if {[catch {exec ldd $f | grep -q [lindex $argv 0]}]} {continue}
puts $f
}

[technosaurus]

Posting from self-built Devuan:

Code: Select all

root@debian:# apt-get purge dbus systemd
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Package 'dbus' is not installed, so not removed
Package 'systemd' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 345 not upgraded.
root@debian:#

However, I must disappoint some of you folks - I am very much pro systemd and dislike the ideological BS behind the Devuan/anti systemd movement. But I do like the Devuan forum, their knowledgeable team and the technical stuff they discuss.

most of the anti systemd movement is more about not introducing a complex single point of failure from a group and lead developer known to push shitty products before they are working (pulseaudio) or breaking working projects (gnome/gtk3) to their own ends (redhat). Systemd keeps sucking in more and more stable projects and making them unstable for no useful purpose.

@drunkjedi I have posted reverse dependency code on here somewhere... It was less than 10 lines of code, but think you can just grep the installed package database for "+dbus" ... But that does packages, not individual binaries and libraries

[nosystemdthanks]

anikin: thats fantastic!

reverse ldd: ldd is less reliable than finding actual dbus files, it was actually this forum where i found out how misleading ldd can be sometimes. i was trying to use it to map deps in packages.

[Keef]

drunkjedi

The pet I used was this:
http://murga-linux.com/puppy/viewtopic. ... 1d67f3998f
Although it was something by technosaurus that I had in mind.
EDIT: Might have been this:
http://murga-linux.com/puppy/viewtopic.php?t=76827

[wiak]

Well, in my life I've programmed many an IPC facility in C and having a standardized communication bus removes the horrendous inefficiency and complexity and is very much a forward development IMO.

https://en.wikipedia.org/wiki/D-Bus

Similarly, the old init process is painfully serial and slow - whether systemd approach is any good or not I cannot say since I've never studied it, but I'm quite convinced the idea is sound. Most developers make technical blunders regularly - seems to me any issues with pulseaudio or systemd would be more a case of them being adopted too early though I suspect such decisions would not be taken lightly no matter if a developer pushed their ideas or not. I have heard pulseaudio has settled down in terms of stability now and certainly makes a lot possible that various alsa processes never could (my goodness even precord could have a VU record meter via pulseaudio facilities without having to muck around with C programming into alsa functions).

I think it is all more a matter of old dogs not liking learning new tricks. We all know init system for donkey years and can't be bothered learning the ins and outs of systemd. But in time all this will be forgotten because if you can't beat it you eventually have to join it. Good to have all these possibilities available at least, otherwise how can you learn what you will eventually have to? In all realism.

wiak

[darry19662018]

@nosystemdthanks you may find this of interest.
http://www.murga-linux.com/puppy/viewto ... 93&start=1

[nosystemdthanks]

over my head, though with a bit of research maybe down the road i could pull a few rabbits out of my hat with that.

one thing ive found through the years is that even if i dont understand what im reviewing (as may be the situation here-- im not saying its a complete mystery though i wouldnt say i have a firm grasp of it either) just the details included make huge leaps possible-- fodder for the next search for an ideal solution.

in short: if this doesnt do it, it might make it several times easier to find something that will. thanks.

[technosaurus]

I had almost forgotten about nobus. I mainly did de-bus to help puppy devs build packages that wouldn't let you disable dbus via configuration - then I found nobus and pointed people to it since I didn't really want to maintain yet another package. Its actually easier for me to grep the source and modify it to make a patch, so I never really used it much myself.

There are now similar projects on github for pulseaudio, systemd, logind, udev, libevent, alsa, x11, xserver and glibc

I should add these to the unbloated coding resources.

[nosystemdthanks]

even if you can forget about kdbus and bus1 (which funnily enough, arent what bother me the most at all, thought kdbus should be) im really beginning to think that dbus should be #2 on the list of concerns along with systemd (for those who believe systemd is a problem) and while it may not be entirely practical to avoid dbus for everybody (it certainly seems like puppy users have it as more of an option than a requirement, thats cool) it seems like a good thing to opt out of when possible.

the attitude about infrastructure that is developing lately seems to be: "unless you can show that its malware or of exceptionally low quality, you should probably include it in your distribution/installation"

this goes against all security advice (dont install or run services you dont actually need, dont have a larger attack surface than necessary) but lately the gnu/linux world inspired/infested by red hat and free desktop seems to be more like windows:

* keep adding features until new hardware is required

* develop bolt-on security gimmicks (there are so many) to treat the problems we just made, instead of preventing them with good practices

* point to all the bolt-on nonsense just added and say "its state of the art, we dont know why these 'hobbyist distros' cant keep up but theyre clearly inferior."

this goes beyond marketing, its just furthering a culture that lies to everyone for profit. ok, i may have contradicted myself a little there.

im not sure how much we want dbus in our world. but im hardly concerned if we have it around sometimes. it should be more of an option and im impressed at the amount work done in this regard.

also, if most people had this attitude about dbus back when it was just dbus, i dont think systemd would be the default in debian today.

the real problem is that debian decided at one point that bloat was fine and that if its useful to anybody, then no amount of gratuitous interdependency is bloat or bad design.

that, and the political moves that put debians init modularity (and support of multiple kernels!) into check was extremely nasty and well-played.

this is still about dbus, but broadly its about the sort of problems that things like systemd and dbus (and freedesktop and enterprise lock-in-by-design) creates.

as far as i know, the overlap of lock-in and foss is mostly treated as mythological and unimportant-- while the problem continues to grow and the justification for the problem is:

"we cant have nice things if we dont model all our designs after enterprise solutions!"

by that logic, coupes and sedans (forget bicycles) should not exist. we should only have vans and trailers and cargo shipping containers and freight-class vehicles.

its both bleak and hilarious, and seems to affect puppy users very little because every time they find bloat they lop it off at all costs, without any sentimentality whatsoever.

[anikin]

My Devuan doesn't have dbus as shown in my previous post. There was no need for it when I built the system. If I ever need it in the future - one little command and dbus will get installed without a hitch.

Code: Select all

root@debian:~# apt-get update && apt-get install dbus
Get:1 http://auto.mirror.devuan.org/merged jessie InRelease [108 kB]
Get:2 http://auto.mirror.devuan.org/merged jessie-updates InRelease [119 kB]
Get:3 http://auto.mirror.devuan.org/merged jessie-security InRelease [106 kB]
Get:4 http://auto.mirror.devuan.org/merged jessie/main i386 Packages [6,809 kB]
Get:5 http://auto.mirror.devuan.org/merged jessie-updates/main i386 Packages [20.9 kB]
Get:6 http://auto.mirror.devuan.org/merged jessie-security/main i386 Packages [470 kB]
Fetched 7,634 kB in 10s (728 kB/s)                                             
Reading package lists... Done
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Suggested packages:
  dbus-x11
The following NEW packages will be installed:
  dbus
0 upgraded, 1 newly installed, 0 to remove and 205 not upgraded.
Need to get 311 kB of archives.
After this operation, 1,132 kB of additional disk space will be used.
Get:1 http://auto.mirror.devuan.org/merged jessie/main i386 dbus i386 1.8.20-1+devuan1.1 [311 kB]
Fetched 311 kB in 0s (376 kB/s)
Selecting previously unselected package dbus.
(Reading database ... 23815 files and directories currently installed.)
Preparing to unpack .../dbus_1.8.20-1+devuan1.1_i386.deb ...
Unpacking dbus (1.8.20-1+devuan1.1) ...
Setting up dbus (1.8.20-1+devuan1.1) ...
[ ok ] Starting system message bus: dbus.
root@debian:~#

Think of the power of Debian ...

[wiak]

Fetched 311 kB in 0s (376 kB/s)

Preparing to unpack .../dbus_1.8.20-1+devuan1.1_i386.deb ...

Wow... bloat...

Which happens to be a useful interprocess comms facility for people who program (create new programs)