J5’s Blog

Here is a nice article to read over the holidays. It really showcases what the OLPC project is all about.

Most of the people reading my blog will have seen the Heroes actor, Masi Oka’s spot advertising the Give One Get One initiative (quick, get your’s soon as the program was extended until December 31’st).

While reading one of the Heroes interactive graphic novels (that’s comic book to everyone else) I came upon this panel. It’s from The Last Shangri-La novel at nbc.com.

BTW Last nights Heroes episode felt a bit forced owing to the writers strike going on. I wish they didn’t try to resolve this seasons plot but instead left it on a huge cliffhanger. I guess they weren’t sure what was in store for the show so they had to wrap it up somehow. Anyway, the next “chapter” as they call it looks like it will be much better since they were able to use the current season to set it all up. There were a number of characters who were side stories. Hopefully we will see how they relate when the show starts up again.

Guido just released it today.

Yesterday I tasked Dan Winship, who recently joined Red Hat on the OLPC project, with porting WebKit as a Sugar activity when he had free time. Today I came into the office to find an e-mail with a link to the activity.  Here are some screen shots.  Ignore the different scaling as we have tweaked  XULRunner to better utilize the XO’s screen.

XULRunner

WebKit

My initial reaction is it shows promise but needs some work to become really usable. On the plus side it uses on average 10 megs less in resident memory according to Dan’s testing. It also starts up five seconds faster. In my qualitative tests WebKit feels a bit more responsive when scrolling.  The biggest problem with WebKit is the gtk port is just not finished yet and as such it is not a usable browser, but it is close.

Why are we looking at WebKit?  In my mind it is another Open Source project that is just more aligned to our needs as a small and fast  browser.  The issue I see with the Mozilla comunity is that they are mainly chasing the fat desktop market.  Every effort I have seen to make an embedded focused project based off of Mozilla has fallen in one aspect or another.  WebKit’s specific claim to fame is to be small and light while not sacrificing needed functionality.  For instance the Gtk port of WebKit uses cairo and pango which we need for nice antialiased and internationalized fonts.  The last embedded mozilla project I talked to spent their time blaming cairo and pango for their performance problems.  Instead of fixing their issues they opted to pull them both which gives you a slightly faster browser with no real internationalization support to talk of.

To be fair I have heard that Mozilla upstream is fixing the issues with cairo rendering in their next major release and have been getting friendlier when dealing with Linux distributions.  This is all good signs of progress.  The question is what is the direction Mozilla is looking to the future and will it line up with our requirements for low powered computing?  Can a project as large as Mozilla serve both the embedded and power desktops equally well or do we look to other projects like WebKit which have more focused goals?  For that matter, what is to say WebKit doesn’t spiral out of control and go in directions which are unsuitable for us?

For now we are using XULRunner, which works and has many benefits along with some pitfalls.  We will keep an eye on the development of the WebKit Gtk port as it is shaping up to be a worthy contender.  In the end it will come down to which offers the best experience on our platform.

I was just reading Guido’s status update for Python 3000.  Though I have yet to go over the PEPs, his blog entry talks about some of the major changes, some of which effect the D-Bus python bindings and Sugar.  None of this is worrisome but are things we should keep an eye on while developing.

Unicode

I’m not sure if the unicode changes will help or hurt us in anyway though I will suspect they will help in that Python will be more unicode friendly.

The inclusion of mutable byte literals however will make it easier to support the array of byte type in D-Bus.  We’ve been flailing our arms on this issue and though Simon has come up with an elegant solution in recent releases, it is always nice to have support in the language itself.

Print and Formatting

Printing and formatting seems to be to be the most invasive change though I suspect the conversion tools will take care of this.

The print command now becomes an actual function so we should most likely replace all occurrences of print ‘foo’ to read print(’foo’) which will work in current python and python 3000.

Formatting will be completely different, changing from the ugly % operator to a format method on string classes.  While I do agree with the need for this change, we do use this everywhere and there will be no good way to be backwards compatible here.  This makes it a bit of a bite the bullet when we move to Python 2.6 sort of thing as Python 2.6 will support the older and newer APIs with the older ones spewing warnings.  We may just want to write a utility function for activity authors to use which will shield them from this change.

Class Decorators

I kind of wanted to have these when designing the decorator syntax for exported classes.  Instead I used metaclasses which means you have to inherit from dbus.service.Object in order to export your object over the bus.  This leads us to having to do hacks in order to support multiple inheritance such as the newly added metaclasses for exporting classes which need to inherit from GObjects.

We may wish to explore using class decorators as a more flexible way for exporting objects in the future though there are behavioral questions to work out.  For instance what do you do when an internal method such as Introspect is also implemented in the class.

Metaclasses

In the future metaclasses will be specified via a class keyword (i.e. metaclass=MyMeta) instead of setting the magic __metaclass__ variable.  D-Bus simply will have to switch over and most likely support two releases for a short while.

Method Signatures

Python is getting typed…sort of.  Methods and functions will be able to specify a type for its parameters and return value.  These are only annotations and do not have any meaning to python.  For instance:

def foobar(a: Integer, b: Sequence) -> String:
…

We can however deprecate the in and out signature keywords in D-Bus’ method and signal decorators and use this instead.

Sugar should also use this when we decide to move, to make the code clearer and allow debugging tools to have more context.

Conclusion

I’m sure there are other things that will bite us.  I’m going to keep an eye on things and as soon as the alpha comes out start running some test.  This is a long way off and with Python 2.6 giving us time to move with a migration path it is even a longer way off though at some point it will cause us pain and should be tracked to minimize the impact.

