Structure and Interpretation of Computer Programmers

I make it easier and faster for you to write high-quality software.

Tuesday, October 13, 2020

Reflections on an iBook G4

I had an item in OmniFocus to “write on why I wish I was still using my 2006 iBook”, and then Tim Sneath’s tweet on unboxing a G4 iMac sealed the deal. I wish I was still using my 2006 iBook. I had been using NeXTSTEP for a while, and Mac OS X for a short amount of time, by this point, but on borrowed hardware, mostly spares from the University computing lab.

My “up-to-date” setup was my then-girlfriend’s PowerBook G3 “Wall Street” model, which upon being handed down to me usually ran OpenDarwin, Rhapsody, or Mac OS X 10.2 Jaguar, which was the last release to boot properly on it. When I went to WWDC for the first time in 2005 I set up X Post Facto, a tool that would let me (precariously) install and run 10.3 Panther on it, so that I could ask about Cocoa Bindings in the labs. I didn’t get to run the Tiger developer seed we were given.

When the dizzying salary of my entry-level sysadmin job in the Uni finally made a dent in my graduate-level debts, I scraped together enough money for the entry-level 12” iBook G4 (which did run Tiger, and Leopard). I think it lasted four years until I finally switched to Intel, with an equivalent white acrylic 13” MacBook model. Not because I needed an upgrade, but because Apple forced my hand by making Snow Leopard (OS X 10.6) Intel-only. By this time I was working as a Mac developer so had bought in to the platform lock-in, to some extent.

The treadmill turns: the white MacBook was replaced by a mid-decade MacBook Air (for 64-bit support), which developed a case of “fruit juice on the GPU” so finally got replaced by the 2018 15” MacBook Pro I use to this day. Along the way, a couple of iMacs (both Intel, both aluminium, the second being an opportunistic upgrade: another hand-me-down) came and went, though the second is still used by a friend.

Had it not been for the CPU changes and my need to keep up, could I still use that iBook in 2020? Yes, absolutely. Its replaceable battery could be improved, its browser could be the modern TenFourFox, the hard drive could be replaced with an SSD, and then I’d have a fast, quiet computer that can compile my code and browse the modern Web.

Would that be a great 2020 computer? Not really. As Steven Baker pointed out when we discussed this, computers have got better in incremental ways that eventually add up: hardware AES support for transparent disk encryption. Better memory controllers and more RAM. HiDPI displays. If I replaced the 2018 MBP with the 2006 iBook today, I’d notice those things get worse way before I noticed that the software lacked features I needed.

On the other hand, the hardware lacks a certain emotional playfulness: the backlight shining through the Apple logo. The sighing LED indicating that the laptop is asleep. The reassuring clack of the keys.

Are those the reasons this 2006 computer speaks to me through the decades? They’re charming, but they aren’t the whole reason. Most of it comes down to an impression that that computer was mine and I understood it, whereas the MBP is Apple’s and I get to use it.

A significant input into that is my own mental health. Around 2014 I got into a big burnout, and stopped paying attention to the updates. As a developer, that was a bad time because it was when Apple introduced, and started rapidly iterating on, the Swift programming language. As an Objective-C and Python expert (I’ve published books on both), with limited emotional capacity, I didn’t feel the need to become an expert on yet another language. To this day, I feel like a foreign tourist in Swift and SwiftUI, able to communicate intent but not to fully immerse in the culture and understand its nuances.

A significant part of that is the change in Apple’s stance from “this is how these things work” to “this is how you use these things”. I don’t begrudge them that at all (I did in the Dark Times), because they are selling useful things that people want to use. But there is decidedly a change in tone, from the “Come in it’s open” logo on the front page of the developer website of yore to the limited, late open source drops of today. From the knowledge oriented programming guides of the “blue and white” documentation archive to the task oriented articles of today.

Again, I don’t begrudge this. Developers have work to do, and so want to complete their tasks. Task-oriented support is entirely expected and desirable. I might formulate an argument that it hinders “solutions architects” who need to understand the system in depth to design a sympathetic system for their clients’ needs, but modern software teams don’t have solutions architects. They have their choice of UI framework and a race to an MVP.

Of course, Apple’s adoption of machine learning and cloud systems also means that in many cases, the thing isn’t available to learn. What used to be an open source software component is now an XPC service that calls into a black box that makes a network request. If I wanted to understand why the spell checker on modern macOS or iOS is so weird, Apple would wave their figurative hands and say “neural engine”.

And a massive contribution is the increase in scale of Apple’s products in the intervening time. Bear in mind that at the time of the 2006 iBook, I had one of Apple’s four Mac models, access to an XServe and Airport base station, and a friend who had an iPod, and felt like I knew the whole widget. Now, I have the MBP (one of six models), an iPhone (not the latest model), an iPad (not latest, not Pro), the TV doohickey, no watch, no speaker, no home doohickey, no auto-unlock car, and I’m barely treading water.

