Conferences...

For those who haven't done seen it, linux.conf.au now has its CFP open, till 7th Aug. It was quite a tight window this time around, but if you already knew about the conference, you probably already have something to pitch to the call :)

IMHO it would be nice to see RDF/Nepomuk folk(s) and some maemo/moblin/i-rebrand mobile hackers too. So please excuse the dual syndication on the premise that some hackers might not have noticed the CFP but have cool stuff which just might be made cooler by chatting over a few beers in 30C summery weather.

Winning the West...

This morning I discovered that the UPS had played games during the night and my server was thus off. Turns out the machine endured a hard power drop complements to the APC 1500 UPS. I must say, less than impressed is a euphemistic rating for that particular rack mount UPS. On the other hand, the little 620VA APC unit I have works fine.

Anyway, so the server didn't want to boot, one of the XFS filesystems was wedged. Setting aside the fsck.xfs == nothing glory, at times you do need to xfs_repair. I've hit this once before, having to repair and zero the metadata log to regain mount ability. No log zeroing was needed this time it turned out.

The trick here is that during booting of a Fedora machine, if a local filesystem complains during fsck -A loud enough then you get offered a root shell assuming you have the password. Unfortunately, every character typed seemed to be taken as the password, so if root has a password of length > 1 char then you can't login this way. And with 20 local filesystems and no indication of which was the problem this makes for hours of bliss. Forget rides in the mountains, nice scotch, or a good book, Russian roulette with fsck is the edge of the seat fun way to spend a few hours.

Anyways, having a 4gb live Fedora USB stick helped. Having access to rpms for XFS helped too, and those were extracted and installed on the USB stick should the need arise again. For those finding this through the libferris internet searches, the command you are after is

rpm2cpio foo.rpm | cpio -id

to extract the foo.rpm to paths relative to the current directory. Though if that command escapes you then having a wedged ext? or XFS not permitting you to boot up would likely be an epic problem. FWIW I also managed to wedge btrfs into a charming state recently due to a non UPS backed power failure. This is not a slur on any of these filesystems. Trying to get performance and durability in the face of arbitrary hardware and firmware paths is not hard, its rock hard^TM. There is no substitute for a good UPS if you care about your byteses.

Take the Wrather With You...

If anyone in the maemo world knows of recent plasma packages for the n810, please drop a line or leave a comment linking to it from here.. The post is about Abomination, my perl/KDE4 code to grab and log data from the Australian Bureau of Meteorology and present it in an interesting way.

I notice that doppler wind is now available from the Australian Bureau of Meteorology. Also, I didn't notice the up to 512km composite rain maps before. The plan is to include support for both of these radar types into my KDE plasmoiods. I think having the doppler wind as a transparent overlay above the rainfall overlay would be quite telling, being able to see why clouds burst at given points.

Though this doesn't solve the deeper, more interesting question of if the system that is causing the interesting wind trend will remain for the next 2 hours while you are outside performing activity-Y and wanting to remain dry.

Perl io::all, REST, and libferris, wagging the dog

A feature that I've had planned to add to libferris since the UKUUG spring conference earlier this year is Perl io::all support. I've syndicated this because adding an io:all interface to KDE kio stuff would also be very cool IMHO.

I'm digging around for others who think io:all is cool and perhaps that libferris is "plus neutral" and might have some time to help out with the creation of a CPAN module to let the two things work together. In libferris there is a single shot interface to get metadata or file content as a single std::string or an std::iostream based interface allowing seeks, streaming and all that jazz. Ultimately I'd like to make the streaming stuff meet perl::io and also have a fake hash there to allow EA to get read on demand. The C++ and to a fairly large extent the Perl binding side I have knowledge of. But I admit to mostly being a Perl user rather than developer of the language or CPAN modules.

If anyone has pointers to stuff that would help out doing this stuff (tutorials and the like) or would like to support the feature in other ways please drop me a line or comment here. Otherwise, I'll probably dig into this later this year, time permitting.

I'm also thinking about making a REST server for CRUDing libferris. This should make Web clients much simpler to create, for example file managers in Yahoo widget UI. Once again, if this interests you, feel free to jump on in ;-p I'll have a survey of existing REST apis for this sort of stuff, obviously providing a similar interface will help other clients to interface. Luckily I can reuse some of the knowledge I gained when mounting web services as filesystems in the creation of the libferris web service server.