On Sat, 16 Jun 2018 12:32:53 -1000 Joel Roth <[email protected]> wrote:
> Svante Signell wrote: > > This is a really good initiative :) Let's get rid of that dbus > > bloat! > > I'm reading a little more about dbus, and find it was > developed by Havoc Pennington, one of the important kernel > contributors, IIRC. > > I'm not sure *I* need it, but he makes a good case for it > and explains some apparent oddities here: > > https://news.ycombinator.com/item?id=8648437 Ugh! > > in response to this critical article. > > http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html As I suspected. Litt's opinion: The whole concept of one central message center to unite them all is deeply flawed. First of all, it's a horrible violation of encapsulation. The implication is everything is everybody else's business. What could *possibly* go wrong. Corba, COM, DCOP, dbus, the desired outcome is undesirable. My personal experience with DCOP and dbus, via KDE applications, was abominable. At one time, before I dumped ALL KDE apps (pretty much for the same reasons I refuse to get involved with systemd) in 2012, I wrote a daemon that: 1) Every 5 seconds did a PS to see all dbus-daemon pids that consumed over 95% of CPU 2) Any such pids that had produced a similar result 5 seconds before was killed with a kill -9 It was only after I started running that daemon that I could go a whole day without having to kill and restart X. Before DCOP and DBUS were written, we knew from Corba and COM that any solutions to this "IPC" need were hugely complex. Sure enough, dbus is complex enough that it's almost unexplainable, according to the second URL you provided (and I sure can't explain it). And it's handled by the FreeDesktop.Org folks, who are fervent fans of complexity. I've always felt if two processes need to communicate, they should do it between themselves. One time I wrote some programs to digitize vinyl records, and of course I wanted to spend the time one record played and was being recorded to input the metadata for the next record. I did it with a queue and a couple shellscripts, visible on page 20 of the following: http://troubleshooters.com/linux/presentations/leap_digitizing/leap_digitizing.pdf I have created playlist managers, consisting of multiple processes, who communicate via files, and signal each other of the immediate availablilty of the file using a kill -s USER1 to inform the other process. And the beauty is, these communications had no way to find their way to other processes, because they were specifically programmed for processes that needed them. > Linus has been critical of the protocol design. At the time > the kdbus kernel module was proposed, He said that flaws in > in the protocol are to blame for poor performance rather > than kernel limitations. > > Also, some blame can be laid on the application developers. > It's one thing to use dbus for automounting an external > drive, other to use it hundreds or thousands of times per > second. However from their point of view, convenience > matters more, and processors are certain to get faster. I'd be even more critical: I think a lot of the use of dbus is so the programmer can brag dbus programming on their resume. > Those who care enough about reducing the overhead will avoid > or limit their use of dbus. Agreed. SteveT Steve Litt June 2018 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
