As Andreas note we are rather close towards Calligra 2.4 which will be the very first release of the Calligra Suite.

Our pretty cool Calligra Quality Dashboard lists 11 remaining release-critical blocker bugs that still need to be fixed till then.

I got a HP Pavilion g6 for my birthday -- this must be the first time I have a personal laptop, all my previous ones having been bought by KDAB (or by IBM as KDE sponsoring, for the very first one).

Main purpose: Windows music software. But also reading KDE email of course. So I installed linux (openSUSE, to try it out for the first time).

What backup tool are you using? You are using one, right? I am using one these days, namely git. My entire home directory is collection of git repositories. Using git for backups is great because it is easy to synchronize data. It is also easy to restore files without needing access to the backup server. I keep my .git directories in a separate partition and symlink them into the right position. Every few days I push all my git repositories to my backup server that has a user called 'git' with 'git-shell' as the shell setting. So sending backups to the server can happen safely over ssh.

There are downsides to using git though. The main problem becomes obvious if you work with large files. I do not have a lot of large files, but I do have a few virtual machines. One way of backing those up is to put them on a disk that supports taking snapshots. ZFS or 'lvmcreate --snapshot' are solutions for this. But what if you want to backup the different versions of large files to a different storage medium?

This is where bup comes in. Bup is a backup tool with a clever idea on top of git: it splits files by using a rolling checksum. Then it stores each file fragment in a git pack file.

To understand how this works, you need to understand a bit about how git works and how rolling checksums work.

In git, you can store every file for every version in every directory that you ever committed. If you make a commit in git, you store the entire directory tree. Yet, the disk usage of git is not so large. That is because each file is stored under a name that is determined from the content of the file. A fancy name for this is 'content addressable storage'. If two files are the same, they will have the same name. A directory is a list of file names. If directories have the same content, the list is the same, and the name under which the directory is stored in the .git folder is also the same. This concept is explained clearly in the git community book.

Git was designed for use with many small files. It cannot work efficiently with large files. If one bit changes, the entire file has to be stored twice. Git has a mechanism to store only the difference between files, but it is expensive to calculate this for large files.

Bup uses the idea of content addressable storage and solves the problem of big files with a rolling checksum. The concept is explained in an entertaining way in the bup DESIGN document. A rolling checksum is a checksum which you can slide along a data blob. You start at the start of the blob and calculate the checksum. Then you slide one byte along the blob; you substract the byte at the low end of the sliding window and add a byte at the high end of the sliding window. This gives you a new checksum. With a rolling checksum it is efficient to calculate a checksum for all positions in a blob (apart from the part where the sliding window started).
At each position where the last 13 bits of the checksum are 1, bup splits the blob. This gives chunks with an average size of 8192 bytes. All of these chunks are compressed and stored separately in a git packfile. If a bit is changed in the blob, two to three things change: the chunk where the bit is located, the following chunk (if there is one) and the list of chunks that is stored, similar to a directory, to restore the blob.

The current implementation of bup was written with speed of development in mind; git binaries are called from python code. There is a read-only FUSE implementation on top of bup to make it convenient to browse old versions of files. Going one step further, write support could be added. That would make bup into a filesystem, similar to Fossil with Venti or ZFS with deduplication. Bup would be better at deduplication, due to the rolling checksum.

Today the WebODF project released an Android app. You can get it from the Android Market and soon from FDroid.org. This is just the start. Viewing and editing office documents and in particular ODF files should be possible on all mobile devices. In the WebODF project we want to make this possible.

The Android application is 95% generic WebODF JavaScript and 5% Android specific Java code. For future ports to iPhone, iPad, MediaWiki and many other environments we will put most functionality in the shared JavaScript library and keep the application specific code to a minimum.

If you have a use case for WebODF, join us on #webodf or webodf@lists.opendocsociety.org to discuss it.

I've been last week in Concépcion, south of Chile to attend another nice open source conference, been the second brazilian around ( Sulamita Garcia beat me first :-). But for me was special since last year we have finally some latin american KDE communities giving life signs, and i would expect that take more time to have they start to appear strongly, even more most of latin america been a strong Gnome supporter for years.

Well, here's Camilo Astete to prove me wrong:

So, as looking that everyone is in the hiring mode...

Yes, Collabora is hiring. So if you are passionate for open source, want join a company that share the same passion as well, want to work from any place in the world and have at least some of these skills below, then we want to know you.

• KDE
• Qt
• Qml ( Qt Quick )
• C++
• WM and Graphics(3D, GL/GLES, X, Mesa) as a plus

Consider yourself a serious KDE hacker? Don't be shy, we want to know you too ! KDE is an important part of our lives now.

Then, what are you waiting for ?
Share your hacking ninja code skills contacting us at our hiring info channel, also known as email :-).

I've been fascinated by the Oracle attack on Google's Android. I don't follow sport and just couldn't understand why so many people were getting excited about the World Cup at Akademy. But to me these epic disputes are a great spectator sport, as well as an opportunity to participate individually. The trouble is that it is all a bit slow, even slower than cricket - if it is like the SCO vs Linus train wreck, it could take up to five years to be resolved.

Remember the last call? After less than 5 months we can see apparent success, and a lot more than a proof of concept.

Click to enjoy the show

Shocked by the title? So I am.

Would you like to see Qt supported on this platform? Just two days ago the answer was like "But it's close to impossible".
Now with NDK 1.6 the "little robot" OS opens more to C/C++ native code. I am eager to read some analysis on the topic.

One big risk with git is forgetting which branch you're working in. Several people solve that by putting the git branch in their shell prompt. But often they do that by calling `git branch` and parsing its output, which is quite slow, especially in big repositories (we strace'd it, and it really opens and reads a lot of files).

At GCDS, together with Aurélien Gateau et Sébastien Renard, we came up with
this light-weight implementation (http://www.davidfaure.fr/scripts/git_branch_in_zsh_prompt).