“DBus is seriously screwed up”
thread.gmane.org
“DBus is seriously screwed up”
1–10 of 209 posts
Re: “DBus is seriously screwed up”
#2And https://lwn.net/Articles/636997/
But, let's stop bitching and come up with alternatives, solutions, or closure. I'm tired of hearing about KDBUS (all love to gregkh) and DBUS.
Re: “DBus is seriously screwed up”
#3And https://lwn.net/Articles/636997/ But, let's stop bitching and come up with alternatives, solutions, or closure. I'm tired of hearing about KDBUS (all love to gregkh) and DBUS.
Good link.
As a side note, I see sorokin's posts about DCOM, RPC and multi-threading:
> Probably some unique thread-id can be propagated through the calls. And if incoming call has the same thread-id as one of our outgoing call it is handled inside this outgoing call as in nested message loop, otherwise a new thread from thread pool is used. This will create an illusion that two processes share the same set of threads and it works well with mutexes.
I think he is slowly driving towards an actor like message passing thing like Erlang, Akka or Orleans without even realizing.
Which reminds me of Virding's law:
http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-...
---
Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.
---
Re: “DBus is seriously screwed up”
#4He's not saying DBus as a concept is bad, just that the implementation sucks. If he's right, that's something that can be fixed relatively easily (compared to a major architectural change).
Re: “DBus is seriously screwed up”
#5> 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 failed. For example OLE (the base technology behind DCOM) doesn't fly beside the legacy Office usage. It goes without saying that binary based implementations of such Component Object Model are faster than XML based ones - a fade of the last ten years.
The component format (if you call it that way) that just works is HTML5.
Edit: okay, it seems it's a controversial topic (My comment used examples which were DCOM and OLE 1+2 (the original MS Office thing "Compound document") - http://en.wikipedia.org/wiki/Object_Linking_and_Embedding and http://en.wikipedia.org/wiki/Compound_document , not COM directly)
Re: “DBus is seriously screwed up”
#6He's not saying DBus as a concept is bad, just that the implementation sucks. If he's right, that's something that can be fixed relatively easily (compared to a major architectural change).
I agree, the OP title is a bit misleading.
I use dbus every day on my laptop and it works totally fine - I don't notice its existence. I'm all for improvements, but I'm quite patient and quite happy to wait this one out.
Re: “DBus is seriously screwed up”
#7> 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…
The problem with REST is that it's great for what it was intended to do initially, but there are too many engineers that don't take their medication that actually use it to do RPC :P
Re: “DBus is seriously screwed up”
#8> 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…
Naive REST (HTTP, JSON) isn't exactly known for its performance
Re: “DBus is seriously screwed up”
#9And https://lwn.net/Articles/636997/ But, let's stop bitching and come up with alternatives, solutions, or closure. I'm tired of hearing about KDBUS (all love to gregkh) and DBUS.
alternatives, solutions, or closure
The link you posted has what I think is the right one:
The problem is that probably this code is not needed at all.
To me, DBUS seems like a solution looking for a problem: The majority of the time there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives.
Re: “DBus is seriously screwed up”
#10> 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…
Apples and protocols.
REST is an architectural approach, and it can very well be using the same overdesigned XML envelopes, binary-encoded payload or anything else, really.