Rubénerd!

Don't you love headlines that can be answered so easily? From Infoworld, one of my favourite sources of whitepapers which I read for a hobby because I'm a nerd:

The Ponemon Institute's research study, entitled "The TCO of Software vs. Hardware-based Full Disk Encryption," claims to provide an answer. The study, conducted last year, polled more than 1,300 IT and IT security professionals in four countries -- the United States, the United Kingdom, Germany, and Japan -- for detailed information about their use of and expectations for hardware-based full-disk encryption.

Perhaps its because I had a long day, but I reread that paragraph at least five times, and I kept seeing "Pokémon Institute".

The results, recently reanalyzed with new insights provided in a follow-up paper, showed that full-disk encryption came at a fair cost, in big part because of the time and labor involved in deploying it. But the perceived benefits for using full-disk encryption far outweighed those costs.

An interesting read, but nothing surprising. Whole drive encryption would have added tremendous computational overhead to already slow machines back in the day, but today there really aren't any good [technical] reasons for eschewing (gesundheit) it.

From an enterprise perspective, the biggest arguments I've heard against it have been those initial deployment costs, and the added potential complexity for data recovery. That's not a problem though, because everyone backs up. R-right?

Then there's the issue of vendor support, or lack thereof. Mac OS X, the BSDs and all major Linux distributions ship with whole drive encryption as a configuration option, but Microsoft's BitLocker is only offered on the non-consumer flavours of Vista, 7 and 8.

It's regrettable Microsoft places more importance on artificial product differentiation than the privacy of their home customers' data. No catching 'em all today.

Perhaps its a remnant of my dial-up days, but I'm one of those old fashioned people that keeps local copies of all the stuff I download. Saves me having to download them again if I need to reinstall.

In the case of Xcode 4.x, components are downloaded and installed from the Preferences screen, but you can still keep the downloaded disk images by navigating to:

~/Library/Caches/com.apple.dt.Xcode/Downloads/

Ironically enough, I only remembered this again when I was going through my home folder backups, and realised my Caches folder was way larger than it should be.

After hearing about it on my beloved 5by5 Back to Work, I finally started using TextExpander. Today, I realised it can be used with my lifehacking language of choice.

Way of the future

TextExpander lets you assign blocks of text (or even images) to a shortcut you assign. For example, when I type ;nc it expands out to all my ncurses boilerplate. ;sig expands to my name, address, email, EARLs and phone numbers. You could leave it at that, and be crazy productive.

But you don't have to stop there. If you create a new shortcut and choose choose "Context: Shell Script" from the top of the editing box, you can write shell scripts to process stuff. I ignored it initially, largely for the same reason I eschew (gesundheit) most Western fast food. I can eat it, but I prefer other things.

Earning some Siracusa cred

On a hunch this morning, I decided to test the limits of this "Context: Shell Script" box and enter some Perl (which of course I inserted with its own TextExpander shortcut!):

#!/usr/local/bin/perl [...]
print("Hello, world");

When I typed my ;test shortcut, Hello was inserted in it's place.

Oh. My. SCIENCE.

That's right, TextExpander took the output from this Perl script, and used it in the substitution. Think of the possibilities. No, seriously, think of them.

I've used Perl scripts, a Dock shortcut and the Mac pasteboard to automate and send results to where I want since 2004. Now I'm going to go through them all and see how I can make TextExpander shortcuts for all of them.

For just over one week, I've moved from a Mac Pro, a 15" MacBook Pro and two X Series ThinkPads to an 11" MacBook Air as my primary machine. You read that right. So how is it working out?

Context

For the first couple of years of university, and subsequent staying home to look after my mum, my primary machine was a first generation 15" MacBook Pro. For a desktop replacement I could carry regularly between Adelaide, Singapore and Kuala Lumpur, its gorgeously large screen, discrete graphics and ExpressCard slot were wonderful. So much so, that I was willing to live with the burden of lugging a 2.5kg (5.6lb) device around with me in a giant bag, even when I was just heading to a local coffee shop or to classes.

Now that my university is the same place home is, the pressing need for a portable powerhouse evaporated. Despite being a fraction of the power of that MacBook Pro, I carried a ThinkPad X40 then X61s with Fedora Linux to university classes and coffee shops. For similar battery life, they were easily half the weight and meant I could take much smaller bags. For the heaving lifting, a refurbished Mac Pro had far more expandability, and meant I could dismantle my stonehenge of external drives.

The MacBook Air!

So we come to this gorgeous, lightweight 11" MacBook Air my sister and father generously bought for me for Yule. I could rave on and on about it over a long series of blog posts... so I will. Stay tuned for individual posts discussing specific experiences and technical specs over the coming weeks ^_^.

Ultimately though, as one can't gauge how delicious a meal is simply by the ingredients that go into it, the technical specs of such a device are secondary to how it actually feels to use. That's a pretty airy fairy statement for an IT professional to make, and certainly I'm aware the MacBook Air is no slouch, but to me this device represents a fundamental shift in the way I live my life.

