how much of puppy requires dbus?
- nosystemdthanks
- Posts: 703
- Joined: Thu 03 May 2018, 16:13
- Contact:
how much of puppy requires dbus?
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.
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.
Running a reverse ldd on Radky's dpup Stretch, reveals 69!
Don't have tahr or xenial installed, but imagine they may be similar.
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
- nosystemdthanks
- Posts: 703
- Joined: Thu 03 May 2018, 16:13
- Contact:
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.
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.
thank you, thats progress!s243a wrote:If you don't mind using an older version of puppylinux, Warry doesn't have it.
-
- Posts: 721
- Joined: Sat 31 Mar 2018, 08:01
- Location: Rakaia
- Contact:
- nosystemdthanks
- Posts: 703
- Joined: Thu 03 May 2018, 16:13
- Contact:
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)
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
Lucid 5.2.8.7
Search by pfind: 26 entries
Audacious is my personal addition, I don't know if that 'contaminated' Lucid. But in good, old Cups?
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
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
True freedom is a live Puppy on a multisession CD/DVD.
- nosystemdthanks
- Posts: 703
- Joined: Thu 03 May 2018, 16:13
- Contact:
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.
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.
Posting from self-built Devuan:
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.
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:#
I am going Off-topic somewhat.
I want to check dbus use in Fatdog, But...
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....
I want to check dbus use in Fatdog, But...
How do you reverse ldd???Keef wrote:Running a reverse ldd on Radky's dpup Stretch, reveals 69!
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
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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.anikin wrote:Posting from self-built Devuan: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.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:#
@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
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
- nosystemdthanks
- Posts: 703
- Joined: Thu 03 May 2018, 16:13
- Contact:
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
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
Last edited by Keef on Tue 08 May 2018, 07:08, edited 1 time in total.
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
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
-
- Posts: 721
- Joined: Sat 31 Mar 2018, 08:01
- Location: Rakaia
- Contact:
@nosystemdthanks you may find this of interest.
http://www.murga-linux.com/puppy/viewto ... 93&start=1
http://www.murga-linux.com/puppy/viewto ... 93&start=1
- nosystemdthanks
- Posts: 703
- Joined: Thu 03 May 2018, 16:13
- Contact:
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.
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
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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.
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.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
- nosystemdthanks
- Posts: 703
- Joined: Thu 03 May 2018, 16:13
- Contact:
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.
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.
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. Think of the power of Debian ...
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:~#