WSJ

[Mike C. Fletcher]

Edward Cherlin wrote:
> On Nov 25, 2007 10:57 PM, Albert Cahalan <acahalan at gmail.com> wrote:
>   
>> Mike C. Fletcher writes:
>>
>>     
>>> If we are serious in our goal of educating children, we need to do a
>>> few things, and some of this requires a readjustment and a
>>> detachment from the question of which hardware goes where.  Does the
>>> hardware matter?
>>>       
>> Yes.
>>     
>
> Yes, the low power consumption, wireless mesh networking, camera and
> microphone, and non-toxic construction matter. The known set of ports
> matters. Knowing exactly how much memory is available matters for some
> purposes.
>
> But those are all nice-to-haves, compared with being able to run the
> software at all. We can already run a nice subset of the laptop
> software from a Live CD on almost any x86 computer, including Macs. It
> would not take much effort to create a new ISO file with an up-to-date
> image.
>   
A closed platform has some advantages.  The fact is, though, that we no
longer have a closed platform.  There *will* be Classmates and EEEs out
in the field.  Children should *not* be blocked from our educational
content just because they got the "wrong kind" of computer[1].  Despite
the special hardware, most of the XO is pretty much bog standard at the
coding level.  It's an i586 class processor with a web cam accessed via
v4l and a microphone.  It has a very high resolution screen (which
requires a bit of special coding, but the emulators can run at 72 dpi
already with a small hack).  It has some game buttons, we need to
support those, but they're mapped to extended keyboard keys by default
anyway.

Resource compression ratios and fixed screen-sizing are fine, but to
reach a few million extra kids it's probably worth re-running the
converter and doing a bit of testing on the screen layout.  The most
difficult changes to adapt to are probably in the aggressive suspend
stuff.  Most machines are going to go nuts if the OS tries to suspend
and resume them every fraction of a second... so we might have to use a
less aggressive suspend... maybe set an integer somewhere... and then as
the other machines get aggressive-suspend kernels and test them, we can
ratchet down the number for them too.
>> Standardized hardware means I can count on having things, and I
>> can optimize. There is a microphone. There is an input that can
>> measure DC voltage levels. There is a camera that does 640x480.
>> The side of the camera with the user's face is quite predictable.
>> There are 3DNow! instructions. JPEG compression levels can be
>> made appropriate to the display. Images can be in ideal sizes.
>> The kernel and X server don't need to ship a zillion drivers.
>> The control panel can be managable.
>>     
Again, for a few million children, it's probably worth porting to
another machine.  It becomes 3 set hardware platforms instead of 1.  It
requires resources that we're short on, no question, but it isn't a
project on the order of a new OS, it's a project on the order of a few
weeks of a guru Fedora sysadmin to figure out what's needed and compile
and package that.
>>> we should port to the other inexpensive laptops, if a country
>>> decides to go with EEEs or Classmates, we should be in there
>>> offering an EEE or Classmate-optimised Sugar + Activities +
>>> Content that they can load onto those machines
>>>       
>> This is a mixed bag. It dilutes the message.
>>     
>
> The message is already diluted, or perhaps polluted. Intel and
> Microsoft have seen to that. It is vital that XO software run
> unaltered but with fewer features on alternate computers that lack
> some of its hardware. Then the fact that free software that runs on
> their machines is actually better on our cheaper XO laptop is a major
> market advantage.
>   
The XO is iconic, and it is powerful as a delivery mechanism for the
message of making education available to the underprivileged children
around the world.  But in the same way as the crank was iconic, and was
a powerful delivery mechanism for the message, the XO is just part of
the message.  The XO is already "winning" the battle to get inexpensive
computers to the forefront of manufacturers' minds.  In doing so, it has
convinced those manufacturers to build their own machines.

We should not be so tied up in a single "message" (particularly one
about selling laptops) that we subvert our own goals.  There is
something like 50% of the world without reliable power, and the XO was
designed for that 50% of the world.  The fact is that none of the other
manufacturers are going for that 50% yet.  There's plenty of room in the
pool.  For the other 50%, a Classmate or an EEE might be the choice of
their government.  If we abandon those children's education on the alter
of the purity of our message, what are we really about?

    "It's an education project, not a laptop project."

That is our proper message.  It's right there on the "about" page.  It's
the message we should be unwilling to subvert.

    "Choose a laptop model, we have one that is designed for this kind
    of deployment and is available at cost, but there are others if you
    prefer.  Have the manufacturer flash this image on them.  Work on
    your curriculum and deployment plans (here are samples and here are
    experts who will work with you if you like).  Set up your
    country-level infrastructure (here are sample specifications if you
    like)."