This 11" MacBook Air is fast, the battery life is fantastic, and its so small and light I can throw it into my tiny backpack and almost feel as though there's nothing in it. That, its charger and my Amazon eInk Kindle already weigh less than the lightest ThinkPad I own, and less than half the weight of my MacBook Pro. Weight has been lifted off my shoulders in every conceivable sense.

Tradeoffs?

And yet, I don't feel like I'm losing anything. Quite the opposite, with this form factor I feel as though I can carry it around with me everywhere. I'm an odd fellow, and inspiration for code and prose come to me at the most bizarre times. The fact I can just whip out this tiny computer and throw my ideas onto it with Xcode, TextMate 2, Homebrew, OmniFocus, TextExpander, MacVim, Alfred and Parallels Desktop along with the Gimp, Inkscape, LibreOffice Draw, Dia and all my beloved shell apps and languages is just... it's indescribable.

Perhaps having heard me describe my ideal machine many times, my family opted to spend the extra money on upgrading the memory from 4GiB to 8GiB, rather than upgrading the stock 64GB solid state drive. It was a wise choice; having used ThinkPads with 20 and 30GB SSDs, I've become used to the idea of using portable computers for current projects, and using rsync to back them up to my Mac Pro with its masses of storage. The fact my MacBook Air now has more memory than my Mac Pro blows my mind! But technical stuff is for the next post.

Suffice to say, I'm a week into using this machine, and already I can't imagine my life without it. If that's not a sign of an indispensable device, I don't know what is. #boom.

When trying to use HandBrakeCLI to take a clip from movie, I couldn't figure out why it was ignoring the durations in seconds I was defining with --start-at and --stop-at.

Turns out, you need to append the word "duration", "frame" or "pts" before each value. For example, to create a 20 second clip starting at the 1 minute mark:

HandBrakeCLI [...] \
--startAt duration:60 --stop-at duration:20

Amazing what one can learn if one reads the manual page before wasting half an hour figuring out what's going wrong!

Pretty sure this isn't the most elegant way to do it, but setting the /Volumes directory immutable prevents volumes from auto-mounting:

% sudo chflags uchg /Volumes

Then to revert back:

% sudo chflags nouchg /Volumes
% echo The Bird is The Word

Despite being an OS X user since the first 10.0 betas, I know surprisingly little about how Macs handle volumes. Put me in front of a [purely!] FreeBSD, NetBSD or Linux box and I'm set, but Mac has its own way of doing things. Of course ;).

If QEMU 1.0 fails to build on Mac OS X (as I described on Sunday), you may be attempting to do it on a case-insensitive file system, like I just tried to do!

If you're installing QEMU on a case-insensitive file system, you'll need to modify the ./fpu/softfloat.h header file. Apply the patch from here, or simply open the file and add the following lines:

56 typedef uint8_t flag;
57 typedef uint8_t uint8;
58 typedef int8_t int8;
59 #ifndef _AIX
60 #if !(defined(__APPLE__) && defined(_UINT16))
61 typedef int uint16;
62 #endif
63 typedef int int16;
64 #endif

It should build without problems now, you unsigned integer you.

Given previous OS X upgrade experience, I decided to hold off from upgrading to Lion until 10.7.1 was released this time around. Alas, despite doing this there are still several issues severe enough to warrant me downgrading back to Snow Leopard until they're addressed.

But that makes no sense, you're a Mac fanboi!!1!!one!

So what are they?

1. Lion has been the first release of Mac OS X where my machine has been noticeably slower since upgrading. Applications take fewer “dock bounces” to launch, but more time. Scrolling is sluggish and key repeat rates are slower. Most maddening of all though are context menus: the current record is a whopping six seconds before they appear after a mouse click. OS/2 Warp 4.5 running on my 120MHz Toshiba Libretto displays menus faster than my Mac Pro with Lion does.

2. The Finder doesn't seem to have a memory leak, but it routinely chews up 70 to 90% of a single CPU core on idle. Killing it or force quitting drastically speeds up the machine, though only temporarily.

3. I have custom icons for my mounted volumes and drives so I can see at a glance which I'm working with. Lion's Finder sidebar replaces these with uniform drive icons in the same monochrome style as iTunes 10. From a glance, individual drives are now indistinguishable.

4. While I can appreciate Apple’s intention to make automatic backups and revision control easier for people, technically proficient users already have their own tools for this, and the lack of an option to disable this is frustrating. I suspect its responsible for some of the reduced performance and greater hard drive utilisation.

5. Related to this new feature, the removal of the one-step "Save As" and replacing it with the two-step "Duplicate" then "Save" function is one of the most maddening changes I’ve ever encountered in an OS upgrade. It was driving me so crazy, I gave up using Lion’s built in applications such as Preview and TextEdit entirely, and wrote symbolic links to redirect to other applications should I accidentally launch them!

