WSJ

[Bernardo Innocenti]

Mike C. Fletcher wrote:

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

I hear on #olpc that Dennis Gilmore is going to make Sugar a
desktop option for Fedora along with KDE and Gnome.

Joel Stanley said that Sugar is already available for Ubuntu too,
but I didn't have a chance to try it out yet.

So you just install one of these distros and then do the additional
customizations you need.  Seems easy, doesn't it?  Well, it's still
a lot of work if you care to give your users a good experience.


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

Yes.  I can't get involved at this time, but 'm willing to accept
patches for the packages I maintain.


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

Yeah, most of the work will probably involve fixing hard-coded paths,
resolutions, and other incorrect expectations we made in the various
activities.

>From what I remember of that code, I'm pretty confident about the
Sugar core being quite sensible already.


> "Traditional" Activities/Applications Needed:
> 
>     * Vector Graphics (Inkscape)

I remember one of the authors of Inkskape saying that he'd be
interesting in sugarizing it.

But, as useful as Inkscape may be for general users, I'm not
sure if such advanced vector drawing would be appropriate for
primary school kids.  Maybe paint is all they need.


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

Again, useful applications for us, not that much for an
8 years old.

Note that I'm intentionally avoiding to say "not at all useful".
I'm usre a few geeky kids may like the CAD or even an IDE.
I used to be like that :-)

There's certainly some need for these advanced applications, but
not as much as there's still need for better educational
software bundled with the laptop.  If we have spare time, we
should try to improve these.


>     * Science (choose any discipline) (KStars, PyMOL, ?)

These would be great to have!  I'd add Kaltium to the list.




> We know our users *are* interested in the finance and spreadsheet
> applications (the pilot program in Nepal explicitly asked for them). 

Really?  I'm very surprised, but if there's really strong demand,
then I'll withdraw all my previous statements.

I'd be willing to accept that parents and teachers want to use
their kid's laptops for other purposes.  And maybe we should spend
a little (little!) of our time trying to support them too.

I guess in some countries we're deploying to, we can't just say
"parents should just buy a normal laptop for themselves".

But I seem to remember that making the XO explicitly a child-only machine
was an intentional design goal tailored at removing the motivation for
an adult of stealing the laptop from a child.


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

Yes, I'd like that too.  Why on steroids?  The XDG specification should
be generic enough for Sugar to implemnet as-is.


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

Sounds like too much trouble for too little success rate.

Letting the kids install random packages downloaded from the
Internet is also not an option.

On the other hand, lots of software out there is fully relocatable.
It's just a bunch of binaries, some libraries and some data files,
usually icons.

So if you reconstruct the usual UNIX tree inside an activity bundle,
(you know, bin, lib and share), and set paths correctly, many
applications would just run.

So a basic rpm2xo converter would just unpack the files and move them
to these directories and add a wrapper shell script to do invoke the
main application.


> [...rewrite sugar widgets in C...]
> 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.

Let me know if you do.  Torello may also start working on
it sometime later if he finds the time.


> It's a cultural thing and it *is* going to happen.
> [...]

Very good to know...  Looking fwd to see your report!

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