On Thu, 11 Feb 2010 23:13:14 +0100, Alan McKinnon
<alan.mckinnon@(protected):

> On Thursday 11 February 2010 23:40:37 Zeerak Waseem wrote:
>> True, but even those using Openbox, icewm, etc. were introduced to the
>> mess that HAL is, and also to dbus. Sure you can choose not to have
>> hal/dbus/*kit, but then you also choose not to use a growing number of
>> apps that seem to depend on it. The way I see it, they should be
>> optional
>> features. If you've got the useflags set, great. If not, then it'll
>> still
>> be able to compile and run.
>
> And what exactly is the problem with dbus? At 2MB, it's one of the
> smallest
> apps on my notebook. It's memory usage is miniscule, I have to invoke
> magic to
> get it to show up in top.
>
> All I hear from the anti-dbus crowd is complaints "that it's there" and
> not a
> single shred of evidence, fact or numbers anywhere to back up why it
> might be
> a bad thing.
>
> Let's rather all sit down and add up the the potential code and resource
> REDUCTION from dbus due to duplicated functionality being removed from
> multiple apps.
> Complaints that reduce to "it's there now and it wasn't there before"
> cannot
> be valid for that reason alone - inotify is there now and wasn't there
> before,
> the resource reduction from it's being added is miniscule compared to the
> amount of polling we now do not have to do. Many other examples exist.
>
> hal is different and in a category of it's own; it's resource usage is
> very
> small but the developer screwed up by making it complex for users (for
> the
> machine it's actually quite simple). We can fix that, and are - udev. I
> don't
> see anyone complaining about it being there now and not being there
> before.
> Anyone remember what came before udev? Who remembers trying to figure out
> devfs? Or MKNODE?
>
> Do keep in mind that even simple WMs use some form of IPC (well, maybe
> twm
> doesn't). The dev has various schemes he can use from pipes on the
> command
> line to named pipes and fifos, or he can use a message bus.
>
> Personally, I'd go with the latter even if only becuase somebody else
> with a
> proven track record is maintaining it (so I don't have to)
>
>

Oh there's not much of a problem with dbus to be quite honest. But that
perhaps is a bit of the point, that dbus seems like it might be, as
someone else put it, a "solution-in-search-of-a-problem".
I can see why it can be smart, but I can also see why it's labeled as a
bit useless. Particularly when your wm can handle all the inter-app
communication that is necessary without dbus.
Like said, I don't particularly mind it for DE's but if you choose a wm,
often you are willingly choosing to be lacking a few things that a DE
does. I think that the issue for the "anti-dbus crowd" is that it's
something that is being forced on them, despite having no need of it.

--
Zeerak