Lone Wolves

In its second year, T-Dose, the Dutch Open Source event aimed at developers takes place in Eindhoven. Your two LXer editors went there to find out what's happening and what's new in open-source land. Todays topics include QTopia for PDA's and smartphones, open source software in the iLiad digital paper device, KDE4 application programming, the Lodel publishing tool, efficient data structures and how to overtake proprietary software without writing code.

Free Software in telecom - Knut Yrving (Trolltech)

When it comes to smartphones, more and more are using Linux as an operating system. This is a huge portion of the market compared to desktops and laptops. There are four times more mobile phones than there are regular computers. In this segment, Linux grew from a market share of 7% in 2004 to 22% in 2005 while at the same time 30% of the smartphones sold in China shipped with Linux as their OS. However, the development of free software for phones is not as straightforward as it may seem. There are over 1500 different phones out there and for each phone type that a development team needs to support, it adds 15%-20% extra development time. A simple 100 hour project grows into a monstrous 1000-1900 hour project if you simply try to support just the 60 most popular mobile phones. In addition to this, some phone manufacturers try to make it hard and/or impossible for 3rd parties to develop software for their phones. Apple's iPhone is an excellent example of this. Also, because of the very different hardware in those phones, even if java-software runs on one phone it doesn't automatically mean it runs on other java capable phones. These reasons make software developing for phones very expensive.

That's why Trolltech came up with the QTopia Greenphone, meant for developers. QTopia is a PDA application framework that's OS-independent and runs on lots of different hardware, on top of the OS. Trolltech thinks the open QTopia environment will cause phone software to become more open in the future. They think it will lead to success for QTopia because software development for phones will be much cheaper if one doesn't have to test new software on each different type of mobile phone. Also, Trolltech thinks a more open development system will lead to a lot of new innovations in PDA- and smartphone software.

The idea of a more open way of developing also appeals to telecom providers. Telenor, a big telecom provider based in Norway and serving 129 million customers worldwide, has the objective of 'creating an open service innovation area', as their iLabs site says. Therefore, they started the PATS-project in cooperation with the university of Trondheim, NO to educate students in making new innovative programs. While developing for mobile phones using QTopia seems a daunting task at first, students appear to be enthusiastic about the platform, and many innovative programs may appear in the future, games for example. Because you carry your phone with you all the time, new possibilities emerge. For example in the UK there is a game called "Duel", a game in which you 'shoot' other members in the same room who also participate in that game. As soon as someone enters a room where another player is, Bluetooth notices the other participant and gives a signal to the user. The first one to press a button 'shoots' the other participants, and they 'die'. These kind of possibilities promise to give a new dimension to gaming.

Telenor is not alone in its interest for QTopia - Nokia, the largest phone manufacturer in the world also seems to have an interest in the platform which will ensure this technology definitely reaches end users.

Building web-based applications with GWT, the Google Web Toolkit - Bram Molenaar (JTeam)

Ajax and browser-agnostic web applications are hot these days. However not every programmer is available to write programs in Javascript, but on the other hand a lot of programmers can program in Java. That's why Google came up with the Google Web Toolkit, which is open source (Apache license). It includes a compiler which compiles Java source code to Ajax web applications. The Google Web Toolkit also ensures corporate support of this platform and that the applications will work on any browser. For example, the person giving this presentation used the Safari browser on his wife's Mac to show the applets he had just compiled in front of our eyes because his own laptop had been stolen a few days before.

One of the advantages of this platform for example, is that the users of these applications can use the forward and backward button like they're used to doing in their own browser. Also, work on 'drag and drop' is being done right now. However this is difficult since GWT doesn't support Java 5 at this moment, but thats only for now. There is a version which does support Java 5 is on its way.

This technology looks promising for both to developers and users. For developers because they can use their Java best practices and they don't have to learn Javascript. For users because the GWT-toolkit solves any of the differences in working with a myriad of browsers. This means GWT-created web-apps will work exactly the same for IE on Windows, Firefox on Linux, Safari on Mac, or Opera on a mobile phone for instance

Open source in the iLiad e-paper device - Matthijs van de Water (iRex)

