Sean McNeil wrote: > This is an area I have a strong opinion about... As do I.
> IMHO, OLPC is doing the right thing here as an application. The kernel > provides functionality and does things at a very low level. You do not > want it to be providing any utilitarian functionality. Theoretically, I agree. > I would disagree > that there is compromise necessary. Sure, one can have debug code that > turns on the display coming out of sleep, but a release should do the > right thing and leave the display in exactly the same condition it was > in when it entered suspend. Ok, but you *DO* agree that there is a compromise necessary. I'm asking for nothing more than *EXACTLY* what you are suggesting here -- while this kernel and this hardware is in its current state, we need to make a compromise on these principles of purity, etc. and do the right thing for the user. That's all I'm asking for! > This is the same reasoning I don't want any of the LEDs to be doing > utilitarian things like being changed when external power is > applied/removed - the kernel is not an application. I would be surprised > if application capabilities such as these manage to make it upstream > into the main kernel tree. !!! Upstream??!!!!! (Ok, I went outside and screamed. I feel better now.) Now a general rant on this myopic focus on upstream, aimed at nobody in particular, and the entire OM development team specifically: Users care that it works, and care nothing for things like elegance of algorithm, or ability to push upstream. As such there will be constant friction; development for the sake of elegance and purity is a thing of beauty, a wonderful art-form. But it's been my experience that users seldom pay for "art" and "purity" and "elegance" if the device fails to deliver, reliably, on its primary purpose. People pay for results, not elegance, especially when they can't see the elegance and beauty of the code when it's in binary form in flash anyway. So, the OM thinking on this issue and on so many we've discussed in the past is that code should always be Pure, and Elegant, and it should always do what is "The Right Thing To Do(tm)" -- in this case, not turn on the backlight in the kernel. Agreed - at least I do agree that's the elegant thing to do. And also agreed is that to do otherwise will cause the code not go upstream. But to continue to pick on this single example we are discussing now, do any of you appreciate what sort of response you'll get from the user who has a non-responsive device with a blank screen in their hand? Will you explain to him that the code leaving the screen dark is not only deliberate, it is considered a thing of beauty, a bit of elegance in programming, and then will you inquire if the user is delighted to know that this code that left his display dark and his device undiagnosable, that bit of code was accepted upstream and will be part of the Linux kernel in the future? Hurray! I'm quite certain the user of that defunct device will be absolutely delighted to hear about that; this knowledge cannot fail to soothe any frustrations the user may have over the complete inability to determine what failed and the true state of the device with the dark display in his hand. I'm reminded of Douglas Adam's bit (somewhere in the "Hitchhiker's Guide to the Galaxy" trilogy) about the spaceship with the black indicators on the black instrument panel lighting up black -- I'm sure he would find it deliciously ironic that here we are, actually implementing that! Ok, enough said. The community will maintain a patch to make sure that we can read the display when the thing crashes. Once the device ultimately makes it to the point where it becomes commonplace for the GTA02 to operate for 21 days as a normal cell phone without crashing or failing to come out of resume, then we can remove the patch to keep the backlight on, and ultimately elegance will win the day -- at least elegance will win the day once the device first delivers on the promise of being somewhat reliable. :-) Carry on, and code elegantly! Regards, Mike (mwester)
