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) -- alan dot mckinnon at gmail dot com