Understanding a G4-vintage Mac meant understanding PPC, Mach, BSD Unix, launchd, a couple of directory services, Objective-C, Cocoa, I/O Kit, Carbon, AppleScript, the GNU tool chain and Jam, sqlite3, WebKit, and a few ancillary things like the Keychain and HFS+. You could throw in Perl, Python, and the server stuff like XSAN and XGrid, because why not?

Understanding a modern Mac means understanding that, minus PPC, plus x86_64, the LLVM tool chain, sandbox/seatbelt, Scheme, Swift, SwiftUI, UIKit, “modern” AppKit (with its combination of layer-backed, layer-hosting, cell-based and view-based views), APFS, JavaScript and its hellscape of ancillary tools, geocoding, machine learning, the T2, BridgeOS…

I’m trying to trust a computer I can’t mentally lift.

posted by Graham at 08:54  

Saturday, June 13, 2009

WWDC wind-down

As everyone is getting on their respective planes and flying back to their respective homelands, it’s time to look back on what happened and what the conference means.

The event itself was great fun, as ever. Meeting loads of new people (a big thank-you to the #paddyinvasion for my dishonourary membership) as well as plenty of old friends is always enjoyable – especially when everyone’s so excited about what they’re working on, what they’ve discovered and what they’re up to the next day. It’s an infectious enthusiasm.

Interestingly the sessions and labs content has more of a dual impact. On the one hand it’s great to see how new things work, how I could use them, and to realise that I get what they do. The best feeling is taking some new information and being able to make use of it or see how it can be used. That’s another reason why talking to everyone else is great – they all have their own perspectives on what they’ve seen and we can share those views, learning things from each other that we didn’t get from the sessions. If you were wondering what the animated discussions and gesticulations were in the 4th Street Starbucks at 7am every morning, now you know.

On the other hand, it makes me realise that OS X is such a huge platform that there are parts I understand very well, and parts that I don’t really know at all. My own code spreads a wide path over a timeline between January 1, 1970 and September 2009 (not a typo). For instance, it wasn’t until about 2003 that I knew enough NetInfo to be able to write a program to use it (you may wonder why I didn’t just use DirectoryServices – well even in 2003 the program was for NeXTSTEP 3 which didn’t supply that API). I still have a level of knowledge of Mach APIs far below “grok”, and have never known even the smallest thing about HIToolbox.

There are various options for dealing with that. The most time-intensive is to take time to study – I’ve got a huge collection of papers on the Mach design and implementation, and occasionally find time to pop one off the stack. The least is to ignore the problem – as I have done with HIToolbox, because it offers nothing I can’t do with Cocoa. In-between are other strategies such as vicariously channeling the knowledge of Amit Singh or Mark Dalrymple and Aaron Hillegass. I expect that fully understanding Mac OS X is beyond the mental scope of any individual – but it’s certainly fun to try :-).

posted by Graham Lee at 16:01  

Saturday, May 2, 2009

Rootier than root

There’s a common misconception, the book I’m reading now suffers from it, that single-user mode on a unix such as mac os x gives you root access. Actually, it grants you higher access than root. For example, set the immutable flag on a file (schg I think, but my iPhone doesn’t have man). Root can’t remove the flag, but the single user can.

posted by Graham Lee at 13:36  

Thursday, January 1, 2009

What’s new in 2009

Of course, it’s a bit early for a retrospective of 2008, besides which I’ve already written 73 entries this year, my most prolific year to date on iamleeg. And that doesn’t count numerous tweets, stack overflow contributions and of course the occasional piece of source code here or there for some security company. As the noise of fireworks and exploding media players sounds across the world, it’s time to pre-emptively ditch 2008 and see what we can expect from 2009. Specifically, what you can expect from me.

It looks to me like the most popular pieces on this blog are the opinions and how-tos regarding Cocoa development, particularly my thoughts on properties and Cocoa memory management round-up. Don’t worry, there’s definitely more of this coming. As well as preparing for this Mac Developer Network conference talk I’ve been discussing recently, I’ve got another exciting – and unfortunately secret – project on the go now which should see plenty of collateral blog posting in the first half of the next year, all about Cocoa development. There’ll also be a bit more of an iPhone mix-in; obviously for much of last year the SDK either didn’t exist or was under non-disclosure, but now I’ve got more reasons to be using Cocoa Touch it will also be mentioned on here. I shall also be delving a bit deeper into Darwin and xnu than I have in previous times.

One example of Cocoa-related information is meetup announcements; I’m still involved in the local CocoaHeads chapter and I’ll endeavour to post an advance warning for each meeting here. I know many of my readers are in the States but a few of you are local so please do come along! In fact, if you’re not local (or “bissen’t from rond theez partz”, as we say here) then consider going to your nearest CocoaHeads or starting a new one. It’s a great way to find out who’s working on Mac or iPhone development in your area, share tips and stories and build up that professional contacts network.

Previously I’ve been concerned that readers here at iamleeg don’t seem interesting in commenting on my posts, but these days I’m no longer worried. I can tell how many people are reading, and of those how many are regulars, and I have to say that the blog is doing pretty damn well. Of course, if you do feel inclined to join in the discussion (particularly if I’ve got something wrong, or missed an important point from a post) then you should feel perfectly at liberty to leave a comment.

