litl webbook: some technical comments


So, you’ve probably seen the news: litl webbook released! It’s the result of heavy work of an awesome team! Our website has a lot of information about the product from a user perspective, so I thought it would be nice to bring an overview of the more technical aspects of the litl OS that I find specially interesting. Scott has written some technical notes about our OS too.


Almost all UI code is written in javascript using our GObject introspection-based binding called gjs (using SpiderMonkey engine). It was a quite interesting learning experience to write a large amount of UI code in javascript. By the time we started, I think no one in the team had any real experience with javascript. So, it took some time until we all agreed on the javascript programming idioms (the flexibility of the language may “cause” a lot of inconsistencies…) and on how to better/correctly take advantage of its features. Most of what we agreed in terms of coding style is in the gjs style guide. Doing stuff in javascript (i.e. not doing the whole UI in C or any other insanity like this) allowed us to prototype, refactor, rewrite things much faster. And that was crucial for us because the ideas around the UI design changed a lot during the first months of development and we ended up rewriting large chunks of code several times on the way. Doing relatively large scale stuff in javascript definitely requires very clear and strong guidelines in order to keep the code base sane – maybe a bit more than usual.


The OS is heavily based on well-known open source projects. Some facts: it’s based on Ubuntu (with great support by Canonical) and the UI is all written with GNOME platform and co. As I said, almost all code is written in javascript using gjs. Most of the UI is Clutter-based. We have our own specialized window and compositing manager that was implemented with our use cases in mind. We’re definitely one of the projects with the largest Clutter-dependent code base. We use GTK+ in just a few places where we needed more complex widgets (i.e. text entry). The web browser is Gecko-based and it’s pretty much implemented as a XUL app running in a separate process than the OS chrome. We use Evince and Totem (as browser plugins), GStreamer, Network Manager, and others. One interesting fact about our development process is that, in the ~2 years of heavy hacking, we had to adapt to major changes in the upstream projects we base our OS on. So, since we started, we had to port our UI to Clutter 0.6, then 0.8, and finally 1.0; had to port gjs to use the then-new GObject introspection scanner; migrated from Network Manager 0.6 to 0.7; and maybe some other major changes that I can’t remember now. We contributed to those projects as much as possible during the process.

No storage, just caching

You probably noticed that the device has “only” 2GB of storage. That won’t sound strange if you see this from a “webbook perspective”. One of the ideas behind the product concept is that the device serves as a much improved window to the web. In other words, the device provides a simple and beautiful way to access web content – among other things. So, we are pretty much only using storage for local caching. We don’t really store any real permanent data on the device. And that brings some interesting challenges on how we implemented the OS. So we had to implement some smart ways to cache as much content as possible and expire the right bits at the right time so that the general experience is nice and smooth. Simple example: the OS provides a way to access all your Flickr photos and videos (which can be a lot of photos and videos btw) but we never permanently store anything on disk. We cache things like rss feeds, profile pictures of your litl contacts, a lot of your Flickr photos and videos, website favicons, installed channels, etc. Each type of content may use a different way of expiring items and all that needs to fit in the relatively small storage space we have. You can guess how fun it was to hack on this. Hacking on syncing was even more fun though :-)


Another interesting aspect of the device is that each device is connected to a litl account on our servers and all your stuff (browser cards, channels, settings, contacts, etc) is always synced in our servers. That means if you lose your device and get new one, you would just need to connect your device to same account and all your stuff would be nicely restored. Additionally, multiple devices can be associated to same account. In that case, they will automatically share channels and other things. If you add channel card in one, it will automatically appear on the other. We spent quite some time working on our syncing infrastructure (client and server), dealing some relatively complex problems – especially when dealing with making UI immediately react to sync-related changes in the local and remote datastores. The server side syncing stuff (and other server-side features) is implemented with Google App Engine, some bits in Amazon S3 and Django.

Seamless system updates

The OS comes with a smart update system. No package management involved. No user action needed to get system updates. In practice, we download and install a new OS image and fetch your data again from litl servers while the system is idle. The update system falls back to current image in case something goes wrong with new OS images. The update system allows us to keep updating, adding features, fixing bugs, and then push those updates to our users in a burden-free way.

We had a lot of fun hacking on the litl webbook. It’s always great to work in a team full of very smart people. Definitely learnt a lot in the process. We still have a lot of work to do of course but I already feel very proud of what we’ve accomplished so far. Exciting times!

Update: Saying that the UI is 99,99% Clutter-based is not very accurate. It’s a bit less than that :-)

Published by


Lucas Rocha is just a brazilian guy who loves hacking and music. He lives in the frozen lands of Finland with his lovely wife Carol. He works for Nokia in the development of Hildon and Maemo. In his free time, he's a happy GNOME contributor. He has a mustache, a beard and big smile in his face.

