WSJ

[Bernardo Innocenti]

On 11/25/07 18:58, Mike C. Fletcher wrote:

>         * 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
>               o we should also port to the thin-client-style setups seen
>                 in e.g. Canonical's deployments of computing labs in the
>                 developing world

That would be a good idea, but we clearly lack internal resources.

All the code is out there and I bet everybody in the Sugar team
would be glad to help whoever wants to port it to the Classmate
or any other laptop.

For me, every Sugar installation helps spreading the constructionist
educational model of OLPC.  As Negroponte says, our goal is not
selling laptops.


>         * 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)

AFAIK, both the mainstream desktops were far too bloated to
be usable on the XO.  I can easily believe it, as the latest
versions are almost unusable on my 1GHz iBook G4, too.

Porting Gnome or KDE to the laptop would require help from the
respective teams to further optimize them and stripping down
some advanced features and some configurability.


>         * we need to get our installation requirements on non-Fedora
>           Linux down to a package-level installation
>               o (and have this be supported and maintained (preferably
>                 internally))
>               o (also very useful for encouraging developers)

I wonder what's the status of Debian and Ubuntu for running
on the OLPC.  Once the platform part works well out of the
box, installing sugar should be just a matter of using alien.

At this point, not even Fedora officially supports the OLPC
out of the box!  I'd like to see our kernel and platform bits
go upstream and appear in all mainstream Linux distros.

Even if we cannot afford to put resources on this, I'm sure
the core developers would be glad to answer questions on IRC
and on this list.


>     If we are serious about educating children, and we truly believe
>     that the software and content we are creating is key to allowing
>     children to learn well, then we need to make that software and
>     content available for all of the projects that are sending computers
>     out in the service of educating children.

I couldn't agree more on the general principle, but operating systems
and desktops are just a small subset of "educational content", and
not even a very interesting one for teaching to little children.

We shouldn't let ourselves (as OLPC) get distracted in porting
20 different Linux distros to the laptop when we're missing
a good astronomy and chemisrtry activity.

The same goes with programming languages: we concentrated on
shipping a good Python environment because it's good enough
for our educational purpose, but we're of course not opposed
if people want to make any other language available for the
laptop and use it to write new activities.

In fact, we help where we can.  I have a friend who is porting
a game written in C# to the XO, and the Sugar developers have
been very helpful.


>     We need to see ourselves, and communicate our vision of, being an
>     educational project which is trying to grant access to children. 
>     Selling our particular hardware is useful because it has a few
>     features that make it uniquely suited to many areas, but we need to
>     expand our vision to achieve the goal IMO.

Again, I totally agree.


> Standardisation and Application Availability:
> [...]

As much as I appreciate software diversity and the network
effect it enables, I'm not convinced there's much educational
value in providing the full range of Fedora (or Debian) packages.

Our target audience is, for the most part, really not
interested in traditional GUI applications and even less in
UNIX command line tools.

I'm not saying we should be actively prevent them from
installing TeX if they want to.  In fact, I believe you can
just type "yum install tetex", wait a few hours, and...
presto!  yum crashes :-)

Seriously, my point is that we shouldn't push too much
in this direction because we run the risk of loosing
focus on the real educational software we need.


>         * 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

I believe the main issue is matchbox acting strange... In the latest
OLPC News issue, I read that Marco has been working on improving it.

I also think we should stop requiring applications to register on
DBus or set fancy window properties in order to apper on the activity
donut.

Gnome and KDE long ago settled on Freedesktop standards such as
for startup-notification, and so shall we.  But I may be ignoring
something obvious, because the Sugar hackers certainly know these
things much better than me.


>         * we need mechanisms that allow application developers to
>           quickly package an existing application as an activity
>               o without a recompile (i.e. from an rpm or the like, just
>                 with some external metadata describing the activity's
>                 operation)

Indeed.  We have an xo -> rpm converter.  I wonder if doing the
opposite would be feasible, at least for simple cases.


>               o with only a recompile to get basic Journal-triggering
>                 functionality (i.e. just substituting GTKFileDialogue
>                 with GTKJournalTriggeringFileDialogue)

That would be hard...


>               o with just a few code changes (i.e. replacing menus with
>                 sugar-style tabbed toolbar-menus and the like)

My C# friend wanted to rewrite the Sugar-specific GTK widgets from
Python to C, so they'd be available to all activities, regardless
of the language.

I think he lacks time for this project, would anyone volunteer to
do it?


> Maintenance and Support:
> [...]

I 100% agree with you here too.


> Teacher Training:
> [...]

The problem with stating "children will learn faster than
teachers, and then teach their teachers and parents"
is not that it is not true.

The problem is that it *is* true.  And I can see how some
teachers may naturally oppose an educational model that makes
them feel obsolete or at least less central than they used to be.

I don't know how one is supposed to address this kind of
resistance, nor how big of an issue it may become.
It may very well be that I had only very close-minded and
conservative teachers in my schools :-)

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/