Lucid Nonsense


BumpTop for Mac

Thursday, 21 January 2010

I am starting to get really used to BumpTop, which is unusual for me because I normally don’t tend to use any interface tweaks. John Gruber mentioned it on Daring Fireball and I think he hit the nail on the head. He doesn’t find it too useful because he wants a better Finder in general, I find it brilliant because I barely use the Finder. My file organising generally involves piling things on the Desktop until it gets too untidy, and then putting everything into a “Desktop Clutter” folder. It’s similar to the way I manage my real desk, and operates on the “If it’s important people will start shouting about it” principal. I do file some things neatly, but they tend to be filed in a folder marked with a company name, so the quickest way to access them is always just typing the name into Spotlight.

So BumpTop works for me, it lets me pile things up and organise things very visually. Plus the faux-3D works well for how I use my Desktop. I have a lot of quick reference files on my Desktop (notes of IP addresses, common commands to cut and paste etc.). I like having them handy, but I don’t necessarily want to see them all the time. With BumpTop I can pin them to one of the side-walls, which lets me visually arrange things, yet not use up all my Desktop space as the side walls can be hidden to give you a more traditional 2D Desktop.

There’s a few things that could do with being improved, I’d like file selection to be tidied up a little and the “clean up” command could do with behaving more like Apple’s which arranges things in a more Mac-like manner and (for instance) always make sure that hard drives are displayed top-right. It is a promising start though.



Preview and CMYK Images in Snow Leopard

Sunday, 3 January 2010

An irritating error that I’ve come across before (but managed to forget about) is that Snow Leopard’s Preview will happily open a CMYK image with no indication that it can’t save them if you make a change to the file. If you adjust the image in any way and attempt to save you receive the amazingly helpful error message “The document … could not be saved”.

If you convert it to RGB first, then that’s not a problem, but obviously you need to firstly realise that it’s CMYK and if you’ve made a series of changes, and annotated the image, it’s annoying to realise when you come to save that those changes are gone and there’s not much you can do about it. As a result I’ve just started using Acorn for simple annotations and changes as it warns you if the image is CMYK and that it will convert to RGB when you save.



Merry Christmas

Thursday, 24 December 2009

I’d like to wish everyone a Merry Christmas and Happy New Year. 2010 here we come (and not a monolith in site).



HFS+ Compression in Snow Leopard

Thursday, 17 December 2009

One feature that made a relatively stealthy appearance in Snow Leopard was filesystem level compression, one of the tricks that allowed Apple to reduce the overall footprint of the release. This HFS+ Compression, detailed in John Siracusa’s excellent Snow Leopard article on Ars Technica, uses zlib to compress the file data, which is then moved into the files resource fork. All of the file access APIs in Snow Leopard have been updated so that the compression is transparent to users and applications, compressed files are automatically decompressed when required. Presumably it is an attempt to reduce latency that is a big reason for Apple’s system (by default) only compressing files under 20MiB in size - the time taken to decompress the files may start getting noticeable if they were of considerable size.

As mentioned in the Ars Technica article linked above this file system compression is not backwards compatible. Viewing a file compressed via HFS+ Compression in an earlier version of Mac OS X will just show a zero-sized file: the data is “hidden” in the resource fork, so HFS+ Compressed files viewed in 10.5 and below appear to be zero sized, and there’s no (easy) way to access the compressed data. This lack of backwards compatibility may be the reason that Apple haven’t exposed this feature to users; they have given no simple way to simply tell the system to compress part of the filesystem.

There is one way to compress files in the filesystem, using ditto. In Snow Leopard, on a HFS+ disk, this command would copy the folder ~/Documents/Archive to ~/Documents/Archive_compressed, while compressing the data:

ditto --hfsCompression ~/Documents/Archive ~/Documents/Archive_compressed

The Archive_compressed folder is still “live”, it can be browsed and files will look exactly the same, but in the background the system will be decompressing them whenever you open them.

Unfortunately this compression system uses a private API, so there isn’t an easy way for anyone to develop an application to let users get to this functionality easily. Fortunately, someone has managed to make a tool that does that. As detailed in this Macrumors thread, bkirch managed to reverse engineer the system calls ditto was making, and has created afsctool. This tool lets you specify different folders to compress, the settings used, and also lets you view details about which files have been compressed, and interestingly how much space has been saved by the compression.