35 thoughts on “litl webbook: some technical comments”

  1. Lucas,

    You might be interested in a project, called fosfor, I am working on which is media player based on clutter and gstreamer. It will also work as a browser plugin with gecko-mediaplayer

    fosfor blog:
    fosfor code:

    gecko-mediaplayer code:

    Requires some minor config to make it fosfor work as the player over gnome-mplayer.


  2. The other nice thing about the update system is that the developers use it all the time! It’s not just a user feature, we’ve got it hooked up to our buildbot so that we get a new nightly automatically installed on all of our devices every night. So you’ve almost always got up-to-date code on your device when you turn it on.

  3. Congradulations, litl looks like a great product! But I can’t find any info about battery life.

  4. Oh, I forgot to ask, is the OS free? Could we download it and try it out on our netbooks? Maybe get the source and hack on it?

  5. Cool! I’m curious to know what version of Gecko you’re using, and whether or not you’ve considered dropping us Mozilla project folks a line about what we could do to make your lives easier.

  6. I am not sure if you will ever sell on of these device.

    The reason is simple. It costs 700 Bugs! And it not even has a touchscreen. This is riduculous.

  7. Mike: xulrunner-1.9 for now, we’re going to upgrade RSN to get TraceMonkey goodness. Peter’s going to drop you a line today, I think. Debugging xulrunner javascript code has been hard, maybe there’s something to do there, but (speaking for myself) I’ve been pleased as punch with SpiderMonkey (and with Rhino, which I’m using in a personal project).

  8. Seems quite expensive for a “netbook” I like the concept and what it does, but I can get an equivalent, more fully featured HP 311 for about $200 less. Curious about the price point.

  9. Huh. I had thought gjs maybe stalled since the page on page has been pointing to 0.2 for almost a year. Looking at the ftp site there have been releases since then. The site should really reflect that.

  10. so, where can i browse the software/patches you are applying to all that free software you are using? cannot find a link to that on the litl web site, but the gpl requires you to provide the sources/patchs somewhere.

  11. Nice to see you’re having fun with this new project. I wish you guys the best of luck, and I already want to buy your device :)

  12. @Waldo,

    Here are the current official legal instructions for that:

    “To obtain a DVD containing the source code for the open source components of our operating system, please write to:

    Sources DVD
    litl LLC
    33 Exeter St.
    Boston, MA 02116

    Please state your name, address and telephone number and enclose a check or money order for US$10 (inside US only) to cover postage and handling. Also clearly state the version of the sources that you are
    requesting. You can see the version details of litl’s software at the bottom right corner of this screen. Write down the characters that follow “litlOS version:” and be sure to include these in your letter.

    If you are outside the US, please email and we will make arrangements to send you the sources. Note that the DVD does not contain source code to our proprietary interface which is not open source.”

  13. On the website i read: “Litl maintains itself by handling updates, patches, plug-ins, fixes and other computery stuff automatically while you sleep.”

    It makes me think in DRM… :-( What is my freedom guaranties?

  14. This is really interesting. You are following the GPL but you don’t make it convenient to take part of the source. I can’t recall another a company that distributes the source of free software on physical media, and only on physical media, in this century.

  15. Any official comment on how it would compare with an AppleTV?

    I mean it’s got the HDMI connection, accelerated H.264 and at the very least I’m guessing it can access Youtube, Hulu, or iPlayer in the UK, stream internet radio, maybe and spotify.

    But I’ve not heard if it could stream from other machines maybe via UPnP? I believe pulseaudio can pretend to be an Apple Airport Express and receive streams from iTunes now.

  16. @ Claes, As I said, the DVD instructions are the “current official legal instructions” we have now. We don’t have a nice link with all our patches yet. We hope to have this magic link soon. Please, don’t get this wrong: we’re not trying to make it hard to get our patches. It’s just something that we haven’t done yet due to other higher priority stuff (keep in mind that we’re a relatively small team). If you want to have access to patches in specific modules or something, just email me or other team members. We’ll be happy to help. Cheers!

  17. @ Claes: note also that most of our patches to upstream code are *already* sitting in upstream git — ie, if you browse the commit history of gjs, gir-repository, etc on gnome, you’ll see lots of litl-affiliated commits. So, the source DVD is not the only way to get our sources — most of the source changes are already published, and probably already packaged in your favorite distro. We haven’t been sitting on our patches, we’ve been pushing our code as soon as we write it.

    However, the GPL does require a full aggregate of all sources to be made available by litl itself — we can’t legally just point you at gnome’s servers and say, “the sources are over there”. Every company that I’ve worked with that has shipped GPL’ed code has had to put together a physical source DVD to satisfy legal — please read section 3 of GPL v2 for details. Even OLPC has a source DVD which you can obtain for a reasonable S&H fee. As Lucas says, if you want to be sure you are obtaining *all* components and *all* patches to same, we have a source DVD which is built as part of our release process which you can obtain.

  18. The only questions I have is, I’d like an official stance on why a demo of the unit showed very apparent stuttering during a non HD Youtube clip. I’m very interested in the answer. Thanks. :)

  19. Were the web services done using the AppEngine python runtime? java? can you share any other details on them?

  20. This definitely looks like a nice product, the price is a little steep for not having a touch screen.

    What are the plans for SDK/API documentation to allow developers to extend the device, similar to Apple and Google’s phone OS systems?

Comments are closed.

Attribution-NonCommercial 3.0
This work is licensed under a Attribution-NonCommercial 3.0.