<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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. <br>
<br>
-Don<br>
<br>
<a class="moz-txt-link-freetext" href="http://xarg.net/blog/one-entry?entry_id=20005">http://xarg.net/blog/one-entry?entry_id=20005</a><br>
<a class="moz-txt-link-freetext" href="http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers">http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers</a><br>
<br>
Word of the day: Bikeshedding<br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<a class="moz-txt-link-freetext" href="http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers">http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers</a><br>
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:<br>
<br>
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. <br>
<br>
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).<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.bikeshed.com/">http://www.bikeshed.com/</a><br>
Why Should I Care What Color the Bikeshed Is?<br>
<br>
"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."<br>
<br>
<br>
Guylhem Aznar wrote:
<blockquote
cite="mid:9cc82a4d0708170231kde324d2pce0c8469c611cf7@mail.gmail.com"
type="cite">
<pre wrap="">Hello,
On 8/17/07, Walter Bender <a class="moz-txt-link-rfc2396E" href="mailto:walter.bender@gmail.com"><walter.bender@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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
<a class="moz-txt-link-abbreviated" href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.laptop.org/listinfo/devel">http://lists.laptop.org/listinfo/devel</a>
</pre>
</blockquote>
<br>
</body>
</html>