Tablet PCs – a chance for Maemo?

I just have watched the Apple iPad announcement and I have to say that I am quite impressed by the Apple marketing team. Before the film I could not think of a good use case for a oversized iPod, but after the film I have to say that Apple greatly refined the use case of the netbooks as a second PC.

Instead of putting an ordinary OS into a differently shaped device, like Microsoft is seemingly doing with the Slate, Apple adjusted the OS to the new use case.

If you have a much smaller screen and a much smaller keyboard, like you have on netbooks, you don’t want to write long articles or aim for the tiny buttons of ordinary user interfaces. Instead one should of a netbook like a playback device, which only requires rudimentary interaction.

As apple is great at streamlining stuff, they simply left out the keyboard and used a modified version of the iPhone OS, which is optimized for easy usage and – voilla here comes the computer you actually want to use in your living room, to quickly peek on facebook or your mail inbox.

But there are two big disadvantages that come with using the iPhone OS. First it is stripped down to much; there is no multitasking and no system clipboard which takes a lot of the convenience you have when using a real OS.

And second you are again locked-in by apple. If you use the iPad, you are also more or less forced to use iTunes for your music, iBook Store for your eBook and the AppStore if you want new Software.

Of course you might be able to Jailbreak the device and use third-party software but this will be nowhere as convenient as using the defaults. This is Apples Achilles heel and where Maemo can triumph.

With Maemo you basically have a full-fledged Linux with a easy to use UI. You have multitasking, you have a system clipboard and most importantly you have an open software repository – and all of this very well integrated in the UI.

You can freely choose your email provide, your music player and even the format you save your music in. And even though Nokia does not support OGG by default, the open nature of the OS allows it to be just as integrated as everything else.

Actually Nokia only has to build a Internet Tablet with the size of the iPad…

4 Years Later

Nearly 4 years ago Jon Smirl, the author of the experimental Xegl server wrote a nice summary about the state of linux graphics. He did that after realizing that it take much more time than he could out into Xegl in order to fix the linux graphics, so it is a realistic summary.

The interesting thing is that in his vision he described an X server which would run without root privileges and use OpenGL for all its drawings. Number one on his todo list though was a memory manager for DRM, which would enable all the nice stuff.

Well it seems that coming with Karmic we will finally see that first step done; most of the users(Intel and AMD) should get a nice in kernel memory manager which will be visible by Kernel Mode Setting. So what can we expect next?

Linux Graphics Dependencies

This diagram shows the dependencies of the various features. (Source) Green is what we should get with Karmic. The graphics-memory manager in kernel allows moving mode setting there too, so the resolution is set only once during bootup (flicker-free). Since the graphics card is now controlled from one hand it also allows dynamic power management to be done and does not require root privileges for X, which results in better security. Memory management also allows giving 3D applications their private front buffer, so they dont conflict when rendering. (RDR, Redirected Direct Rendering) Which is basically the core of DRI2. It also allows supporting memory related OpenGL features like VBOs or FBOs(Vertex/Frame Buffer Object) which brings the compliance level of MESA up to OpenGL 1.5.

Theoretically everything up to OpenGL3 could be implemented now, but since of the old design of MESA everything would have to be implemented for each driver over and over again. That is why Gallium3D was created. It is a intermediate level API which abstracts from the hardware by just offering a  state tracking interface. On top of that it is possible to implement more sophisticated APIs like OpenGL, OpenCL or a Video Decoding API like VDPAU. These implementations can then be shared across all drivers which are built on the Gallium3D architecture.

Well it is still a way to go until we get these grey boxes, which Windows and Mac basically already had 4 years ago…

Gnome Online Desktop

There was a lot of talk recently about how Gnome should embrace the online services in order to keep up with the Web 2.0 development. But sadly most of the ideas were like “lets integrate better with web service <foo>” – the problem is that I do not want to start using Google Calendar from now on; I like the way Lightning handles my dates and I like that I have them available offline. What I would like would be able automatically synchronise them, when an online connection is available.

But we are already too focused on the data layer right now, so lets take a step back and see where we are.

We are here

What we currently have are web pages or better web services with interfaces described with XHTML and styled with CSS and we have local applications with interfaces described with XML and (eventually) styled with CSS. So the UI done pretty similarly already – although it still looks quite different, since there are standard web-page widgets and since most of the web-pages are drawn inside the browser, while local applications are drawn as separate windows on the desktop.

The difference

One might think that the difference might be the place where computation happens, but actually the computation happens in both cases on your local machine – it is just that Java Script is the only language you can use for web services and it is pretty limited right now, but things like Tracemonkey and Google Gears are creating a platform for computation intensive application delivered over HTTP.

And that is also the main difference; the way applications are deployed. Because web-services can be updated every time you reload the page, you can easily keep you customer up to date, while for local applications you often have to deal with out of date applications and updates. This is especially a problem on non Linux platforms, where you do not have a central package(application) manager. But on Linux we have that advanced systems for update delivery so this is not really a problem.

The real difference

What everyone is doing right now is rewriting existing and working code in Java Script in order to solve that one delivery problem, which is really not that big on Linux while the rewriting task is quite huge. And everyone starts using that new and shiny web services – but the question is why. The real benefit which web services offer over current local applications is centralized and therefore synchronised memory; you can log into Google Calendar from every PC you have access to and always see your up to date dates.

So we need

So basically what is missing from Gnome is that centralized memory, but the problem is that an open source community can not easily offer that because someone has to pay a lot of money for a lot of servers. So we still have to integrate with the existing web services. Nothing new here. But that is not a problem either, since there are already web services for everything one might imagine.

What we have to consider here, is that we have to be able to switch easily between different services like lets say Picasa Web Albums and Flickr. We could even define an open API for web service interaction which the services could implement then.

The master plan

to me it makes no sense re-implementing everything in JavaScript just for the sake of being able to run it inside the browser. We have already a variety of better languages available, when running on the local machine and there is also much of the infrastructure ready.

So instead we should make the existing applications more web-aware. Luckily there is already a framework made exactly for this: Telepathy. Currently Telepathy only manages your web-presence status and allows local applications to work with it. But it should also be able to manage your web-pictures and web-calendar and make it accessible to local applications similarly.

Then F-Spot could easily show you which of your pictures are currently published and which are only available locally without making a difference between Picasa Web Albums and Flickr – you should only care whether your pictures are synchronised or not.

The next step would be to actually take advantage of such a framework. If you currently want to write a text you have to care whether you write it for offline or online usage. If you write it for offline work, then things are pretty easy; since Word is not available on Ubuntu you use OpenOffice. But if you write it for online use you have to deal with a bunch of different interfaces – depending on what your web software is you have to deal with the WordPress text editor, the Joomla text editor and so on. And they all have in common that you cant save your text to your local computer easily.

The initial task was just to write a text – why have do I care of such things at all? Would it not be great if I just could open a local running text editor, write my stuff and then decide whether I want to save it to a file or publish it to a web service of my choice.

A locally running web-aware application could do that while offering a consistent interface for text editing and doing a lot of things which you can not inside a browser like launching Gimp in order to edit that picture you need in your article and then automatically upload it.

So basically we have to move things offline in order to get an online desktop and then we can also use browser for what they were meant for; reading text.