[sugar] First impressions of a B4 machine

[Dan Williams]

On Mon, 2007-07-23 at 06:29 +0100, Ivo Emanuel Gon?alves wrote:
> Hello Sugar and Devel lists,
> 
> I finally got my hands on a B4 machine, which I will be using for Xiph
> compatibility tests, among other things.
> 
> However, I got so many things to say about the system presently that I
> might as well just post a First Impressions thread.  Hopefully, some
> of my points will be considered to improve the XO laptop.
> 
> The first thing I noticed is how tiny the laptop is.  I'm really
> enjoying the hardware, and I believe it's a real killer combination
> for a durable and powerful machine for children.  The laptop is
> perhaps too heavy for a child, though.  I can notice the weight, so I
> imagine how a badly nourished child will deal with the weight by
> him/herself, perhaps for 1 or 2 km's to the nearest school.  Maybe the
> components will be more and more miniaturized in following versions?
> It's still a valid concern.

One question; did you get a NiMH or a LiFePo4 battery?  LiFePo4 have
"Battery Sample" written on them.  They are quite a bit lighter than the
NiMH ones.

> Speaking of the components, I have a few environmental concerns, but I
> think I will save them for a future thread.
> 
> Being able to rotate the display of a screen that can already rotate
> 360? is pretty useful, not to mention awesome.  Congrats to whoever
> designed the system.
> 
> Booting XO was fast for a Linux system, but very likely not fast
> enough for a child expecting it to turn on immediately.  I guess it
> can't be helped.  What could be done, however, is hide the diagnostic
> dialogs with a simple splash screen stating POWERING ON, or LOADING,
> or whatever.  It's cute and would not confuse the children.  I mean,
> we don't want them to think: "Hey, what's all this alien garbage on
> the screen?", instead of paying attention to class.

They will have a boot splash screen, just haven't gotten there yet.  We
also haven't put the time into optimizing startup time, because it's
pretty low-hanging fruit and fairly easy to do.  There are more pressing
things right now (getting the networking/sharing to work for example)
but this is something we fully intend to do.

> I have to say that Sugar looks pretty neat.  Really neat.  It's simple
> to understand, efficient, and easy to use.  What's not so obvious is
> that you have to push the square button on the top right to be able to
> go back to Sugar after loading a program.  Took me a while to figure
> that out.  It's a no-brainer afterwards, though.
> 
> I don't understand why the XO asks for my name after I turned it on
> for the first time, as it has never greeted me by my name since, nor
> does it seem that my name has any importance for school work.  It
> doesn't even show up on the /home folder.  I suppose this may change
> in the future of the XO development, but right now it makes no sense
> to be there.  I have really seen no point to the color switcher of the
> XO logo, either.  It seems my "version" of the XO logo stays in
> Sugar's background, but otherwise seems to have no other use.  It
> doesn't seem we may switch the color afterwards, either.  Useless
> distraction.

These are both so that other children on the mesh can recognize you.
You probably have build 406.15 on the machine, you probably want to
update to something in the 500-series, which has a lot more of the
network capabilities.  Each child is represented by a color combination
and a nickname.  If you work on documents together, you'll see the XO
icons of the other children you worked on it with.  If you look in the
Mesh View, you'd see other XOs that yours can see, represented by the XO
icon in that child's colors.  The roll-over contains the child's
nickname.

> Before going over the software choice, may I question why the choice
> for Fedora?  Yes, I understand the OLPC has some kind of agreement
> with Red Hat, and it's all fine and well, but Fedora is known for its
> "bloatness".  Why not look into smaller and more XO-adequated distros
> like Damn Small and similar?  Is it because of SELinux?  SELinux may
> be put on any distro.

We haven't yet put a lot of work into slimming down the distribution,
but this is tradeoff between taking stuff out and forward maintenance.
Slimdown is someting that'll start happening soon.

> One of the big issues I have found so far should be easy to solve.
> And that's the file system.  Pretty much every program under the XO
> with an Open/Save File dialog displays the entire mess that is the

