Power manager specification... (request for comments).

[Don Hopkins]

You have to remember that the kids using these machines might not yet 
know how to read, so just popping up a notice with a paragraph 
explaining the situation and Yes/No buttons isn't an ideal solution.

    -Don

http://xarg.net/blog/one-entry?entry_id=20005
http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers

Word of the day: Bikeshedding

I saw this word somewhere and did not know what it meant. It turns out 
to be an excellent word for describing a lot of what goes on in online 
communities.

It comes from Parkinson's Law by C. Northcoate Parkinson. He describes 
how a planning board will approve spending millions of dollars to build 
an atomic power plant but if you go to them to get approval to build a 
bike shed they will argue endlessly. The problem being that the atomic 
power plant is so large, complex, and difficult to understand that no 
one can really argue about how exactly it is done. On the other hand, 
everyone knows what goes into a building a bike shed and so everyone 
feels qualified to argue about the details.

For some reason, technical discussions seem to be particularly 
susceptible to bikeshedding. There was a great post by Poul-Henning Kamp 
on the freebsd-hackers list:
http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers
which describes a particularly virulent attack they had on their list 
and submits a plea to avoid it in the future. I think just writing the 
code is a good antidote to engaging in the arguments in the first place. 
If the functionality is straightforward and easy to implement then just 
do it rather than argue about it. Most of the people spending their time 
arguing probably have enough inertia that they are not going to write 
any code and consequently, if you do have the initiative, the code 
itself is the most suitable response. As Poul-Henning Kamp said:

    I wish we could reduce the amount of noise in our lists and I wish 
we could let people build a bike shed every so often, and I don't really 
care what colour they paint it.

Who knows, if you write enough code we might even end up with an atomic 
power plant (or for you greens in the audience, a lovely old growth forest).

http://www.bikeshed.com/
Why Should I Care What Color the Bikeshed Is?

"The really, really short answer is that you should not. The somewhat 
longer answer is that just because you are capable of building a 
bikeshed does not mean you should stop others from building one just 
because you do not like the color they plan to paint it. This is a 
metaphor indicating that you need not argue about every little feature 
just because you know enough to do so. Some people have commented that 
the amount of noise generated by a change is inversely proportional to 
the complexity of the change."


Guylhem Aznar wrote:
> Hello,
>
> On 8/17/07, Walter Bender <walter.bender at gmail.com> wrote:
>   
>> Lets please be careful not to over-engineer. While Mike makes good
>> points, we have this wonderful human social network we can depend upon
>> as well. E.g., If I am downloading something from your machine, I can
>> ask you to hold on a second until I finish. Let's take advantage of
>> the fact that the kids are in the same community/school most of the
>> time and not worry so much about corner cases until we have some more
>> breathing room.
>>     
>
> Yet thinking before implementing can easily overcome future problems.
> I believethe idea of "inibitors" for the various power schemes should
> not be overlooked since their benefits can be important.
>
> In your example, a download activity could make the suspend wait an
> additional minute or two, explaining the user than its request was
> noticed, won't happen until the download/upload is over, unless it is
> overriden.
>
> If people are in the same class, of course, but what if the person is
> several hops away on the mesh network?
>
> Moreover, this interesting idea could also be applied to video
> playback/screen rotation requests, explaining that the screen can't be
> rotated or the playback will stop, etc.
>
> There's a great potential in such examples to go beyond the
> traditionnal power management done in GNU/linux.
>
> But anyway, if you think these cases are so special and supporting
> them will take too much time, write a quick shell script to test the
> concepts, play with it, and see if it helps you or if it's just a
> waste of cpu cycles.
>
> PS I have some more suggestions (ex: a maximal suspend mode to carry
> the machine without using it)  but on a computer I don't have here - I
> will post a message a little bit later.
>
>
> Guylhem
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20070817/fa804e50/attachment.html>