We help give children access to the social and intellectual resources of
the world by making computers act as educational tools.  We help educate
children.
>>> we need to make use on multi-user machines easy, where Sugar
>>> is just a desktop manager session that is run just as one
>>> would run KDE or Gnome (so that computing lab situations can
>>> let children use Sugar's safe, rich  without giving up the
>>> ability to run KDE/Gnome)
>>>       
>> Activities which don't need special XO hardware features
>> should just run, right from the GNOME menu, without anything
>> extra. Activity authors should have an easy way to specify
>> if this means full-screen or 1200x900 in a window.
>>     
>
> We have Gnome on the Live CD now. What prevents us from installing it on XOs?
>   
This is *not* the thrust of my suggestion, rather, I want Sugar running
on *other* machines, machines such as those found in thin-client labs
(and other inexpensive laptops).  I rather like the Sugar desktop as an
environment for 7-11 year olds, it's reasonably simple and very
elegantly designed.  It is also currently the only place that many of
our activities will run.  We want Sugar to run *everywhere* if possible.
>> The ultimate goal should be to have activity isolation be a
>> normal part of the business desktop. Sugar can melt away as
>> the ideas get put into regular software.
>>     
Certainly, but for today and tomorrow, there's still a lot of stuff that
the regular desktop just doesn't have and which will prevent our
activities from running outside Sugar.
>>> For the other countries, we need to address their concerns.  It
>>> seems that at least some of the concern is because we have
>>> introduced a huge barrier to entry for application porting.  That
>>> means we have a pool of dozens of applications instead of hundreds
>>> or thousands of activities/applications.  Even compared to other
>>> Linux-based solutions, we have a tiny pool of available
>>> applications, many of which are still in reasonably early stages of
>>> development.  We are missing whole classes of application/activity.
>>>       
>
> It's much easier than Debian packaging of apps that come out first in
> RPMs. We could organize a bunch of schoolchildren to do it for
> hundreds or thousands of apps. We could probably automate most of the
> process.
>   
I'll have to take your word for it.  I haven't yet seen an elegant
method for such packaging that produces a launch icon and doesn't
require arcane command-line operations to install or run the activity. 
I am *really* interested in this, though I have to confess I've been
working elsewhere and may have missed a simple recipe showing up.  I
just spent three hours yesterday trying to get it to work with the
overlay system as originally described in Bitfrost and had no luck.  I
realise we can use RPM to install, but to create a re-installable
package that we can share with other users, that creates an icon, that
doesn't require futzing about on the file-system level... it has as of
yet eluded me.

Please, share.
>> I feel like such a conspiracy theorist here, but...
>>
>> The thought that has always come to my mind is "Python cabal".
>> At times it feels like things are maliciously non-standard,
>> as if intended to exclude normal Linux software.
>>     
It's those darn Python programmers.  Kill them a.... oh, wait.  I would
suggest that it has been more the siren call of thinking of the platform
as a closed "embedded-style" platform where backwards compatibility is
considered of secondary importance.  When you start from that position
it's fairly predictable that you will come up with something (slightly)
non-backwards-compatible.  There has (luckily) been a strong
countervailing force in the project that has tried to push *the
technologies* into the underlying desktop OS, so most of the
compatibility issues are way up at the "desktop shell" level.  The
desktop shell being in a fairly flexible high-level language it should
be possible to (and is, from my understanding a current project to) add
support code to let those X applications run with a bit of magic.
> We need to get that Sugarizing code for non-Python apps like Etoys
> onto a Wiki page.
>   
Indeed!
>> A simple xterm should work, no matter if it is started from
>> the console or if it is on a separate machine with $DISPLAY set.
>> Switching to and from the xterm should work perfectly. The icon
>> and title should be used for the donut display.
>>     
>
> I'm sorry, what's wrong with the current standard console and
> Developer's Console? All it takes is Ctl+Alt+F1 or Alt+0.
>   
I think he was using it as an example of a "dirt simple X application",
rather than as a *particularly* needed application.  Taking the icon and
title from the X icon and title has (I think) already been added (would
have to ask about that), but the installation and specification of the
activity so that it shows up in the launch bar doesn't AFAIK work yet.
>> Shipping full-screen programs does not mean that the window
>> manager should be incapable of handling anything else. It may
>> be good for the window manager to automatically attempt to
>> size a window to fill the screen, but the window manager needs
>> to handle the case when that doesn't work.
>>     
Yeah, I'd agree on that one, despite the fact that I personally *always*
work full-screen on everything.  Excluding applications just because
they want e.g. two top-level overlapping windows seems arbitrarily
restrictive.  Probably too late to change that one, I'm guessing.  In
the grand scheme of things it's probably not a huge issue compared to
the application/activity count in total.
>>> * we need some way for a regular, non-Sugar-fied application to
>>>   be installed (easily) and run (with reasonable support) on a
>>>   Sugar desktop.  We should at least have the application-depth
>>>   of a *Linux* desktop available to our students.
>>>       o Even if they don't integrate nicely and they have file
>>>         dialogues instead of Journal dialogues (so you'll have
>>>         to switch to the Journal and add the file manually)...
>>>         practicality beats purity
>>>       
>> Hack every common toolkit. Shared libraries are great.
>> If you change the toolkit library, you get journal support.
>>     
If I'm recalling correctly, that was the original design spec for
Bitfrost's minimally invasive support level.  Not sure if it got
abandoned, pushed back, or reconsidered.

Have fun,
Mike

[1] Companies which want to sell hardware haven't got the kind of
massive content and software development project we have.  If we don't
make our results as widely available as possible, then the children
using those machines will be stuck with edutainment software and a
pot-luck of random content that can be thrown together.

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com