WSJ

[Mike C. Fletcher]

Bernardo Innocenti wrote:
> 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.
Yup.
> 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.
Which is where I come in, I suppose.  I need to find someone who wants
to do the port.  Ellis has suggested they're willing to donate an EEE
and maybe even do some "load it and see if it runs" tests for us once we
produce an image for them.  I just need to find some Fedora Guru who
wants to help change the world to do the work.  I unfortunately don't
know all that many Fedora Gurus (just one, actually, and he's already
working on the project).  If people know a sysadmin Fedora Guru who they
think would be interested, let me know.
...
> 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.
I seem to have confused a lot of people on that point, I was referring
to running Sugar on other machines that normally run Gnome/KDE, not
running Gnome/KDE on the XO.
>
>>         * 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.
Debian and Ubuntu are the farthest along here AFAIK.  They have
packages.  The packages don't seem to like living alongside a jhbuild
installation (hosed my laptop when I tried that), but they seemed to run
the packaged apps fine.  I need a few days I don't have to sit down and
test that further.
> 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.
Yes, again, we need sysadmin-guru people to do this kind of work.  We
need to see supporting such people as important, but the core team is
likely too busy to do much work on it.
>
>>     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.
I'm not suggesting that we need to core developers to do this work.  For
any given Linux distribution, porting should be just a matter of getting
someone from the distro who is interested in porting.  Most of the work
will be quite mechanical I would think, just a matter of figuring out
how your distribution deals with SRPMs as foreign packages and using
those to build your native packages.  Then all the fun of conflict
negotiation and the like, of course.

What we might need from the Core devs is a way to kick off a Sugar
session as a desktop shell from GDM/KDM/XDM (i.e. the multi-user stuff),
and some thought on whether running in a multi-user environment is going
to cause problems somewhere.  I don't know the mechanics of that
interaction all that well, but I'm guessing it's a pretty trivial amount
of code in the core.

>> 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.
"Traditional" Activities/Applications Needed:

    * Vector Graphics (Inkscape)
    * (Full-featured) Raster Graphics (Gimp-class)
    * CAD Software (PythonCAD?)
    * Personal Finance (budgets, running farms/shops) (GNUCash? or
      LedgerSMB?)
    * Spreadsheets (Gnumeric?)
    * IDEs/Dev Tools (Eric? Boa Constructor? Glade?  SciTE? MIT's Java
      Tinker-toys?)
    * Science (choose any discipline) (KStars, PyMOL, ?)

Yes, we will need to write new software for some things, but there's way
too much to be written to a professional level in the next month or six
AFAICS.  There's no reason to duplicate Inkscape or the GIMP (though we
quite likely *eventually* want to fix their interfaces to be
reasonable).  There are pre-existing applications of various levels of
development for *lots* of activity/application classes with quite
reasonable roles in an educational context.  They often represent years
of work.  Being able to run them allows the children to use the tool
today.  I'm not here talking about TexTex or Emacs or what have you. 
I'm talking about straightforward GUI applications that have been
designed to be used by end-users.

We know our users *are* interested in the finance and spreadsheet
applications (the pilot program in Nepal explicitly asked for them). 
CAD, Vector and Raster graphics programs are strongly constructivist
(expression/creation) tools, as are IDEs in a different way.  Science
programs also tend to be exploratory in nature.
>
>>         * 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.
It would certainly be nice if we could at least use them as a fallback. 
But I'm afraid I too am somewhat ignorant of the issues surrounding it. 
My dream is that with just a description file (think a .desktop file on
steroids) we could have Sugar run any regular Linux GUI application
(unmodified code) which is packaged in some way.
> Indeed.  We have an xo -> rpm converter.  I wonder if doing the
> opposite would be feasible, at least for simple cases.
AFAICT you need an overlay system to make this work with the
whole-system-image operations.  That is, you need to be able to isolate
the effects of the RPM to a directory that isn't part of the system
image, which means AFAICT you need to use an overlay.  You might be able
to convince some software to work in a directory with "root" setting,
but it wouldn't be universal.
>
>>               o with only a recompile to get basic Journal-triggering
>>                 functionality (i.e. just substituting GTKFileDialogue
>>                 with GTKJournalTriggeringFileDialogue)
>
> That would be hard...
Indeed, I'm hoping some super-elite GTK hacker wants the challenge :) .
>
>
>>               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?
Don't know, sounds like a job a second or third year comp sci student
could tackle.  I might be able to scare up one of those at some point.
>
>> 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 :-)
It's a cultural thing and it *is* going to happen.  Teacher training
must allow teachers to know enough to save face in many cultures.  We
all understand that young children will surpass their teachers in many
cases.  Teachers understand that.  What they need is to show competence
and familiarity.

They also need to be able to use the machine's capabilities to enhance
the educational experience.  They are giving their students access to a
huge body of knowledge, and no human on the planet knows everything, so
it is to be expected that the students will find corners the teacher
does not know.  Teacher training must include the idea that students
will have that universal access, and that there will often be new things
that the student discovers.  Teachers will need to be guided on how to
incorporate those ideas as they bubble up.  Again, we've had at least 2
schools where this has been done, we need to document what was covered
and how this message (among others) was communicated and received by the
teachers.

Enjoy yourself,
Mike

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