On Wed, 3 Sep 2014 21:38:47 +0100 Jonathan Dowland <j...@debian.org> wrote:
> On Wed, Sep 03, 2014 at 03:54:06AM +0200, Bzzzz wrote: > > Hehe, because it sinks his claws deep and everywhere (it also > > plans to implant dbus _into_ the kernel (WTF? A kernel is > > here to kernelling and nothing else AFAIK), > > Plans to move bits of dbus into the kernel predate systemd. The first > serious effort I am aware of was patches by Vince Sanders (and > possibly others) to add a DBUS socket type, but they were nixed by > the network maintainer. It now looks like it might happen with KDBUS. > Other than having Lennart's involvement, I don't think this has > anything much to do with systemd. > > kernel support is pretty much essential to improve the performance of > dbus. Lots of data is being passed over dbus by apps nowadays, and > because it's an entirely userspace solution that means data is being > copied from process to process. These needless copies can be avoided > with some kind of help from the kernel, but none of the existing IPC > mechanisms are good enough. Hi Jonathan, Maybe you or someone else can explain the need for dbus. First, I should say that as an ex Kmail user, I was constantly afflicted with runaway, 95% CPU consuming dbus-daemon instances, and so I have a bad attitude toward DBUS, KDE, and the whole "programs communicate with each other" thing. To me, programs not knowing each others' business is a *good* thing. To me, having something like DBUS is sort of like using global variables in programming, in that you can quickly lose track of who said what to whom. The only time I've consciously used is for notifications, and notifications could have been done just as easily with a socket, with all programs writing to the socket and the actual notifications printed and handled by the socket's server. Unless different "client" programs need to know what other "client" programs are doing, and why would anyone construct a system that way? The few times I needed two programs to communicate, there were always relatively easy ways. One obvious example is mplayer's fifo API, so I can control a running instance of mplayer from my own program. Another is the Nullmailer program, which receives email files in a queue directory, and when the client sends an interrupt (SIGUSR1 if I remember correctly), Nullmailer breaks its normal sleep and processes the queue directory. My vinyl record digitation scripts communicate through a fifo, and are shown on slide 19 of this file: http://www.troubleshooters.com/linux/presentations/leap_digitizing/leap_digitizing.pdf The main advantage I see of things like signals, fifos, sockets, intermediate file and the like, as opposed to DBUS, is that when troubleshooting the former, you have a much smaller suspect pool than if they'd used DBUS, in which case your suspect pool would be every DBUS aware program running on your system. Was DBUS created just for crazy entangled suites like KDE, or does it have a more basic use within Linux? Thanks, SteveT Steve Litt * http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140904112459.0630d...@mydesq2.domain.cxm