You’ve done ***************** this much “good” so you are obligated to do more (and to my benefit first). If you don’t do so the world will implode.

I especially hate it when the person making that argument benefits from that good but doesn’t think they should contribute to it.

I do however agree with this argument:

You have done ******************* this much “good” and as a result have benefited from that good on average more than others, you have an obligation to keep putting in as much as you can. I am a beneficiary of your good and will try to add to it but I may lack the ability to contribute in any meaningful way.

On the philosophical side:

Is it more moral to get paid for the above arguments’ “good”, which frees you up to do more of the “good” or to do something else for a living with results being the scope of your “good” contributions are less than they would have been?

Those questions I don’t think there is a real answer to.

And no Spot, I’m not going to suddenly quit, I just sometimes wonder why I chose to be a public free software developer when it means I have to deal with anonymous idiots or break my own moral code on censorship.

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.

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.

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.

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.

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.

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.