Finally, have a happy new year!

posted by Graham Lee at 03:47  

Friday, December 12, 2008

Whither the codesign interface?

One of the higher-signal-level Apple mailing lists with a manageable amount of traffic is apple-cdsa, the place for discussing the world’s most popular Common Data Security Architecture deployment. There’s currently an interesting thread about code signatures, which asks the important question: how do I make use of code signatures?

Well, actually, it’s not so much about how I can use code signatures, but how the subset of Clapham Omnibus riders who own Macs (a very small subset, as the combination of overheating batteries in the old G4 PowerBooks and combustible bendy-busses means they don’t stay around very long) can use code signatures. Unfortunately, the answer seems to currently be “not by much”, with little impression of that changing. The code signing process and capability is actually pretty damned cool, and a nice security feature which I’ll be talking about at MacDev 09. It’s used to good effect in the iPhone, where it and FairPlay DRM are part of that platform’s locked-down execution environment.

The only problem is, there’s not much a user can do with it. It’s pretty hard to find out who signed a particular app, in fact the only thing you can easily do is discover that the same entity signed two versions of the same app. And that’s by lack of interface, not by any form of dialogue or confirmation. That means that when faced with the “Foobar app has changed. Are you sure you still want to allow it to [whatever]” prompt, many users will be unaware of the implications of the question. Those who are and (sensibly) want to find out why the change has occurred will quickly become frustrated. Therefore everyone’s going to click “allow”, which rather reduces the utility of the feature :-(.

Is that a problem yet? Well, I believe it is, even though there are few components yet using the code signature information in the operating system. And it’s precisely that allow-happy training which I think is the issue. By the time the user interfaces and access control capabilities of the OS have developed to the point where code signing is a more useful feature (and believe me, I think it’s quite a useful one right now), users will be in the habit of clicking ‘allow’. You are coming to a sad realisation; allow or deny?

posted by Graham Lee at 00:37  

Monday, June 16, 2008

Local KDC on Leopard

via Nigel Kersten, a great description of the operation of Leopard’s built-in local KDC. I think the most exciting thing about the local KDC is the Bonjour support; could we see simple cross-system trust in the near future? Could there be someone in the world who can actually make Kerberos simple?

posted by Graham Lee at 21:28  

Sunday, March 23, 2008

Broke track mounting

For some reason, CDs occasionally don’t automount for me on my iMac. Luckily that’s easy to work around:
kalevala:~ leeg$ diskutil list
[…]
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: CD_partition_scheme Audio CD *620.3 Mi disk3
[…]
kalevala:~ leeg$ diskutil mountDisk disk3
Volume(s) mounted successfully

Job is, as they say, a good ‘un.

posted by Graham Lee at 10:53  

Sunday, February 17, 2008

Mach-OFS: aforementioned polish and functionality

It’s getting there, now has the ability to display load commands (though it only reports useful information for LC_SEGMENT and LC_SEGMENT_64 commands):

Again the screenshot depicts the OmniDazzle binary for no reason other than it’s a nontrivial file. The directions in which to take the filesystem are now numerous: I can add info about the remaining load commands (v. useful), the raw data for each segment (somewhat useful), and the sections in each segment (v. useful). Whether the filesystem will eventually get to the level of symbol resolution, I’m not sure :-).

posted by Graham Lee at 00:58  

Sunday, February 10, 2008

Mach-O FS (no really, MacFUSE does rule)

It needs some polishing and more functionality before I’d call it useful, then I have to find out whether I’m allowed to do anything with the source code ;-). But this is at least quite a cool hack; exploring a Mach-O file (thin or fat – in this case, I used the OmniDazzle executable which is a fat file) as if it’s a file system. FUSE of course makes it easy, so thanks to Amit Singh for the port!

posted by Graham Lee at 23:39  

Saturday, February 9, 2008

MacFUSE rules

One reason that microkernels win over everything else (piss off, Linus) is that stability is better, because less stuff is running in the dangerous and all-powerful kernel environment. MacFUSE, like FUSE implementations on other UNIX-like operating systems, takes the microkernel approach to filesystems, hooking requests for information out of the kernel and passing them to user-space processes to handle. Here’s the worst that can happen when screwing up a FUSE filesystem:

Now that might sound not only like a recipe for lower-quality code, but also like I’m extolling the capability to create lower-quality code. Well no it isn’t, and yes I am. The advantage is that now the develop-debug-fix cycle for filesystems is just as short as it is for other userland applications (and HURD translators and the like). This provides a lower barrier to entry (meaning that it’s more likely that interesting and innovative filesystems can be created), but also a faster turnaround on bugfixes (no panic, restart, try to salvage panic log… no two-machine debugging with kdb…) so ultimately higher-quality filesystems.

posted by Graham Lee at 22:06  
Next Page »

Powered by WordPress