1 |
On Thu, 11 Feb 2010 23:13:14 +0100, Alan McKinnon |
2 |
<alan.mckinnon@×××××.com> wrote: |
3 |
|
4 |
> On Thursday 11 February 2010 23:40:37 Zeerak Waseem wrote: |
5 |
>> True, but even those using Openbox, icewm, etc. were introduced to the |
6 |
>> mess that HAL is, and also to dbus. Sure you can choose not to have |
7 |
>> hal/dbus/*kit, but then you also choose not to use a growing number of |
8 |
>> apps that seem to depend on it. The way I see it, they should be |
9 |
>> optional |
10 |
>> features. If you've got the useflags set, great. If not, then it'll |
11 |
>> still |
12 |
>> be able to compile and run. |
13 |
> |
14 |
> And what exactly is the problem with dbus? At 2MB, it's one of the |
15 |
> smallest |
16 |
> apps on my notebook. It's memory usage is miniscule, I have to invoke |
17 |
> magic to |
18 |
> get it to show up in top. |
19 |
> |
20 |
> All I hear from the anti-dbus crowd is complaints "that it's there" and |
21 |
> not a |
22 |
> single shred of evidence, fact or numbers anywhere to back up why it |
23 |
> might be |
24 |
> a bad thing. |
25 |
> |
26 |
> Let's rather all sit down and add up the the potential code and resource |
27 |
> REDUCTION from dbus due to duplicated functionality being removed from |
28 |
> multiple apps. |
29 |
> Complaints that reduce to "it's there now and it wasn't there before" |
30 |
> cannot |
31 |
> be valid for that reason alone - inotify is there now and wasn't there |
32 |
> before, |
33 |
> the resource reduction from it's being added is miniscule compared to the |
34 |
> amount of polling we now do not have to do. Many other examples exist. |
35 |
> |
36 |
> hal is different and in a category of it's own; it's resource usage is |
37 |
> very |
38 |
> small but the developer screwed up by making it complex for users (for |
39 |
> the |
40 |
> machine it's actually quite simple). We can fix that, and are - udev. I |
41 |
> don't |
42 |
> see anyone complaining about it being there now and not being there |
43 |
> before. |
44 |
> Anyone remember what came before udev? Who remembers trying to figure out |
45 |
> devfs? Or MKNODE? |
46 |
> |
47 |
> Do keep in mind that even simple WMs use some form of IPC (well, maybe |
48 |
> twm |
49 |
> doesn't). The dev has various schemes he can use from pipes on the |
50 |
> command |
51 |
> line to named pipes and fifos, or he can use a message bus. |
52 |
> |
53 |
> Personally, I'd go with the latter even if only becuase somebody else |
54 |
> with a |
55 |
> proven track record is maintaining it (so I don't have to) |
56 |
> |
57 |
> |
58 |
|
59 |
Oh there's not much of a problem with dbus to be quite honest. But that |
60 |
perhaps is a bit of the point, that dbus seems like it might be, as |
61 |
someone else put it, a "solution-in-search-of-a-problem". |
62 |
I can see why it can be smart, but I can also see why it's labeled as a |
63 |
bit useless. Particularly when your wm can handle all the inter-app |
64 |
communication that is necessary without dbus. |
65 |
Like said, I don't particularly mind it for DE's but if you choose a wm, |
66 |
often you are willingly choosing to be lacking a few things that a DE |
67 |
does. I think that the issue for the "anti-dbus crowd" is that it's |
68 |
something that is being forced on them, despite having no need of it. |
69 |
|
70 |
-- |
71 |
Zeerak |