6. After Mac OS pioneered the commercial GUI with a simple resize handle in the bottom corner of windows to change their size, Lion finally caught the all-edges-resize disease. It’s visually distracting having cursors constantly changing as I move them across the screen, and it increases the chance of changing windows by accident. To me, this was more of a feature to appease Windows-switchers than something useful, though I suppose I could get used to it. In KDE I overcame it by having all my windows full screen by default ;).

7. DigitalColor Meter.app only shows decimal RGB now, not hex. Why remove this?

Cue Arnold Schwarzenegger reference

One of the good things about Apple on the desktop is they tend to listen to our concerns. When Leopard came out, they quickly headed our cries for folder icons in our stacks, and opaque menu bars. There's nothing here that can't be fixed, provided we all keep giving them feedback. Not that it helped for some of these features given we voiced our concerns before the GM, but still...

In the meantime, it's back to Snow Leopard for me until at least the performance and reliability issues are addressed. 10.7.4 perhaps?

Patently Apple is reporting Apple is being sued for patent infringement with their new line of Macs. Specifically:

"A method for fast booting a computer system, comprising the steps of: A. performing a power on self test (POST) of basic input output system (BIOS) when the system is powered on or reset is requested; [..] C. storing the boot configuration information from execution of the POST operation before loading a graphic interface (GUI) program, based on the checking result; [..]"

Apple computers don't have a BIOS, and configuration data is stored after the GUI launches.

Apple has infringed many patents, but this should be dismissed on the grounds of dumbness. Is that an admissible legal defence?

The question seems to come and wane, but checking up on my long neglected TextMate newsgroups I uncovered a conversation regarding the future of TextMate 2. Again.

I've been everywhere, man

I've tried a lot of editors. On my Mac, I've gone from Smultron, to TextMate, MacVim, to JOE, another brief flirt with nano, and back to TextMate again. Vim is now my editor of choice for most work, but for projects nothing beats TextMate on the Mac. Allan Odgaard won an Apple Design Award for the software in 2006, and rightly so. It Just Works™.

In 2006, we got our first glimpse of the future 2.0 release on the official MacroMates blog:

I should also add that I am taking 10 weeks of vacation starting the 29th of November (going hiking in New Zealand), so even if I didn’t drop backwards compatibility, I wouldn’t have a 2.0 release before Leopard.

Little did we know that by that he meant before Leopard, Snow Leopard and Lion. Discussions about garbage collection in Objective-C 2.0 seem so distant and quaint now... remember how excited we all were about that? Those were the days :).

Crickets chirping

After years of talk about the improved features, in 2008 Allan stopped posting on his blog entirely, leading to an alleged torrent of questions about the project's direction. Finally, Allan responded with a new post entitled Working On It:

Over the past two years, posts on this blog have slowed to just a trickle, and a number of TextMate users have asked about TextMate’s status, or publicly worried about its future. This blog post, the first I’ve written here in a long time, is an attempt to assuage those concerns and answer some of the most frequent questions.

So where does development stand for 2.0? It feels to me like most of the modules are getting close, say 90%. But as they say, on the horizon, mountains look small. While I use 2.0 for my own work, day-to-day, and the basic infrastructure is pretty solid, much of the front-end still needs work, and for now it’s all lacking the spit and polish of a finished app. Hopefully an alpha version will be ready before too long, but I can’t make any promises about dates.

That was in 2009.

The V Word

After a few more months with little communication (somewhat justified given his social anxiety, but little communication nonetheless), rumours began circulating that the software was vapourware. A few threads on Digg (I presume, but I don't go there!) and Reddit were started, and the software was even featured unceremoniously in fifth position in Wired Magazine's Vaporware 2009 piece.

But it’s also been stuck in 1.x limbo for years. Lead developer Allan Odgaard got so tired of answering the barrage of questions about TextMate 2’s release — including from those wondering if it would ever arrive — that he broke months of silence by posting a long sob story on his blog titled, "Working on It."

The fall 2009 release of Snow Leopard brought more compatibility setbacks. It is perhaps no coincidence that Odgaard’s chosen tagline for his app is “The missing editor for OS X.”

In 2011, the story is the same

As I said in the introduction, TextMate has the mix about right for me. It works, I'm used to it, I have my own bundles, everything is peachy. Well, almost. For one thing it is a little unstable at times. The lack of wide character and true UTF-8 support is becoming a bit of a joke, and renders it useless for writing blog posts here that often have Japanese characters in them (anime posts and the like).

I've being doing a lot more work in Vim lately, and have recently rediscovered the NERDTree plugin, perhaps its finally time to think about moving over to it. Alternatively I could try using emacs seriously given TextMate was inspired by it... heck, I want a new email client too and emacs can do everything, right? ;).

I hope life is treating Allan okay, and that he doesn't lose too many people from this TextMate limbo.