On Thu, 11 Feb 2010 23:13:14 +0100, Alan McKinnon
<alan.mckin...@gmail.com> wrote:
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
