Oh by the way, which one's pink?

This should be a really interesting conference. Right at a very exciting time for KDE, so I might be able to survive the event without an onslaught of comments on why I coded libferris instead of working on core VFS + Indexing code in KDE instead :-p~~. It will be interesting talking about nepomuk and the existing RDF+Inferencing that is in libferris. Perhaps everyone can benefit from metadata harvesting and cross communication of RDF data between KDE and libferris even if the codebases and projects are completely separate.

Ruby, don't take your love to town...

It seems that compiling a kernel for n810 devices involves a bunch of clean compiles, a little offering to the daimaou and some mules for the purple cat (now that I've included some nice narrow references Lou ;).

Issues don't seem to be related to the kernel image itself being too large, but compiling some functionality just seems to make the kernel kill the boot just before the desktop is displayed. These two pages are a good start along the merry road to a new kernel, even one that actually boots. Anyway, after a bunch of compile, download, try to boot cycles I found that you can have fuse, dm, encrypted filesystems, NFS client + server and xfs in a working kernel. I'm still trying to work out what parts of iptables state based filtering makes the kernel crap out.

But with the fuse and crypt stuff I should be able to have some fun making a nice front end to encrypt the internal 2gb sdcard... it will be interesting to see how much crypto impacts performance. I think /usr can be raw, but a bunch of the stuff in /home should be encrypted just because I don't want the guy who steals my n810 to read my email too ;-p

In other news, it sort of feels a little like the start of fight club, but instead of browsing furniture and other crap its hardware. 10G-BaseT can not arrive soon enough.

Trees, a forrest, some falling and an ear

Well, my desktop machine is now starting to actually work again after updating it to Fedora 9. "A charmer for the ladies" is the best description of the time trap that was... and still shall be for a few weeks I imagine.

I don't recall any previous fedora being as painful to update to. And then there is the kde4 issue, which I knew about before hand but didn't expect the outcome to be as it has become. So, the issue that finally forced me over the edge in a past GNOME release, not being able to fully hide the panel, was in fact the starter to drive me away from KDE, atleast as my desktop shell. I still love the apps of KDE4, I just use something else for my panel and desktop shell (no candy treats for guessing which wm/shell is at the core now).

It is a shame, I updated to the beta1 of 4.1 and somehow managed to get KDE wedged into a state where it just didn't want to start anymore. even with the old .kde that I started off with. hmm. Though the compositing and kwin stuff is very nice... fundamental things about panel interaction are just not there, or are rather hidden from the user, like being able to rearrange the icons in the panel.

And so it goes that another blog post has fallen, another rant was cut short in mercy for the wasted electrons.

A slightly more readable version of the data from the linux-raid mailing list. RAID-6 is the surprising one here, the rewrite performance taking the cake over all the RAID-10 configurations. So much for parity RAID being slow for writes ;-0

How now is soon?

Well, the main libferris site has now moved to libferris.com. And there was singing and dancing etc.

In other news, the maemo port is getting a little stronger. The db4 indexing modules can handle indexing about 15-20 music files / second on the device itself. Of course search is nice and snappy, but the lack of prelinking problem still remains slowing down actual process spawning. Ferris can now be compiled without Xalan-C which brings its footprint down a little on the device. Still a few other things I might trim off to make things a little nicer on limited hardware. The debs still weight in at about 6.3Mb which is quite chunky for a device with an initial filesystem size of 256Mb.

Still, using a forked child process an app can quite nicely fire off many index searches and sidestep the prelink issue after the initial exec() is done and dusted. Still no panel integration stuff but the fun begins once the port itself works acceptably. Mounting the GPS anyone?

libferris for the n810

So the virtual filesystem that mounts XML, db4, postgresql and even emacs now runs on the n810. There are some initial performance issues, Nokia seems to have decided to drop prelink packages which were in earlier maemo distros. This is quite annoying because small apps like ferrisls actually spend more time in the dynamic linker now than running on the 810. Nothing that can't be fixed with prelink on the n810 and maybe GNU Hash linking style as well. But these things are annoying because it means you have to probably replace your binutils on the device and install prelink from a third party repo (mine, most likely).

But the glory of running XUpdate XQueries on the n810 is still there. Federated indexing from the device instead of the "lets index everything in a static manner" that seems to be the MO for maemo apps at the moment.

I've not tested the mounting of flickr/23hq from the maemo build but having ferris on the 810 should let me integrate "send to" flickr items in application context menus. Once I get the performance issues under control then such handy integration will be on the cards.

Now all I need is a mokophone with 32gb of flash for media (I can dream eh?) so I can taint it with libferris as well.

I'll probably start a target for embedded ferris soon so that more server oriented things like XSLT and XQuery can be trimmed out to provide a smaller footprint VFS/Index solution.

The saru paws and the n810

I finally got one sitting on my desk. I've still to install the one true editor.

First impressions are good. It is quite snappy for a 400Mhz ARM chip. Relative to the e61 things are quite nice. The storage quickly becomes an issue. Luckily I have an 8gb microsdhc card in it, so data files can be taken with me but still I would like to have more storage on the go... but many have noted the blow of only one minisd slot relative to the two full sdhc slots on the n800. Luckily the n810's microUSB seems to work with USB OTG stuff. This will be interesting with 16gb usb thumb drives, being able to plug in a card with a bunch of data on it.

I've already done the whole dual boot by reappropriating the internal 2gb card to be the new boot drive. The 256mb root filesystem might be great for users who don't want to treat the n810 as a little linux machine, but for the serious hacker having a /partition that is over 1.5Gb makes for a much more enjoyable system to install software on.

One very surprising thing is that stuff like kernel side encryption of partitions is so hard to do out of the box. Encrypting /home on a laptop is standard practice, but with an n810, much more stealable than a lappy one would really *need* to have the data become unaccessible to any would be thief. Sure you loose a cool piece of hardware, but allowing someone who has just stolen your mobile device access to your little digital world is just a no go. I would have hoped that you could just install an extra kernel package like for NFS to get device mapper and ecryptfs and luks working without much pain. There are precompiled kernels and modules for luks but having nokia offer a bunch of kernel modules in grouped "kernel-extra" debs by default wouldn't be that hard for them to do and would make the whole process much easier.

I still haven't managed to get FUSE going yet. I guess sadly that it might be true that folks don't care too much about funky filesystems while on the move. But that won't stop me forcing libferris onto the device. Mounting postgresql, sqlite and XML from the n810 isn't going to be any less fun than from the desktop ;)