There actually aren't going to be open/save dialogs, and they are no
longer there in the current builds.  You might want to reflash with a
development image to see what the current state of the Journal is.

> Linux filesystem.  Are children supposed to even see that?  Why not
> use a .hidden file?  Most GTK and Qt applications that I know of obey
> its rules and hide every file marked that shouldn't be seen.  And that
> kind of behavior makes sense.  They should only see /home and /media
> -- maybe not even those two; I have a better suggestion further below.
> 
> Let's go over the programs, shall we?
> 
> Paint, is this the famous Tux Paint?  I have heard that it is a very
> neat drawing app for kids, but what I saw so far was an Open/Save
> interface more awful than the one used by the other porgrams.  What
> the Niflheim where the developers thinking?  It doesn't make any sense
> for the children.  Heck, it doesn't make any sense to me.  Somoene,
> please fix it.

This has been replaced by a different program in recent builds.

> One of the export options allows one to save the work as a ICO file.
> ICO file?  Where, but where in the world are the children going to use
> the Microsoft Windows Icon format?  It's better to remove this
> "feature" for the sake of taking out clutter.
> 
> Editing large images in Paint is a nightmare since the direction keys
> are of no help and the Sugar scrollbars are so thin they are almost
> invisible.  The thin scrollbars are a good idea, so I suggest instead
> to make the direction keys work to scroll through the image.
> 
> I liked the e-Book reader.  Simple and efficient, especially
> considering the XO's e-book mode.

Recent builds have good rotate support and the game keys are mapped to
page up/page down, so this should work pretty well.  We still need to
roll in the power-save feature that will put the machine completely to
sleep in between your keypresses while in ebook mode, but we've had that
working for a while.  It's pretty cool, you don't even notice the
machine is in S3 sleep because the DCON keeps the display on.

> I haven't yet looked into Tam Tam.  It seems like fun.

It's awesome :)

> I have looked into Tetris, though.  Tetris?  It was a fun game back
> in, what, the 80's.  I don't think it offers much as educational tools
> go.  I believe a bit of research on what games other educational
> distros (like Edubuntu) are using may be helpful.  Look at GCompris,
> for instance.  Now those are some fun and educational activities for
> kids.  I'm not advocating the removal of Tetris, but it should be
> something to consider to replace it with something better.

There has actually been some work going into GCompris to make it work
better on the XOs.

> I have read on Wp that there's going to be a Sim City clone for XO.
> Now that would be awesome.
> 
> RSS Reader.  I don't have WiFi around here to test it, but it seems
> it's PenguinTV according to the OLPC web site.  PenguinTV is a neat
> app, but it's locked in RSS and offers no support for XSPF, which is
> an Open Media format.  I contacted its author on this matter, but he
> says he has no plans to support XSPF in the near future.  I call to
> boycott this program entirely until it does.  It's a radical approach,
> I know, but making sure the XO is powered by OM formats and not
> proprietary ones should be a top concern.
> 
> Well, the thing about free software is that someone may patch it
> before the author himself does.
> 
> Next comes the browser.  It's based on XULRunner.  I have to ask why.
> XUL is a resource-hog.  I think only Java can beat XUL on resource
> a-hungry, and even then, by little.  Do you know that Gecko-browsers
> have the slowest Javascript parsers of any other modern browser?  If
> the project insists on a Gecko browser, do take a look at Epiphany: no
> XUL!  KHTML browsers are a good alternative, too.  Any browser that
> will include support for the upcoming <video> and <audio> elements of
> HTML 5 is a good choice, anyway.

The debate was between resource usage and rendering capability.  At the
time we chose Mozilla based solutions, people felt that KHTML didn't
have the same rendering success that Mozilla did.  We may revisit the
decision at some point, depending on how the resource usage of Mozilla
works out, and whether the Gtk WebCore project keeps going forward.

