Welcome to the libferris screencast on copy append.
1) I start a copy from the command line.
2) I decide I want to copy another file to the same place.
For example to the same USB stick.
3) In the old days, I would have to start a parallel copy
or wait for the first copy to finish before copying
the second file.
4) Now, with libferris, I can just append it to the existing copy task for this destination.

Unfortunately the video quality is not so good in the final web version. Still some fun and games to be had getting things up to scratch.

Untitled from Ben Martin on Vimeo.

Automounting for the People

Now that the bad pun in the title has been read, you can't unread it!

So, now libferris has some closer HAL integration. Of course, some might say right away that ferris has been able to mount dbus for ages, so why have an explicit hal:// filesystem. The reason is that the fdo methods in the raw dbus interface for HAL are very coarse, and by explicitly having a hal:// and a volume manager daemon you get some interesting possibilities.

When the daemon can't work out what to do, it runs a nice little wizard:


One you choose how to identify the volume, you can tell libferris what to do:


More actions will arrive in time. I particularly like the auto copy mode, if a usb stick is readable at 20mb/s, a local scratch RAID-10 at 200Mb/s it makes sense to start moving the data to the scratch RAID right away and then pick it apart from there rather than from the USB stick directly.

Libferris summer hackfest

OK, so I now officially have one participant in the libferris summer hackfest! If you've been looking to help out a crazy filesystem project but hesitant as to who to approach, look no further... ;)

But seriously, if you have been using libferris and always wanted it to do X as well then now is a great time to help make it happen. Of course you could send patches, but you might be better off just buying some time and now is a great time to do the latter. And so ends the plugfest.

Unfsck your redland RDF.

Again, for those who are using the unpatched db4 redland backend, if you get issues where libferris apps just eat CPU and seem to hang, if your backtrace includes Ferris::RDF::RedlandIterator::__advance() calling librdf_iterator_next() then there is a fair chance your RDF db4 files are screwed. You can try to recover them with the below.... sorry about the long standing issue folks.

#!/bin/bash

cd ~/.ferris/rdfdb

for if in myrdf-po2s.db myrdf-so2p.db myrdf-sp2o.db
do
echo "Fixing: $if"
db_dump -r $if >| dump
rm -f $if
db_load -f dump $if
rm -f dump
done

No n810 is an island

Ch, Ch, Ch, Ch, Changes.

Yes, maemo has had rsync for ages. Yes, rsync makes dumping stuff to the device really easy. Trouble is, when you are travelling around for a while, and when you have a little keyboard you tend to update some of those files.

Assuming the OOM (Only One Me) rule, Unison is a great tool to make the n810 much less of a data island and more of an extension of the desktop.
Check out my repository for the debs. You'll need to install gcc and binutils, complements of the way ocaml is currently built. So thats another 15mb of downloads or 40mb of card space you'll loose. The gcc thing should be able to be worked around to make a leaner install, but I wanted unison for use before the maemo summit. Kind of handy to sync stuff over and know you can edit it with the device. Of course you could always rsync from the device when you get home again, but unison is just a nicer bidirectional solution.

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.