pmck – A poor man’s clock

I have written another app based on Cairo and Xlib that should run on any UNIX variant (tested in Linux).

Poor Man’s Clock

That’s exactly what it is. An analog desktop clock that does nothing but show a clock face! It is however a halfway decent demonstration of the Cairo library in action, displayed on screen with Xlib.

Get it here.


FatDog Arm Beta 1

James (jamesbond) has released FatDog Arm Beta 1!

After being in the cooker for over two months, I can happily announced the next release of FatdogArm: the Beta1 release.

Release Announcement

Release Notes

FatDog arm is designed to run on ARM CPU supporting ARMv7-A instruction architecture. It is targeted at A10/Mele, A20/Cubieboard2, Odroid-U2/U3, OLPC XO-4 and OLPC XO-1.75 but with a bit of hacking can be adopted to other platforms, providing the CPU is compatible.

I have an Odroid U3 and while it is beta software it runs great. Plenty of software available in the repository too. It uses GSlapt/slapt-get for package management so it is easy to fatten up FatDog Arm.

Test away! (Bug reports here)

f2fs – booting linux on an f2fs flash drive

Today I had an eureka moment. I installed a full install of Slacko Puppy Linux to an f2fs formatted flash stick, booted and surfed the net. Has anyone done that yet?

The kernel is k3.4.52 patched with f2fs patches from Now Computing. I had to hack them a bit because the developer is only supporting k’s 3.0, 3.2, 3.5 and 3.8. I also patched the kernel for AUFS as we do in Puppy.

The unique problem here is that no bootloader supports f2fs at the time of writing. The work around is to first create a small boot partition in a recognised format such as vFAT, ext2, 3 or 4. Then you can boot the stick with grub (I used grub4dos). You could probably use syslinux, grub2 or even lilo.

In the boot partition you create a /boot directory that contains the kernel image (vmlinuz) and an initrd (in my case initrd,gz). Now in my kernel configuration I have all the relevant drivers that I need as builtins however using an initrd it would work just the same to have hid, usbhid, ehci-hcd, uhci-hcd and f2fs as modules and just load them. In fact, in my init script I have those loading anyway with the error sent to /dev/null. Of course you need a tree with the appropriate modules in the appropriate places, busybox, the necessary mount points and so on.

The real trick was to find the root partition which was on /dev/sdb2, however that would not work, nor would sda2, which probably should have since I wasn’t loading any other filesystems and the only builtin is ext2 (I was using FAT32 on my boot partition). My hard drive is formatted NTFS and ext4. I achieved this by using the UUID in the init script itself. You could just as easy have a config file that init reads.  Once the root filesystem is mounted you then switch root in to the running systems as with any other initrd.

Thanks have to go out to Barry Kauler for integrating f2fs into Puppy Linux infrastructure and for some of the code from his init script. My init script uses some of that but uses a directory structure based on Slackware’s initrd and some of the code from Pat Volkerding’s init script too.

I’ll post the code and documentation at a later date.

Any questions, ask in the comments.

Google… literal “cloud” computing

Loon (YouTube)

Google is going to the cloud, and beyond, literally.

Project Loon is an ambitious Google project with the aim of providing “infrastructure”, (used loosely) to developing markets (?) such that they can use the internet which we all take for granted (except at the end of the billing period  :-P). The basic idea is that several balloons are fitted with internet transceivers and launched into the stratosphere. Their direction is controlled by their level of flight. Wind current directions vary (apparently, see the links) at different altitudes so by controlling the balloon’s altitude relative to conditions *should* keep these mobile data transceivers within operable range.

Imaginative stuff!

Update on Google Drive Client (or lack thereof)

Well, most of us Linux users know that Google have not been forth coming with a Drive client for Linux. Why? Who knows? We’re told.. “It’s in the works”, “We’re working on it”, “Soon..” .. yeah, don’t hold your breath.

Some of the audience may remember my post about this from almost a year ago.

On G+, +steven C has created a G+ community (GoogleDrive4Linux, “ours”, not his :heh: ) and a petition which already has over 3100 signatures (that’s double since yesterday), GoogleDrive4Linux. This follows in the footsteps of +Kev Quirk‘s great work with his petition that amassed over 1800 signatures.


If you are reading this, use, or even like Linux, use or even like any of Google’s services then sign the petition! (link above).

Those of you that read my earlier post may remember Grive.

Grive is a 3rd party application to sync your Google Drive in Linux, command line based. It works well. I made a simple GUI for it using ROX-Filer, but that is very limited. The developers have added a new QT gui to the application, but it does have it’s limitations. For a start, I haven’t figured out how to use it! However it is in it’s infancy so we will leave any judgement on it’s usability and usefulness at the moment.

grive gui
The new Grive QT gui

As time allows, I may investigate this new development further, but really what is needed, is for Google to come to the Linux party and embrace a true Linux client.

Sign up folks and lets make Google listen!