A while ago, Royal Philips developed E-Ink; a display method in which no energy is used if the image being displayed doesn't change. As this technology seemed promising, a spin-off called 'iRex technologies' was started, which developed the concept to a commercially product which it dubbed the iLiad (see iRex link). The display is changed by means of changing electric fields. The pixels are small pebbles containing tiny electrically charged black and white particles. Change the electric field and you can change the color of a pixel. When there is no electric field then the particles remain static, as does the image. Because only updating requires power and because the screen does not emit any light itself which makes the device very economical with batteries, up to 12-14 hours under regular use. In addition, because it only reflects light, the readability is very close to regular paper.

So far all seems promising, but there are a few disadvantages: It takes one full second to refresh the whole screen and there are only sixteen shades of Grey possible. In the future they will be able use a color filter to create color images but the resolution would be reduced since you need 4 pebbles to make up one pixel. Also, you cannot update just a part of the screen, full screen refreshes only. This leads to new and interesting restrictions on UI development.

For example, UI feedback is very hard to do because it will always feel slow. The same problem exists for web browsing because it takes such a long time to refresh the screen. You will only refresh it when all the drawing is completed. In the case of web browsing that means you have to wait for the page to fully download and render.

The low color-depth makes the device mainly useful for reading e-books and taking notes next to the text to be studied. One might wonder like we did, how it is possible to take notes if the iLiad is not able to change only a part of the screen? This is done by a 'dirty hack', a faster and only partly refreshed screen is possible when only using black and white, so no grayscales. And it isn't very precise so the hack cannot be used to render regular graphics

Input works via several buttons and a Wacom-stylus. The iLiad cannot be operated by touching it like a tablet because of the different display technology used. The touch screen works by putting a film over the screen that dims the brightness a bit because the iLiad does not emit light. Reflected light would have to pass through the layer twice (in and out) which would make the screen too dark to be useful. The iLiad also includes handwriting-recognition, wifi-capability and a USB-port. The main problem is getting the iLiad to respond quickly. While browsing to the next page in a PDF and contrary to what we expected, it was not the refresh-time of the display but the processing power that was the problem: The iLiad contains a 400mHz Intel xScale processor. To tackle this issue the iLiad uses pre-processing so while you are reading, it is processing the next page of a PDF, for example.