As it currently stands the Python team expects the alpha to come out some time in August with a goal of releasing Python 3.0 (which is the stable release of Python 3000) about a year later.  Some months before Python 3.0 is released, Python 2.6 will be released and will roughly be the same as Python 2.5 plus all of the new bits that will be in Python 3.0, or at least the bits that we need for a orderly migration.

It is my hope that Python 3.0 will make python much cleaner and easy to support in the long run.  If it achieves those goals then it is worth a little bit of pain in the short term.

I fixed the issue with booting under QEMU in build 486.  I have also been able to boot under VirtualBox by converting the image to a VMWare image and adding it as the primary hard drive in a VirtualBox session.  To convert you can use this qemu command:

qemu-img  convert <raw image>  -O vmdk <image name>.vmdk

VirtualBox while harder to setup than qemu (why can’t I just run VirtualBox <img>?) gives you the ability to have shared folders to make it much easier to shuffle files between the host system and Sugar.  Pretty soon I think I will use this to do development images with full gcc support.  The nice thing is I can distribute it as a VMWare image and people who are confortable using VMWare can use that and those who want an Open Source solution can use VirtualBox.  I may even play around with VirtualBox sources to make a download and run version of our images.

Now off to see some fireworks.

Slashdot posts a story about how moving from the Red Hat build systems to the Fedora build systems means that through some sort of magic, OLPC is now subject to export restrictions. Here is a hint, OLPC is a US based non-profit and as far as I know, though I am not a lawyer, OLPC is subject to US law in any case. What that says about export restrictions I don’t know - ask a laywer not Slashdot. Add the fact that it is no secret that Red Hat is the creator of the Sugar interface and that the OS is a derivative of Fedora and all you’ve got is FUD. <sarcasm>Oh no Slashdot users don’t spread FUD they only combat it</sarcasm>. The “article” gets it wrong on so many accounts and I am easily reachable via IRC or e-mail (they link to a mailing list post with my e-mail in it) that you think someone might have fact checked. So to set the record straight here is a mini FAQ:

Why did OLPC move to Fedora?

OLPC didn’t move to Fedora. Sugar, the software layer, was already being built on top of the Fedora OS within Red Hat’s build systems. With the merge of Fedora Core and Fedora Extras we felt it prudent to move the Sugar packages to the Fedora infrastructure. This lessens the burden of maintainership as we were branching a lot of packages just so we could build against them. It also gave us access to a legion of Fedora packagers, developers and translators, which has so far payed off very well in terms of quality of the packages.

What does this mean to people in the community?

It means people in the community have more ways to participate. The Red Hat build servers are accessible only to Red Hat engineers, Fedora’s are open. Go here if you want to contribute to the base OS.

What else is gained?

By not reinventing the wheel we free ourselves from having to think about infrastructure such as signing packages or hosting builds which leaves us to think about the forward moving innovative bits.

For more information you can read my post announcing the move.

ONE is a campaign to make poverty history. I found out about it through a news story on the CNN. It is a nice complement to the work I do at OLPC as it focuses on some of the more basic needs outlined by the UN Millennium Goals. What I liked about this particular effort is it is bipartisan, having picked up members from all over the political spectrum. Their One Vote ‘08 initiative is geared towards putting political pressure on all the US candidates towards focusing policy into trying to solve the issues of world poverty. This is a much better strategy than backing one horse in the race and brings change through unity and not division. I’ve signed the declaration, joined the facebook group, and offered to help and am now seeing if there are any like minds who would like to do the same.

As of Fedora 7 Red Hat had relinquished control of Fedora to the community by merging extras and core into one distribution and giving the Fedora Engineering Steering Committee (FESCo) oversight over the whole project. FESCo is somewhat analogous to the GNOME Board. Today it was unanimously approved by FESCo for the OLPC operating system Sugar to become part of the fold.

This means we will be moving from the Red Hat build and CVS servers to the Fedora servers which are open to the community. It also means we will be working within Fedora towards making it more and more flexible for targeted projects such as OLPC.

In the coming weeks I will be rebasing Sugar on Fedora 7 and moving all of our packages over. More information about the OLPC/Fedora partnership is on the Fedora wiki.

Fedora 7 is now available for download. One of the biggest improvements is the merging of core and extras into one repository open to all community members. In the next month or sooner I plan to start merging the OLPC changes and rebasing off of Fedora 7. Right now we base off of Fedora Core 6 with some code forks and new packages.

The idea is to merge the new packages, drop some of the packages we forked from extras and use the ones in 7. We still need to keep some of the forked packages, for instance gnome-vfs which picks up ORBit dependencies even if we use the GConf-dbus package. Those packages will be looked at for Fedora 8 to see if we can get runtime dependencies working or simply replace the offending code (in this case GConf).

What this means for OLPC developer is I can now give access to our packages so that they can add and hack on base system components such as TUBES or pyabiword without myself being a blocker for builds. Right now we stick these things in external repositories or someone has to ask someone else to kick off a package build. It also means others can help out on packaging , say if someone is on vacation or just busy, and keep things rolling. And the great thing is this is not all tied to OLPC as anything we get into Fedora can be used and tested for other purposes. For instance the AbiCollab stuff based on TUBES is something I want on my desktop. This will allow developers outside of OLPC to get premade packages to run and play around with and hopefully accelerate adoption of some of the cool technologies being pushed by OLPC.