I've never been a big fan of saying goodbye, but I'm a big fan of lengthy ones even less, so I'll keep this short.

The time has come again: I'm transitioning, into something pretty different, but not exactly unexpected given my interests. As of this week, I've moved on careerwise, I'm now a software engineer at Collabora, working on cool stuff in C++.

It'll be interesting to see what the future brings.

While GStreamer has been working on Windows for a long time and one can compile GStreamer using Visual Studio, the lack of pre-made binaries for Windows developers has been a bit of an issue. Various groups and people have tried providing windows binaries for a while, but most efforts have stalled after a short while. The GStreamer winbuilds project however seems quite solid however and have now been doing good windows packages for quite a while. If you have been looking for Windows builds for GStreamer this is a good place to start. They already have a list of users on Windows and the reason I became aware is that the jokosher guys are using it for their windows porting effort.

Been following the news and discussion about Google and their recent acquisition of on2. For those who doesn’t know On2 is a codec company that created such codecs as VP3 (which become Theora) and VP6 which became Flash video. Their latest codec is VP8 which they claim is comparable to H264 in terms of quality.

The big question of course is what Google plans on doing with On2 and the codec acquired. I guess there are two likely routes Google could be going. One is to try to create some kind of vendor lock in with Youtube offering higher quality video using VP8 for Google clients like Android and Chrome. The other is that they want to remove the dependency on proprietary video formats on the web and will thus release VP8 as open source in a similar vein to Theora and Dirac. If they combine that with youtube offering high quality HTML5 videos in VP8 combined with ensuring that Firefox and Opera supporting the format in addition to Chrome then it could be a big move. Silvia Pfeiffer got some good thoughts and comments on the subject in her blog, including interesting comments from Monty and former On2 employee Dan.

From a Collabora Multimedia viewpoint we would of course love to add support for liberated On2 codecs in GStreamer, so if anyone from Google is reading this, just know that we would happily help you implement the needed GStreamer plugin code to get these codecs supported in GStreamer and the linux desktop.

Since my last post I have worked on applying a similar approach of making HTTP range requests to obtain indexes necessary for seeking in the Flash Video format version 1 (‘old’ FLV, if you will) and AVI (both legacy and ODML) in GStreamer.

Legacy AVI was fairly straightforward as we only need to do one seek to get the index. ODML AVI was somewhat messy because we had to perform multiple seeks as there can be multiple indexes spread across the file. As such, within the GStreamer framework, we have to handle the multiple seeks in the streaming thread rather than in the seek thread as we might prefer. This is because we cannot block the seek thread.

Check out the head commit of git master or the next release of GStreamer to try out this work. If you find bugs, file them on bugzilla as normal for GStreamer.

Hello World! It’s been a long time since I last wrote anything here, and for that I’m sorry. The autumn was consumed by university work, and the last few weeks I’ve been discreetly coding and writing to get everything ready for this announcement. Anyway, without further irrelevance, let me present the KDE Real-time Communication and Collaboration Project. You’ve probably heard me blathering about Telepathy before, but now for the first time we have a coherent plan for world domination, concocted by Abner Silva, Matt Rogers and myself (with help from many other people).

Let me briefly introduce the project and our aims:

• Fully integrate real-time communication (think VoIP, IM, Video etc) into the KDE Plasma Workspace (do I have the branding correct?)
• Provide a fully-featured Telepathy-based real-time communication experience in the KDE SC. (loving the double-barreled words)
• Provide infrastructure for collaborative features in KDE SC applications.

So, if any of this interests you, we’d love your help. Hop in to #kde-telepathy on freenode IRC, or join our mailing list.

And, while you’re at it, why not take a look at our code so far.

The Code So Far…

Warning: this is highly experimental code which may cause all kinds of side effects, especially the Nepomuk related stuff, which is likely to make a complete mess of your Nepomuk database, so use with care.

If you’ve read the above warning and want to take a look at what we’ve done so far, here are some instructions. For the first phase of this project, our attentions are focused on building Telepathy based components for basic IM usage on top of the existing Kopete codebase. So far, you can create an account (Jabber is the only kind tested, so expect minor bugs with other protocols), set its presence and see a list of your contacts. Not the most exciting stuff ever, but with this core stuff in place, more features should arrive very soon.

Prerequisites

You need recent telepathy-mission-control-5, telepathy-gabble and telepathy-qt4. Best to install these from your distribution. If telepathy-qt4 is not provided, or older than 0.2.0, then download the source here.

The Account Management GUI

Checkout and build the account management gui from svn here:

svn://anonsvn.kde.org/home/kde/trunk/playground/network/telepathy-accounts-kcm

Also install its plugins from

svn://anonsvn.kde.org/home/kde/trunk/playground/network/telepathy-accounts-kcm-plugins

You can launch it by running:

kcmshell4 kcm_telepathy_accounts

And then follow the wizard to set up your Jabber account.

Setting the Account Presence

To set the account presence through a GUI (ie. bring the account on/offline), you will need the presence plasma dataengine and applet, available again from svn:

svn://anonsvn.kde.org/home/kde/trunk/playground/base/plasma/applets/presence
svn://anonsvn.kde.org/home/kde/trunk/playground/base/plasma/dataengines/presence

You can then add the applet to your Plasma workspace and use it to bring the account(s) created with the GUI in the previous section on/offline.

Nepomuk Integration

Your contact list is integrated into Nepomuk by means of the telepathy-integration-daemon. Best to install it and launch it before bringing any accounts online. Code, again is in svn.

svn://anonsvn.kde.org/home/kde/trunk/playground/network/telepathy-integration-daemon

You can run it by calling telepathy-integration-daemon on the command line.

Contact List App

Finally, in order to see our contact list, we need a contact list app installed. Currently, this is in the very early stages of development, but you can at least see a list of contacts in it (although you can’t interact with that list yet). Source code is at:

svn://anonsvn.kde.org/home/kde/trunk/playground/network/telepathy-contactlist (corrected)

and you can run it by calling telepathy_contactlist_prototype on a command line.

If you like what you see or have any problems with getting it working, come talk to us in #kde-telepathy. We’re very happy to help out

My company was really kind to get me a Macbook Pro (the 13.3-inch “5.5″ variant). It is an awesome piece of hardware! (especially after my own PoS HP laptop I’ve been cussing at for a while now)

That said, I still don’t like the idea of running a proprietary operating system on it (as beautiful as OS X is ;)), so I continue to happily use Gentoo. The standard amd64 install works just fine with some minor hiccups (keyboard doesn’t work on the LiveCD, kernel only shows a console with vesafb).

The one thing that did bother me is BIOS-emulation. For those coming from the PC world, Macs don’t have a BIOS. They run something called EFI which is significantly more advanced (though I think the jury’s out on quirkiness issues and Linus certainly doesn’t approve of the added complexity).

Anyway, in order to support booting other OSes (=> Windows) exactly as they would on PCs, Apple has added a BIOS emulation layer. This is how Ubuntu (at least as of 9.10) boots on Macbooks. Given that both the bootloader (be it Grub2 or elilo) and the Linux kernel support booting in an EFI environment, it rubbed me the wrong way to take the easy way out and just boot them in BIOS mode. There is a reasonable technical argument for this – I see no good reason to add one more layer of software (read bugs) when there is no need at all. After a lot of pain, I did manage do make Linux boot in EFI-only mode. There is not enough (accurate, easily-findable) documentation out there, so this is hard-won knowledge. :) I’m putting this up to help others avoid this pain.

Here’s what I did (I might be missing some stuff since this was done almost a month ago). The basic boot steps look something like this:

1. EFI firmware starts on boot
2. Starts rEFIt, a program that extends the default bootloader to provide a nice bootloader menu, shell, etc.
3. Scans FAT/HFS partitions (no ext* support, despite some claims on the Internet) for bootable partitions (i.e. having a /efi/… directory with valid boot images)
4. Runs the Grub2 EFI image from a FAT partition
5. Loads the Linux kernel (and initrd/initramfs if any) from /boot
6. Kernel boots normally with whatever your root partition is

Now you could use elilo instead of Grub2, but I found this it to not work well (or at all) for me, so I just used a Grub2 (1.97.1, with some minor modifications) (just adds an “efi” USE-flag to build with --with-platform=efi). While I could make /boot a FAT partition, this would break the installkernel script (it’s run by make install in your kernel source directory), which makes symlinks for your latest/previous kernel image.

Instructions for installing the Grub2 EFI image are here. Just ignore the “bless” instructions (that’s for OS X), and put the EFI image and other stuff in something like /efi/grub (the /efi is mandatory). You can create a basic config file using grub-mkconfig and then tweak it to taste. The Correct Way™ to do this, though, is to edit the files in /etc/grub.d/.

Of course, you need to enable EFI support in the kernel, but that’s it. With this, you’re all set for the (slightly obsessive-compulsive) satisfaction of not having to enable yet another layer to support yet another proprietary interface, neither of which you have visibility or control over.