It is a very nice device indeed. We were able to get a good look at it and even though the display is a bit smaller than a standard A4, it is very easily readable. The reason iRex was invited to T-Dose is that it is aiming to create an open development ecosystem around this new device. The iLiad itself also uses lots of open source software, including Linux 2.4, GTK 2.6 and the Matchbox window-environment. It uses some older versions of open source software because it is still covering some legacy hardware, for which no working drivers are available in the newest versions when the device was built. However as iLiad is updates the hardware and the hardware-manufacturers update and open up their drivers, it will become possible to support newer software like Linux 2.6 and GTK 2.10 or 2.12. At this moment Dillo, AbiWord (though doesn't work very well), a few calendar and address book applications along with other programs are ported to the iLiad and the community is busy porting the whole of QTopia 4 to the iLiad as well. iRex also plans to open source their own applications when they become more stable.

An obstacle for the iLiad may be the price; it costs €649 or $700 (finally a gadget that costs less in Euro's than in Dollars!). iRex is working on subscription models to bring down the price. They could be sold in combination with a subscription to a newspaper for example. Roughly 70% of the price of a newspaper is production cost which can be saved by distributing newspapers over internet. These savings can then be used to subsidize the iLiad. Negotiations are currently taking place between iRex and several newspapers such as the New York Times, The Financial Times and a few Dutch newspapers.

Lodel Content Management System - Odile Benassy (Paris Sud University)

[Note: Because I attended only half of this presentation, and since I am not that up to date with content management systems, I can only give a superficial overview - hkwint]

Just like Wiki for example, Lodel is a content management system for data you want to publish online. It is meant to be easy in both setup and configuration. A bit unlike Wiki, Lodel is meant to create output of a high quality, like OpenOffice and TeX. At closer inspection, Lodel actually seems to be a hybrid of both Wiki and TeX. Different people can have different access rights in this system and Lodel has nice database interfaces to handle all this - in fact MySQL is used. One of the main strengths of Lodel is the user having the choice to create content using Microsoft Word or OpenOffice, Lodel will then translate it to the XML-presentation it uses. It also includes a scripting language called Lodelscript which can be used to create loops and other control structures to speed up your work. Amongst many other applications, Lodel is of good use for making essays or good-looking webpages.

Like you can see when looking on the Lodel.org site, it is mainly developed and used by French-speaking people at this moment but German and British people have joined the effort as of late and as always, translators are welcome.

KDE4 - Adriaan de Groot

Adriaan de Groot is a researcher in (Free) Software Quality, a long-time KDE contributor and serves on the board of KDE e.V. and NLUUG. He is also a gifted speaker, he was easily the best I heard all day. Adriaan talked about the technology of the upcoming KDE4 and what it means to develop using the new KDE4 core libraries. His own contributions to the project are mostly QA related tasks to make sure KDE works well on other Unix platforms besides Linux, such as the BSDs, Solaris, HP-UX and AIX. The Windows and OSX ports are watched by someone else.

The pillars of KDE4 are it's core libraries which cover a large amount of technology. In each case the KDE team has tried to make the APIs as simple as possible and they have tried to incorporate as many existing leading technologies as is out there, such as GStreamer or HAL/D-Bus. Pretty much all the complexity of these different technologies are abstracted away from the KDE programmer and most of them have pluggable backends which make it possible to change the underlying technology without changing the APIs. One of the lessons the KDE team took from KDE3 is that relying on a single technology can be dangerous, as KDE did with the aRts sound system.

Adriaan then talked about the different base libraries in KDE4, such as Phonon, Decibel, Strigi, Sonnet and more which I am not going to repeat here because the internet is filled with great reviews of those libraries. The most important thing I took away from it is that the KDE team has tried to abstract away pretty much all the complexities so that developers can focus on the applications instead. I was very impressed by it, and that is saying a lot being a GNOME guy myself.

Efficient data structures - Jörn Engel

Jörn's talk was more technical and programmer oriented than the other talks I attended that day. But the small conference room was still packed with people. Jörn explained that since the invention of RAM, it really hasn't gotten any faster. Today's access time for RAM memory is in the order of 60 nanoseconds which may have seemed instantaneous a decade ago but not today. Worse, the speed of RAM is not likely to increase anytime soon. RAM has become a high latency-high bandwidth device much like another device we already use and have optimized for years, The Hard Drive. Instead we have a new and fast RAM, it's called "processor cache".

Much of the programming techniques that were invented to deal with slow hard drives in the past can now be used to overcome the problem of slow RAM, it's all about preventing "cache misses". A cache miss happens when you need to look up something in RAM that is not anywhere near where you are in memory now, which is the cache.

Jörn then covered most of the data structures that programmers know of to manage a large collection of items and gave examples of how they worked and why some are faster than other's when accessing them sequentially or randomly. Starting with the simple single and double linked list, he moved on to hash tables, binary trees, red-black trees, radix trees, B-trees and finally Jade trees. Over that last tree type he remarked that it's the most efficient structure but its impossible to work with, it's insanely complicated and horrible to debug. There once was a person brilliant enough to implement a bug-free Jade-tree implementation, but unfortunately he was also insane enough to write an interface for it that consists of 120 odd 3-letter C functions.

The main lesson to take away from this presentation: Don't use linked lists or hash tables unless you know in advance exactly how many items you are going to use (which is almost never). If you don't know what to use or are unsure, use one of the B-tree variants such as B* or B#. Overall they give the best performance with the least amount of cache misses.

Conclusion

Overall it was a very good day at T-DOSE. It had a bit of a slow start, with only 30-40 people present when Knut Yrving started his keynote speech, but people kept pouring in and in the end it was quite busy. The talks were of very high quality and it showed in the large number of people attending them. There was only one talk that did not draw in a big crowd: iBuilding's sponsored talk on PHP. I attended it and can only conclude that iBuildings only have themselves to blame. Their talk consisted mainly of advertising Zend's closed-source Zend Framework and Zend IDE products. Not a terribly smart move on a Free Software conference.

Other than that, it was a great day. There are a few things that we have not covered here yet, such as the expo floor and Olivier Cleynen's excellent talk on how to promote Free Software. And there are pictures of course, but we will pick up the slack in our coverage of T-DOSE's second day.

This article was originally posted on LXer Linux News and was co-written by Hans Kwint.