> SeaMonkey, while XUL-based, is an entire Internet suite, so it may be
> another interesting choice.  Small distros like Puppy OS use it.
> 
> Next is AbiWord.  Why was it not stripped of support for most file
> formats?  Microsoft Word .doc is proprietary and should be removed,
> not to mention it's useless for children using XO -- none of their
> classmates or teachers will be using Microsoft Word.  AbiWord's own
> format should be removed because its useless for interoperability and
> ODT does a fine job by itself.  RTF?  Who uses RTF these days?  This
> is all bloat and has no point for the children.
> 
> OpenDocument should be the default format for saving new documents and
> open older ones.

I think that's the plan.

> HTML support makes sense if children will put stuff on the Web, and if
> so, HTML should be kept in its simple form, no Multipart HTML crap,
> which doesn't even work on XULRunner, anyway.  Plain text support is
> always a good idea, after all, Linux is all about editing text files
> :)  However, I have no idea what "Encoded Text" is.  Other character
> sets besides ANSI?  Useless.  It only confuses the children.
> Appropriate handling of character encodings should not force seperate
> text formats.  Actually it's not even a problem anymore with Unicode
> around.
> 
> If it could export PDF as OpenOffice does then Abi would become quite
> useful.  That's not the case, right now.  I heard there's an
> unofficial plugin to do this.  Maybe worth looking at?
> 
> Finally, there's no Media Player right now.  How will children see
> educational videos?  Or hear audio lectures?  Or analyze images
> outside of Paint?  There are plans to add something based on
> GStreamer, and that's great, but keep in mind the three aspects of
> media: video, audio, and image.  All in one place to make it easy.

http://dev.laptop.org/git.do?p=projects/jukebox-activity;a=summary

> Oh, and let me talk about the shell.  Is this really bash?  Why, oh
> why?  BusyBox is so much better suited here, especially considering
> the limitations of the XO, so why put bash here?  It's not like the XO
> will be used by bearded UNIX users and their emacs.  The shell's there
> to rescue the system in case something goes wrong, am I right?  Avoid
> clutter.  BusyBox will provide a more efficient shell for XO.
> 
> Next thing I know and someone's gonna tell me that the XO software is
> not compiled against uClibc or dietlibc. . .  It is, right?  Right?
> 
> And what's the point of /home/OLPC?  What's the point of the home
> folder at all?  I don't reckon XO allows a multiuser environment, so
> it just makes sense to create a /Documents folder of some kind.
> 
> /Documents and /Media.  Hide everything else.  Seems wise to me.
> 
> Speaking of /Media, which would be for media devices, where's the
> device manager?  How am I supposed to use a USB key?  I don't see how
> to mount one outside the shell, and the system doesn't mount it
> automatically, either.  How are children supposed to work with files
> on USB drives?  We can't expect them to know shell commands.

USB drives are integrated in later development builds than is probably
on your machine.

> Following this line of thought, a very simple file browser may be a
> good idea, too.

The Journal is the mechanism for doing this, and it's there in later
development builds.

> Bug: Anytime an Open/Save dialog shows up, the program cannot be
> closed.  This may confuse children.
> 
> Battery: Drains too fast, even while the CPU is idle and the display
> is set on B&W mode.  How long are the children supposed to have XO
> turned on?  2 hours a day?  Three?  More than that seems unlikely
> right now.  Or is it just my battery?

We're deep into power-optimization territory at this point, and it's
going pretty well.  Later builds should be much better at power
consumption.  I can pretty easily get 3 or 4 hours with the display on
and a LiFePo4 battery.

> And that's it for now.  I have to say that while I'm impressed with
> the hardware, I am not impressed with the software.  There's still
> space for a lot of improvements, although I hear the launch day is
> soon on the horizon.  Probably not a good idea, but everyone knows how
> these things tend to turn out.

Check out a later build, they're quite a bit more representative of what
the launch stuff will look like.  These are "Trial 2" candidate builds.
There will likely be a "Trial 3" release, then the final one later this
fall.

> I release this little review under Creative Commons Attribution 3.0
> License, just in case my little (read: big) rant will help improve XO.
>  Don't want Copyright to get in the way.
> 
> Before I go, does anyone know who I have to contact to get a developers key?

You don't actually need one yet...

Some good points, thanks for the input!

Cheers,
Dan