Hi everybody!
Let me try to summarize the situation and add my 0.2 french francs.
The way I see it, all the problem is about how people want to compromise
between lightness and features. Some people want BB to be as light as
possible, others want more features. Personnally I am somewhere in
between: I can not live without bbkeys, but I don't really need a pager,
a slit or a taskbar. I hope this position allows me to be somewhat
neutral...
Those who like it light want all the extras to be kept outside of BB, in
order to keep the binary small. On the other hand, for those who like
the extras, having separate applications running at the same time is not
very efficient: there is the X-middleman problem, and I guess the total
binary size may be bigger if the applications are separate (correct me
if I'm grong on this point). So for those who want some extras, having
them integrated as tightly as possible in BB would be more efficient.
Is it possible to please everybody? Namely to have a very tight
integration of the extra features *you* want, without wasting ressources
with those *you* don't want? Maybe it is not possible, but I believe the
question is worth asking. Let's examine the options, from the tightest
integration to the loosest.
First option: put everything in the same binary. For this option I ask
myself the following question: what is the problem with having a big
binary? I know it sounds provocative, but think of the following: As
Derek Cunningham suggested, the extras could be turned off in
.blackboxrc. So this extra code would never be executed by those who
don't want it. If your OS has some kind of load-on-demand paging, the
code will not even be loaded in RAM. Then the only ressource you are
waisting is *virtual* memory. Can this have any impact on the
performance of your system? I'm not an expert on how paging works, so I
don't have a clear answer to this question. I hope someone on the list
can give some insight on this point.
The next option is to make the extras compile-time options. I know this
is a solution to the initial problem, but I personally dislike the idea
of having each user compile their own binary in their home directory. It
is not user-friendly nor disk-space-friendly.
Another approach would be to have the extras compiled as dynamically
loadable modules, just the way PAM or Apache work. This way an unused
feature would not even eat virtual memory. This sounds appealing to me,
but it is just a very wild suggestion. I have no idea of how
(im)practical it would be to implement loadable modules. Any comments
on this?
As for the last option, namely to keep things in separate applications,
I think packaging everything in a single rpm/deb/tgz is a good idea. I
know this is still a waste of ressources for those who don't want them,
but I really think it's a very minor one. We are talking of less than
a MB of *disk* space, which is a loooot chaper than RAM.
Regards,
Edgar.
--
Edgar Bonet Tel : +1 607 255-9349
LASSP -- Cornell University Fax : +1 607 255-6428
Clark Hall e-mail : [EMAIL PROTECTED]
Ithaca, NY 14853, USA web : www.edgar-bonet.org