There’s extra-overhead incurred in the background compression and decompression of these files, so you wouldn’t want to use compression exclusively across your entire system (and with the default settings only small files are compressed anyway) but for infrequently used files it’s definitely interesting. When I tested the compression level achievable with a number of 30-40GB folders of general files with a bit of a design tilt (including a fair number jpegs which won’t compress much further) I’ve seen reductions in disk space usage of around 30%. That’s not bad. Bear in mind that if you’re testing this with your own files, the Finder will always show the uncompressed sizes when you do a “Get Info” on a folder. The best option is to use afsctool with the -v switch, which handily shows the exact percentage saving the compression is making, the command is of the form:

afsctool -v ~/Documents/Archive_compressed

It would be nice if Apple gave more direct access to this feature, but in the meantime afsctool is useful, and it may be that this is simply a stop-gap feature until Apple’s new filesystem hits the streets.



VirtualBox

Monday, 30 November 2009

Virtualisation has come on leaps and bounds over the past few years and VMWare Fusion and Parallels Desktop are pretty common Mac apps these days. One free alternative that I haven’t tried for a while is Sun’s Open Source VirtualBox. I hadn’t tried it for a while primarily because last time I tried to use it I found it a bit sluggish and unstable. I’m glad to say though that having given the current version a spin it’s actually pretty good, although I may have had a better experience this time as a result of using OpenSolaris as the guest OS, so perhaps support between the two Sun products is unsurprisingly better than when attempting to run other systems.

The reason for the OpenSolaris test was actually a continuation of my trials and tribulations with ZFS, now of course sadly removed from Mac OS X due to licensing issues. I was testing whether it would be feasible to use OpenSolaris and ZFS as backend storage for some of our systems. While OpenSolaris seems pretty usable and obviously has a first party ZFS implementation, it’s going to take a bit of time to work out if it’s suitable. While ZFS is effectively the same as it was on OS X (although more up-to date), and OpenSolaris seems moderately easy to get to grips with, the big problem is going to be hardware support. With OS X it’s pretty easy; you buy Apple kit and look for Mac OS X support on interface cards, peripherals and software. There’s normally even a handy logo right there on the product page. More importantly I’ve also got a lot of experience in knowing which kit works best together and which kit has good OS X support. With OpenSolaris, not only do I have very limited experience of what works but without a first party vendor (unless we went with relatively expensive Sun systems running Solaris itself) I barely know where to start looking other than randomly searching on Google and OpenSolaris forums.

So, I’ll keep having a play but really I’m hoping that ZFS on OS X still has legs, and I’m giving at least emotional and hopefully some practical support to the brilliant team who have picked up Apple’s abandoned ZFS implementation and are trying to keep it alive. If you happen to be a Mac OS X kernel hacker, or brilliant filesystem engineer (sadly I am neither), please consider joining in, it’s a worthwhile cause!



The reason why

Sunday, 25 October 2009

Confirmation from Jeff Bonwick that puts the death of ZFS on OS X down to licensing issues. It looks like Apple had specific requirements from Sun and the two parties couldn’t agree on terms. I assume that indemnification against potential costs should Sun lose the lawsuit brought against them by NetApp is a big, if not the main, part of it.



Well at least it's official

Friday, 23 October 2009

The ZFS project at MacOSforge has now been officially shut down. At least it’s a definitive statement, only took them 6 months.

At the same time Apple are after a File System Engineer. Doesn’t seem like a coincidence.

So presumably we’re not going to get a modern filesystem for a while and I have a horrible feeling that what we’ll get will in fact be HFS+ with some extra features gaffer-taped on (“What do you mean it’s not as good as ZFS, it’s got snapshots, that’s like ZFS, right?”).

I don’t know if there’s any possibility of carrying on the project without Apple’s backing, I get the feeling that this set of events (including the terrible communications from Apple) has pushed a lot of the kind of people who could support a community backed ZFS towards alternate operating systems (FreeBSD and OpenSolaris both supporting ZFS).