This rather Heath Robinson contraption (or Rube Goldberg, to our American readers) is from a picture I took around this time last year, when trying to diagnose a poorly RAID array.
This is the second mention of Billy Joel on this blog…
There’s an irksome problem which I’ve encountered on a few Linux boxen recently, whereby directories under /tmp/.private, such as /tmp/.private/root, simply cannot be deleted – even as root, nothing seems to be able to shift them!
This may only be an issue on installations which make use of the PAM ‘mktemp‘ module…
This is just incredible…
So Steam has now been released for the Mac. Whilst this is a massive step forwards for the Mac as a platform – finally giving Apple a credible position regarding gaming (after the 2007 deal with Electronic Arts, which didn’t even promise Mac native games but merely wrappers around Windows titles*, apparently went nowhere) – there are still clearly rough edges which makes Steam feel more like a late beta.
Having tried m0n0wall and pfSense without much success (I basically need a filtering bridge: with m0n0wall bridging WAN to OPT and with LAN disconnected, everything is fine until I enable traffic shaping, at which point the throughput reduces to almost nothing; with pfSense, I gave up on the third attempt at configuration because it had corrupted its own CompactFlash filesystem), I’ve decided to install Linux on my ALIX 2C3.
So far as I can tell, the iPhone SDK exposes no method to truncate an NSString to a given width (in pixels). This function obviously exists since it is used when drawing UILabels, and you can even draw truncated text with the method:
[cc lang=”objc” inline=”true” width=”0″ theme=”geshi”]
– (CGSize)drawInRect:(CGRect)rect withFont:(UIFont*)font lineBreakMode:(UILineBreakMode)lineBreakMode[/cc]
… but there’s no way to read-back the rendered text.
A quick search of the ‘net revealed some methods which would truncate a string based on the number of characters, but nothing to perform the operation based on the rendered width in pixels.
After succumbing to unbearable pressure (e.g. my Mum mentioned in passing that she was thinking about getting one…) and buying one of the new DSi XLs, the next task was to find a solution to playing all of the games I’ve bought since getting my original DS Lite several years ago – without the hassle of carrying around, changing, and then losing hundreds of tiny cartridges.
On the DS Lite, the CycloDS Evolution was pretty much a perfect solution for me – it was fast, stable, customisable, and frequently updated with the latest fixes and upgrades. Unfortunately, it was also completely incompatible with the DSi, and so also the DSi XL.
In order to find an acceptable solution which works on the DSi (and therefore the XL also – the two machines run identical firmware, and only differ physically in form-factor) I ended up ordering one card, and then another – and so it occurred to me that a comparative review could well be useful… especially since one seems to be very popular but really doesn’t work at all well, whilst the other takes some effort to get working but is really very good once it’s sorted out!
In December of last year, after only nineteen months of use, my 500GB Time Capsule died of a dead PSU. As documented here (a great graph, sadly lacking a scale on the y-axis…) the average lifespan of a Time Capsule was, for these first generation units, nineteen months and 20 days – and mine was only eighteen days short of this.
In any case, Apple offered to replace my out-of-warranty unit free of charge – but noted that they had no backup service to recover the contents. When asked, they did say that they were happy for me to dismantle the Time Capsule and backup the data myself though. Them’s fightin’ words 🙂
After a long slog ironing out some last-minute bugettes (and a major performance issue I’d accidentally introduced by attempting to bubble-sort an 10,000-entry strong list) I’ve just posted an updated release of Æther Tool to Apple for approval.
This is my first commercial app, admittedly, but it has taken a great deal of time, sweat, and (almost ;) tears to progress this far… and it makes me wonder how other small- or one-man developers approach the development process and how long this generally takes.
And now, following in the footsteps of the seminal “How 12 Hours, 2 Guys, 6 Cups of Coffee = 1 iPhone App there’s Sahil Lavingia‘s oneweekapp.com.