[arch-general] [OT] What is wrong with DBus anyway?

Raghavendra Prabhu raghu.prabhu13 at gmail.com
Thu Dec 3 16:55:40 EST 2009


I never had dbus crashing anytime.. Regarding communication channels - there
are two types in dbus - one is system and other is userland.. So dbus
provided something for userland apps which could not use IPC for some
reason.

Another main reason as pointed above, it is general pub/sub system - which
wasn't there before, and it is quite generic in that publishing to an
interface works(need not know underlying stuff).

Regarding bad experiences with dbus, it is the application's fault. If app
is having problem with dbus, then compile that app without dbus. If that
doesnt work then ditch that application. (send flame mail to app creator :)
if you are over pissed)



On Fri, Dec 4, 2009 at 2:45 AM, David Rosenstrauch <darose at darose.net>wrote:

> On 12/03/2009 12:29 PM, Aaron Griffin wrote:
>
>> Mechanisms have existed for like 20 years before dbus to communicate
>> with other programs. dbus is just another way to do it that has a
>> smell of "architecture astronomy" - as if they all scoffed at the
>> actual ways to do IPC on various Unicies and said "Oh, I can design
>> better".
>>
>> That's why I dislike it.
>>
>
> I'll preface this by right up front saying that my knowledge of dbus is
> actually pretty limited.  So forgive me if I'm off-base in my comments.
>
> But frankly, I didn't think the *intent* behind dbus was as a replacement
> for IPC.  As I understood it, dbus was intended to be a system-wide message
> bus - i.e., a very generic pub/sub type of system that could be used by any
> component in the system.  Some components would publish messages of a
> particular, and other components would get notified about messages of a type
> they're interested in and react to them.
>
> Makes some sense to me to do things this way, as then you can just have a
> single, standard system-wide daemon that every app interacts with in the
> same way, rather than force each app to reinvent the wheel and implement
> their own solution.
>
> DR
>


More information about the arch-general mailing list