Seen today on a web site that shall remain nameless:
This web site has been optimized for use with Microsoft® Internet Explorer 4.7 and above. Get your free browser update today.
I had to double-check my calendar to make sure I hadn't accidentally walked into a Tardis and been sent back to the last millennium.
I use open source software every day on all the computers I own. In fact, outside of work environments where Windows is still predominant, very little of the software I use is closed source these days. As a result, I've wanted to contribute back to the community that has developed such great software by fixing bugs and implementing new features. However, I've found it a lot more difficult that I expected. To make any meaningful contribution, the project I would contribute back to had to be a piece of software that I used regularly. When I look at the ecosystem of software I use regularly, they are either written in C, a language that I haven't programmed in for 20 years (assuming the stuff I did at university actually counts) or they are extremely complex, or both.
Then, a few months ago, I got wind that one of the planned changes for Ubuntu 10.10 (Maverick Meerkat) was to replace the default photo management software: F-Spot was out, Shotwell was in. Photo management has been a sore spot of mine for ages on Ubuntu. None of the software that was available until now actually met my needs so I ended up not using any photo management software and doing everything through the file manager. Looking into it, it looked like Shotwell was the ideal opportunity for me to get a photo manager I liked. Shotwell uses Vala as a programming language, which I found intriguing and which I thought should be easier than C to get into.
So I downloaded the source from the SVN repository, built the software and lo and behold, the build was actually easy and 10 minutes later I had a local version of Shotwell to play with. I then had a look at the source code and found it very easy to understand. So I thought: let's see if I can fix an easy bug!
For that experiment, I choose a bug that looked extremely easy: bug 1954 looked like the ideal candidate because it merely consisted in adding a line of information to an existing window in exactly the same way as the other lines already present in the window. And indeed, the fix was trivial. So I created a patch and uploaded it to the bug tracker.
What happened next was very important and is something that all community projects should be very attentive to: I got some feedback on my patch within a day, basically saying that the patch had now been committed to trunk with a minor modification. This is extremely important and is something the Yorba team, who produce Shotwell are very good at doing: all contributors are welcome and any contribution, such as suggestions or patches, are acknowledged very quickly. From a contributor's point of view, it means that you know that you can really participate and help the core development team improve their software.
Quite chuffed by the outcome of my first bug fix, I decided to use Shotwell extensively and try solving more complex bugs. I eventually hit a significant issue with my SLR camera, which I duly reported in the bug tracker and which I decided to attempt to solve. It took a bit of time but I eventually got there and as a side effect actually solved another bug: result!
By now completely sold on Shotwell, I wanted to do my bit so that it would be well received by Ubuntu users. In my mind, the most important thing was to ensure a smooth transition from F-Spot to Shotwell and indeed the migration was one of the major requested features in Launchpad and very high on the Yorba list too.
Implementing such a major feature can feel a bit daunting at first but, at the end of the day, integrating and migrating from weird and wonderful databases is something I get involved in on a regular basis in my day job so bringing that experience to Shotwell sounded like the way to go. And to be honest, the F-Spot database is extremely simple compared to some of the horrors I've faced recently.
It took a bit of time and I learnt a lot about Vala and the GObject library in the process. Thanks to the support from Jim and Adam from Yorba I got there in the end and finished the bulk of it in the middle of GUADEC. A few more extra tweaks were required but it's now in fairly good shape, ready to face the hordes of new users that Ubuntu will bring it.
There you go, that was my first major contribution to an open source project and I'm now hooked so will endeavour to contribute more.
The Nokia N900 is able to upgrade its operating system over the air, which is the best way to upgrade it, especially if you have a fast Internet connection. This is also very practical when you're not running Windows because the Nokia suite only exists on that platform. This is exactly what I had been doing since I bought my N900. Except that a few months ago, I declined to update when requested for a reason I have now forgotten, probably because I didn't have the time then. And since then, it has failed to propose any new upgrade. So the only solution was to flash it but I had no idea how to do that on Linux. Luckily, I found a very handy guide on the subject which includes a version for Linux. Unfortunately, this guide is light on details and not fully correct so here's the fix.
Note that flashing the device rather than upgrading it over the air will remove all software you previously installed, as well as some of your settings. It will not delete your data as it only flashes the root partition. Your address book for instance is safe. But I would still strongly advise that you backup your device before going any further. The N900 ships with a backup utility so please use it and copy the backup file to your computer. If you fail to do so and you lose all your data, you're on your own to recover it.
As the guide explains, download the Linux Flasher Tool and the latest available N900 firmware image. You will need to enter your device ID for the image and in both cases you will need to accept Nokia's license agreement.
If you are using Ubuntu, I suggest you download the .deb version of the flasher tool: maemo_flasher-3.5_2.5.2.2_i386.deb, then double-click on the downloaded file and the package installer will open. Install the package. The flasher tool will then be installed to /usr/bin, not in the current directory, as suggested by the article.
For the image, ignore all the red warnings on the page next to the eMCC image links and download the latest combined image for your region, in my case RX-51_2009SE_10.2010.19-1.203.1_PR_COMBINED_203_ARM.bin.
Go through steps 3 and 4 as explained in the guide: turn the phone off and connect it to your computer via the USB cable.
Now comes the glitch in the guide: the actual command to flash the image needs to specify where to find the image in question:
$ sudo flasher-3.5 -F /path/to/image.bin -f -R
When you run the tool, you will get quite a bit of output when it validates the image. It will eventually show the following message:
Suitable USB device not found, waiting.
And the tool will hang. This message is not an error message as the guide says, even though it sounds a bit ominous, it's the flasher tool's way to tell you that you need to switch the device on so that it can find it. So switch the phone on. As soon as you do so, the flasher tool will recognise it and will start loading the image. It will provide on-screen feedback while it does so and the N900 will display a small progress bar at the bottom of the Nokia boot image. Once the tool has finished, the phone will take a lot longer than usual to start up. Don't try to hurry things along, just wait until it is fully booted. Then, and only then, disconnect the phone from the computer.
As mentioned above, you then need to re-install the software you had previously installed on the device. Luckily the OVI application store remembers what you previously paid for and downloaded so you should be able to just re-download software without having to pay for it again.
I was at GUADEC this week so here is a summary of what I took out of it.
GUADEC was held in The Hague this year and hosted by De Haagse Hogeschool. The Hague is a nice medium sized town where, in typical Dutch fashion, you go everywhere by bicycle or tram. Public transport is very efficient, fast and always on time. In short, the only similarity with London is that the weather was cold and cloudy most of the time we were there. De Haagse Hogeschool is a great space for such a conference, with good rooms for the talks and a great space to mingle with people during breaks. However, the restaurants around the venue were clearly not used to having that many customers and I missed the afternoon keynote talks both on Thursday and Friday when it took longer than expected to have lunch. On the other hand, lunchtime was always spent with a bunch of very interesting people so no harm done there.
As there were different streams running in parallel, I didn't go to all the talks. Also, I may have completely missed the main point of any talk so what follows is my take on things. It may be biased, incomplete or outright wrong due to me misunderstanding something or other.
Luis is a lawyer at Mozilla and a geek. His premise is that since the first GUADEC in 2000, a universal platform built on open source software has appeared on every computer on the planet and it's a platform upon which Microsoft is actually struggling to keep up with the competition. It's not GNOME, it's the web. And it's not a fad, it's here to stay (despite what the star formerly known as the star formerly know as Prince might say).
Luis suggests that we should strive to make GNOME Shell the best shell for web applications. All GNOME applications should embrace the web and integrate with it. And when you write a new application, you should write it in HTML and JavaScript first.
I completely agree with the idea of integrating the web into the desktop. A photo management application for instance should be able to seamlessly integrate with services like flickr so that you don't have to leave your desktop to upload photos to flickr or to subscribe to someone's photo stream. In practice, this is what The Web Standards Project have been pushing for some time in the form of the semantic web.
I disagree with the idea to write all applications in HTML and JavaScript because that would significantly reduce developer freedom and flexibility in writing those applications. Also, HTML and JavaScript are just a tool, are well suited to some applications but not all of them.
Finally, there is on aspect which I believe Luis is very aware of: I want to know where my data is hosted and be able to make sure that some of my data is exclusively hosted on my own machine, not somewhere in the cloud. That sort of issues will need to be addressed if the desktop platform we use is to integrate more closely with the web.
This talk sparked a bit of controversy. Dave presented the results of the GNOME Census report. This report produced some statistics on the people who contribute to GNOME in the form of commits to the repositories. The idea was to understand better who contributes to GNOME and how much of it is contributed by paid developers.
Obviously, the fact that Red Hat accounts for 16.3% of the total and Canonical accounts for just over 1% sparked controversy with people saying that this was the proof that Canonical didn't contribute. We're talking about statistics here so as usual they don't tell the whole story and I feel it is very dangerous to draw any conclusion from them. Dave is very aware of the fact and took great care in including caveats in his presentation. That didn't prove enough to prevent the controversy though. So here's my take on what aspects of the statistics show that they should be taken with a pinch of salt:
I have very few notes on this talk, it basically amounts to: some stuff works, some doesn't and it's still a work in progress.
Another talk where my notes are less than of stellar quality. The idea is that the GNOME Shell developers are here to make GNOME great. And indeed, the demos look fantastic and are very encouraging. A lot of thought has gone into the interface and I think for the most part, it will make application management, from a user's points of view a lot smoother. On the other hand, some bits and bobs look like the same old things re-hashed, in particular how notifications are handled. I'm not sure how Ubuntu will integrate that as they seem to go the opposite way from what Ubuntu has been doing in this area. Time will tell.
What more to say than absolute genius? There's no point in me telling you what happened, you needed to be there.
Clutter has a new logo and a new web site. Very interesting is the introduction of ClutterState to provide declarative state changes and animations. The latest implementation also makes use of the GPU if available. Very, very cool technology and it's what makes MeeGo rock!
This was a very interesting talk and it made a lot of excellent points in how to handle the release of library code. A lot is also applicable to end user applications and everything is equally applicable to open source and closed source code. The main ones I took out of it are:
That's quite a list and I agree with all of it!
A very interesting talk by Carlos on how to integrate multi-touch abilities in GNOME applications. There is a whole new API for that, that basically allows you to specify the device to use rather than assume that there is a single keyboard and mouse connected. The low-down is:
If you want to play with it, you will require XOrg 7.5 and you can get the code through git:
$ git clone -b xi2-playground git://git.gnome.org/gtk+
A quick introduction on the changes brought by GNOME 3. My take on it:
.desktop will be much more central to the application, will act as a unique ID for it and will provide more features. In particular make sure, to include the StartupNotify=true option.libnotify.Thanks to Andrea Scheer, Sophia Klees, Andreas Weigt, Martin Steck and Clemens Buss for a very inspiring workshop! I failed miserably at my task in the warm-up LEGO exercise. We all had a lot of fun and I think we came up with interesting concepts. If I find the time, I'd love to try to implement some of what the team I was working on came up with.
Tracker has evolved a lot since version 0.6, which is the one available in the Ubuntu Lucid repositories and a is a lot less resource intensive than it used to be. It provides application with the ability to share all sorts of data and is standards based. It also has a brand new query interface in the form of tracker-sparql which looks very powerful.
In practice the tracker database provides functionality which is very similar to what Desktop Couch provides, which is what is installed by default in Ubuntu. Tracker does not provide the replication facility but it provides more comprehensive search facilities. The other difference is that Tracker is designed to store non-application specific data (such as meta-data on an image, which should be available to any image management or manipulation program), while Desktop Couch includes application specific data such as preferences, as well as non-application specific data. I don't think the two are incompatible though and creating a Desktop Couch back-end for Tracker could be very interesting and provide a solution that is greater than the sum of its parts.
Andre presented an interesting research he did based on code commits and bug activity to try to identify projects and translation teams that were in need of help in GNOME, the results of which can be found online. It still leaves a lot of questions on how to help those projects but identifying them is an essential first step.
Rob presented libsocialweb, which is used in MeeGo to provide integration to web services such as Facebook and flickr. And there were demos aplenty: very entertaining! Oh and GeoClue looks really cool too.
For professional graphic artists, it is essential to have proper colour management throughout the complete image workflow, from the source (camera or scanner) to the output (printer or PDF file). OS-X does that to perfection, Windows 7 does it but not very well, Linux doesn't do it at all. Richard proposes a set of tools and libraries to change this and make the GNOME (and possibly KDE) desktop fully colour managed. Great stuff!
Maybe it was burnout from 3 days of conference but I found this talk the least interesting of all. All I took out of it was that there are a lot of reasons why Cairo hasn't released a new version for a long time, if Cairo is slow it's because the drivers are broken or developers are not using it properly and it's all going to be better very soon now as they move to a 6-month release cycle.
Anyway, moving on swiftly...
Danilo's talk was all about how to use Launchpad better to ensure that we can get related communities (such as Ubuntu and GNOME) to work together better. It concentrated particularly on bugs and translations. I think that, as a result of a question I asked, I volunteered myself to contribute code to Launchpad in order to simplify forwarding bugs upstream.
Nearly as important as the talks were the parties: it was the opportunity to meet people I'd only ever heard of or talked to via email or IRC.
The indefatigable Jorge Castro made sure that the party was a success. The music was a bit loud at times but considering it was held in a night-club, it was to be expected. It also proved that the best DJ in the world would find it hard to get a group of geeks to dance.
The beach party organised by Collabora was great. Less loud music than the Canonical one and a nice barbecue. It would have been perfect if the weather hadn't been cold and windy. We also got to be initiated in the correct Dutch etiquette regarding the use of satay sauce at barbecues: just drown everything in the stuff.
This hacker space is just great and it was a nice way to wind down.
It was a pleasure to meet Adam, Jim, Rob and Lucas from Yorba while at GUADEC. We talked a lot about Shotwell and with Jim's help I finalised the code to migrate photos from F-Spot, which Jim committed in trunk. There are a couple of follow-up bugs that were reported by early testers but the bulk of the functionality made it in before the string freeze and the rest should be sorted in time for the release of Shotwell 0.7, which will them make it into Ubuntu 10.10.
Next year, GUADEC and Akademy will join forces for a desktop summit in Berlin.