acpid

[Roberto A. Foglietta]

2008/10/12 Vladimir Dronnikov <dronnikov at gmail.com>:
> I hardly understand the logic of not having small (objsizes gives 270
> bytes) applet and having a dozens-of-Kbytes daemon even on so-called
> desktops, Roberto. Why on Earth anything other than a black box with a
> couple of leds is considered a "desktop"? And then why these desktops
> must use bloaty software?
>

 Vladimire, you wrote:

> I, of course, admit that this applet can be of limited use to be
> injected in BB tree.

 and I wrote you back _ironic_ questions about why I think ACPI event
manager it would be FULL useful in a bb tree. Whatever system we
consider from smart-phone to a very powerful workstation the problem
of managing ACPI events exists, if the HW supports ACPI standard,
obviously. I agree with you a small ACPI event manager would be very
helpful but immediately after it follows the concern about HOW much
deprecated is the /proc/acpi. Probably, as you claim, is not enough
deprecated to live without. So if deprecation is the only viable way
for now then it is my way too.


> Anytime I fell I've solved a particular problem of getting rid of a
> piece of full-blown software I try to share the experience with BB
> list. That is why I may sometimes seem way noisy :)
>

 I plan to have a lot of free time in the near future... be prepared
to read some noise from me too!
 :-)

> Some ideas deserve to be merged in BB, some don't. But the latter
> should be nevertheless placed to some BB "quarantine" repository, IMO.
> For just because we may not see the longterm fruits does not mean the
> idea should go in vain, right? I see the discussion of introducing
> libm surrogate: situation is the same... What do you think about it,
> Roberto?
>

 Until the precision (in the worst case) of libm surrogate is 4 bits,
as I found running the suggested test, instead 16 bits as the author
states there is no hope for the inclusion. Personally, I compile
statically against libm and dynamically with glibc, so I am not very
concerned about footprint at this time. I do not know enought about
ulibc to say if libm surrogate should go there. So, really, I do not
know where they belong but until they do not proof to be enough
precise, there are not any place for them: imprecise maths are like
bitter sugar, it does not exist! Once they proof to be enough good I
would like have the option to compile bb with libm surrogate instead
regular libm even without using uclib. So I guess libm belogs more to
bb than uclib.


 Bloating software with new feature is a problem and trying to keep it
simple is another problem. I think the best approach would be adding
everything and look what features really have been used and eliminate
the useless. Unfortunately we cannot count on this kind of feedback
for our selection. Even in the case of having this feedback we would
not able to remove things because "not enough many" people use it. So,
once we put something inside bb we have to maintain it for a long long
time. Under this point of view I understand why is so difficult for
anybody inserting new features. Be patient and trust in your idea, if
it is good it will prevail and will stick for a long, long, time.
 :-)


 Cheers,
-- 
/roberto