What's potato, as said in the mailing list?
“DBus is seriously screwed up”
71–80 of 209 posts
Re: “DBus is seriously screwed up”
#72Earlier quoted context omitted.
Is there a document that explains the why's and wherefores of dbus? Aside from those posts.
You can probably find it here: https://wiki.freedesktop.org/www/Software/dbus/
Is there a paper/article that discusses and categorizes the differences between IPC mechanism? Their pros and cons etc.
What mechanisms are there? What is used on Windows? OS X/iOS? QNX? BeOS? Android? Solaris? etc.
The Wikipedia article on IPC https://en.wikipedia.org/wiki/Inter-process_communication is really incomplete.
Re: “DBus is seriously screwed up”
#73Another great Linus quote: "The people who talk about how kdbus improves performance are just full of sh*t." http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...
As entertaining as it might be to people who are entertained by such things ("not me" would be an extreme understatement), it's pretty much exhibit A for Linus' inability to manage people in addition to code. It's embarrassing, honestly.
Re: “DBus is seriously screwed up”
#74Should be rewritten in Erlang or Go, if you'd ask me.
Re: “DBus is seriously screwed up”
#75Earlier quoted context omitted.
So, basically, systemd-bus would solve the problems even without kdbus, if it avoided all the extraneous memory allocations.
I don't think Linus is up to date on libgio-2.0 (and the GDBus implementation). It does in fact use a SLAB, based on early kernel versions with per-thread allocation caching. As for avoiding utf8 validation, that would require being able to trust the sender/receiver. That, I believe, is a major bullet point of both memfd (sealing) and kdbus.
Linus' trace shows that 12% of the runtime is spent in libc's malloc and free. So yeah, there's a problem there.
Re: “DBus is seriously screwed up”
#76> Since then I'm convinced that people who are inventing RPC solve non-existing problems. Many RPC solutions ultimately failed, because they were slow and overdesigned/complex. (e.g. CORBA, Network OLE/DCOM, Java RMI, XML-RPC/SOAP and other XML-based protocols, etc.) Whereas e.g. REST (if you call it even RPC) is just very simple and enough for most purposes. It's more like the concept of Component Object Model faile…
You do realize that pretty much whole of Windows is, underneath, based on COM, including most of the .Net-exposed system API's? I'll agree that COM and DCOM are... hairy, if you're implementing COM objects 'by hand'. But there's a reason for all of it, and I have yet to see an easier and more flexible way to write cross-language components. I could write a COM object in C++, call it from VBScript in a very simple com…
COM sort of works, on Windows, when when one or preferably both sides of the connecting components are made by Microsoft. You never see non-Microsoft code talking to non-Microsoft code from a different vendor via COM. This is not a successful component interface standard.
Re: “DBus is seriously screwed up”
#77Earlier quoted context omitted.
It's more like the concept of Component Object Model failed. For example OLE (the base technology behind DCOM) doesn't fly beside the legacy Office usage. True, but the idea of the self-registering COM object eventually seemed to limp across the finish line. Anyways. "Two key kdbus developers" ( ahem ) have said that the entire kernel signal mechanism should be deprecated because it's "too brittle and complex". When…
Except they're not wrong. We have a potentially infinite set of signals and data we'd like to communicate to programs and a very limited set of signals to do it with. I mean apache uses sigwinch as an exit code!
We have a potentially infinite set of signals and data we'd like to communicate to programs
Ah, I think I've identified your problem.
Signals are for alerting programs to a specific (small) set of changes of external states. There's nothing "potentially infinite" there (frankly having 2 different SIGUSR's is generous).
For transmitting arbitrary messages, Linux provides message queues, which are very nearly sockets (and the ways they aren't sockets make using them for IPC easier). What's the limitation there?
It lacks multicast, sure, but then receivers can just make their own queues and have the broadcaster send to them if you want that.
Re: “DBus is seriously screwed up”
#78Should be rewritten in Erlang or Go, if you'd ask me.
[deleted]
Re: “DBus is seriously screwed up”
#79Should be rewritten in Erlang or Go, if you'd ask me.
Are you missing '/s'?
Re: “DBus is seriously screwed up”
#80Earlier quoted context omitted.
That was my first reaction as well. But to be fair, the kdbus people always said the real speedup will be seen for large packets. However, the real issue is how slow overall DBus seems to be according to those numbers. As Linus says earlier in the thread: "No way should it take 4+ seconds to send a 1000b message to back and forth 20k times." This is indeed rather shocking.
So what's the use case for sending large packets of data over dbus where the performance gains warrant integrating the dbus server to the kernel? Are they planning to migrate the X server to dbus?
X is going to be migrated into the recycling bin. Lennart wants to migrate PA to dbus, and the possibility exists for doing the same for some future version of Wayland.