Converting OS X .plist to XML

The failure of my MacBook Pro seems that it didn’t cost much in terms on data loss, actually all the really crucial data were there. There are though some bits here and there that need to be moved over to my Linux box. One of the most important for everyday use the was the feed list for my RSS Aggregator. I was using the elegant, nice and simple NewsFire which uses binary plists (XML-like) for storing the feed list and I was never bothered exporting the feed list to OPML. The plist command in OS X can convert the .plist file into a .xml file, however I had no other Mac to do this operation or copy over the plist and export in OPML from there. Therefore I had to find a workaround for getting the plist working on RSSOwl or Liferea. Found the Perl plutil for Linux which converted the binary plist to standard XML. RSSOwl managed then to import the XML with all the blogs’ feeds as on NewsFire.

Regarding liferea, it wouldn’t import the XML file as it wasn’t proper OPML. But since RSSOwl imported the XMl file, I exported the feed list as OPML, which would be imported into Liferea or any other application.

Advertisement

An ARM comparison: Raspberry Pi vs OpenRD Client

Bellow there’s a comparison between Raspberry Pi (Model B) and OpenRD Client, two low-power ARM SoC (System on a Chip), running Linux (Rasbian and Fedora respectively). I used the EEMBC CoreMark benchmark with default settings for 100000, 1000000 and 2000000 iterations. For each set, each device keep its performance with the same rate of iterations per second. The difference between the devices is at, an average level of, 520 iterations per second. That translates to 1.4x faster in favour of the OpenRD Client.

While OpenRD Client performs better, in terms of efficiency, Raspberry Pi seems to doing much better. In terms of CPU, Raspbeery Pi uses a 700MHz (with the possibility of setting it up to 1GHz) ARMv11 processor while OpenRD Client an older 1.2GHz Marvell Sheeva (ARMv5TE). ARMv11 supports an FPU unlike ARMv5 and that is one of the reasons that Raspberry Pi performs quite well despite its lower specifications. In terms of memory, Raspberry Pi uses 256MB DDR2 800MHz (newer models have 512MB RAM), in share with its relatively powerful GPU, while OpenRD Client uses 512MB DDR2 800MHz. OpenRD Client also provides Gigabit Ethernet as well as many more I/O interfaces. Also, OpenRD has preloaded OS, unlike Raspberry Pi that boots from an SD card. During this benchmark, Raspberry Pi was running Rasbian “Wheezy” (unofficial Debian port to armhf) while OpenRD Client Fedora 8.

(Raspberry Pi diagram – http://www.raspberrypi.org/wp-content/uploads/2012/04/Raspi_Iso_Blue.png)

(OpenRD Client Hardware Block diagram – http://www.globalscaletechnologies.com/skins/skin_1/images/OpenRD-Client_back.PNG)

HFS+ on Linux

My MacBook Pro seems to have died. Its hard disk holds lots of data that have not been backed up anywhere else. The important data have been mostly backed up but latest changes haven’t been backed up. Other than that, I had to check the hard disk for bad sectors etc and since I don’t have another Mac to test it on I had to do it on my Fedora box. My system (Fedora 15) would automatically detect and mount the HFS+ hard disk on read only mode. It was also missing the fsck tool for HFS+ partitions. Getting the fsck tool for HFS+ required downloading and installing hfsplus-tools via yum.However, fsck.hfs will not allow you, except if you use the –force option, to scan the partition if it has journalling on, which is the case with HFS+ partitions by default.

But how would I turn off journalling when I don’t have a Mac system to attach my disk on? After a couple of minutes I came across a post on the Ubuntu forum which linked to this blog. The author has a C code that turns journalling off. A fixed version of this code can be found here. The compiled code results in an executable which gets as its only argument the partition that you want to get journalling off.

# gcc journalling_off.c -o journalling_off
# ./journalling_off /dev/sdg2

Next step was to perform the fsck check on the target disk

# fsck.hfs /dev/sdg2
** /dev/sdg2
** Checking HFS Plus volume.
** Checking Extents Overflow file.
** Checking Catalog file.
** Checking multi-linked files.
** Checking Catalog hierarchy.
** Checking Extended Attributes file.
** Checking volume bitmap.
** Checking volume information.
** The volume OS X appears to be OK.

Disk looks OK. Next step is to mount it with read-write permissions:

# mount -t hfplus -o rw,user /dev/sdg2 /mnt/osx

Next issue encountered was the different UIDs between my account on the OS X system and that on the Linux system. Therefore, next step was to change the UIDs under the whole user directory on the OS X disk so I could access without problem with write permissions from my Linux box:

# find panoskrt/ -uid 501 -exec chown panoskrt {} \;