Yesterday, Matthew Bloch, MD of Bytemark Hosting¹, tweeted:

next stop: no installations on your own computer from outside the walled garden. A free desktop is much more important.

He was referring to Apple’s announcement that they’ll soon be requiring all apps sold via the Mac App Store to implement sandboxing. Broadly speaking, this strictly limits what an individual app could do once installed - for example, it can’t access files outside it’s own area without going through the standard save and restore dialogs. Mac OS X’s younger sibling, iOS, has had even stricter sandboxing in place since it first allowed third-party applications. It also has another property, namely that the App Store is the only way to install applications under iOS. Matthew’s worry is that Apple’s adoption of one iOS policy (sandboxing) on the Mac suggests that they’re likely to adopt another, and forbid installation of non-App Store apps.

Personally, I think the two are separate issues. Sandboxing is a sensible policy in its own right. It’s a key component of the success of the iOS App Store - the fact that you don’t need to worry about the developer’s incompetence or malice before downloading that 69p impulse buy. Relatively few applications actually need to do things that sandboxing prevents, like alter system settings. For the rest, sandboxing allows the ease-of-use and convenience that iOS users have grown used to.

It’s not like sandboxing is even a new idea. Not only did Java applets (remember those?) give it a go in the late 90s, but Mac OS X’s own version has a lineage stretching back to chroot jails, introduced to Unix in 1979. The idea that every program a user runs has to be able to do anything that that user is not an absolute, and there’s nothing inherently wrong with a user choosing to restrict the facilities available to specific programs. All modern systems do this to an extent, by restricting root privileges to programs explicitly granted them. Sandboxing could be thought of as simply a more fine-grained version of the same idea.

Restricting installation to only the official App Store, on the other hand, represents a significant break from the current status quo. At present, if I want to install a random piece of software from some shady corner of the internet on my Mac, I am free to do so, and live with the consequences. Channelling all installations through the App Store (and Apple’s somewhat mercurial review process) doesn’t give me this option. For many users, who just want to get work done, and don’t want to worry about maintaining their computer, this might be a reasonable trade-off, but for others (such as myself), it is not. However, it’s important to remember that this isn’t an all-or-nothing distinction. For example, I’d want Galcon Fusion to be sandboxed, but still build Emacs myself. If I lose the option of installing arbitrary software, though, the range of things I could do on Mac OS as opposed to another system would be severely curtailed. I don’t think there’s much risk of this happening, for two reasons.

Firstly, the people that such a move would alienate - developers, designers, and those who see themselves as power users - are the sort of people who are willing to pay a premium for high-end hardware. Whilst not as numerous as general consumers, this group must still be a significant source of profit for Apple, and so they’d need a good reason to abandon them. Furthermore, many of these users are the very people who keep the App Store stocked with high-quality products. Driving them away would, in my opinion, be a significant own goal.

Secondly, and more importantly, why do they need to? Apple already sell a walled-garden OS for people who want it, and the devices that use it sell pretty much as fast as Apple can manufacture them. They don’t need to sneak a walled garden in via the back door, because they’ve already kicked down the front. My expectation is that Mac OS will be increasingly seen as a “Pro” platform, and iOS as the way for general consumers. This is arguably no bad thing, as it allows people to use computers for what they actually want to do without having to worry about servicing and maintaining them (I touched on this in a previous post). As John Gruber points out the Mac/iOS division allows Apple to cater for those of us who want the flexibility offered by a general purpose system, whilst not burdening everyone with the attendant complexity. And if at some point they choose to stop catering for us, there are plenty of others who will.

Update: Mathew has responded on his blog. He makes some interesting points. Most importantly, he points out that Apple already charges developers $99 per year. Root access could be restricted to these developers (and anyone who paid the fee could join them), whilst not providing it for regular users. The latter would effectively be handing over both the hassle and the control of auditing the software on their machine to Apple, a bargain that many people would consider reasonable (and one that most people already make with, for example, their email).

The fallout for developers would be that they could no longer rely on end users being able to install software themselves, and therefore everything would have to go through the App Store, with Apple taking their 30% cut. For many small developers, this again is a good bargain - the simplicity of the App Store, plus the trust user’s have in it, are worth Apple’s cut (and the small but non-zero risk of running into problems with the review process). However, as Matthew points out, big developers such as Adobe and Microsoft are less likely to be happy, and could go as far as abandoning the platform.

That’s a key reason I don’t think that Apple are likely to go down this route. Over the last decade, Mac OS X has gone from having the scantest selection of third-party software to having arguably the best. Part of this has come from the kinds of small commercial developers that are a natural fit to the App Store, but it also comes from big-name applications like Office and Creative Suite. Losing these applications would be a significant blow to the platform, and I’d be surprised if the additional App Store revenue would make up for it. Indeed, it’s not at all clear that there would be any additional revenue, given that the change would result in users leaving a Mac OS that no longer met their needs.

More importantly, the end result of this game makes no sense. Why would Apple turn Mac OS into another iOS, when they already have iOS? If people are choosing between a hassle-free/locked-down device (depending on your perspective) and a more flexible/fragile one, why would Apple not want a product on both sides? The only reason would be that one side doesn’t make enough money to justify pursuing. I don’t think that’s the case, but if and when it is, I wouldn’t expect them to turn Mac OS into iOS. They’ll just stop selling it.

In conclusion, I don’t expect Apple to remove the ability to install arbitrary applications from Mac OS in the foreseeable future, not through any moral compunction or fear, but simply because I don’t think it would increase their profits in the long term. I could be wrong about this; Apple clearly know their business better than I do. We’ll see.

In the past two weeks, there has - justifiably - been a lot of coverage of the death of Steve Jobs. However, two other computing pioneers have also died during that time. Dennis Ritchie and John McCarthy were not the household names in the same way, but their contribution was arguably more fundamental. Whilst Job’s work made modern computing accessible, Ritchie’s and McCarthy’s made it possible. They created, respectively, C and Lisp, which are essentially the Greek and Latin of programming¹.

In a field which values the new over the old to an almost pathological extent, these two languages have lasted for decades. If someone embarking on a new software project tomorrow using, say, PL/I, it would seem like an obtuse exercise in nostalgia. Use C, on the other hand, and nobody would raise an eyebrow. Lisp’s influence is less obvious, but arguably more profound. Whilst you can still use it in unadulterated form, relatively few people do. However, the popular dynamic languages that all the cool kids are using - Python, Ruby, JavaScript - are essentially Lisp in new clothes².

The origins of the two languages are instructively different. C was created to solve an immediate practical problem - writing Unix in a portable way. Moreover, it was targeting relatively modest hardware, the PDP-11³. It therefore lacks some of the bells and whistles that, even in 1973, “real” languages were thought to need. However, instead of limiting its scope, this resulted in an elegant simplicity that has seen it adapt to four decades of hardware improvements whilst many “real” languages have fallen by the wayside.

In contrast, Lisp wasn’t intended to be a language to solve a particular practical problem. It wasn’t intended to be a programming language at all. McCarthy had written a paper outlining a theoretical system for formally describing algorithms. Fortuitously, he didn’t make the “theoretical” part clear to one of his grad students, who promptly went off and implemented it on the department’s computer, creating the first Lisp interpreter⁴. What had started as a mathematical model of programs turned out to be an amazingly flexible and powerful way to actually write them.

What both languages have in common is that they each have a small, conceptually coherent core. Because it’s small and coherent, the programmer is able to internalise the basic concepts of the langauge. This done, they’re free to concentrate on the task at hand, rather than the details of the language. This is also why they’ve lasted so long - simple, clear ideas date far less quickly than specific technologies.

You might wonder why, in an post about two men who have recently died, I’ve not said much about their lives. The reason is simple; I didn’t know them, and so I’ll leave the biography to those who did. Like millions of other people, though, I do know their work. Both have had an enormous impact on a field that touches the lives of almost everyone, and will continue to do so for a long time to come.

Here’s a quick demo I’ve put together, showing the RaspPi running as a VNC client:

The setup is a slightly unusual one; instead of the client connecting to the server, it runs in listen mode, and the server initiates the connection. This allows the RaspPi to be used as a kind of shared, network display. The software on the RaspPi end is TightVNC, which is available in the Debiam ARM repository. On the server side, I used Vine Server, as the built-in server on Lion doesn’t support reverse connections (if you want to use the normal client/server arrangement, the built-in server is fine).

The reason that VNC supports this back-to-front arrangement is interesting in itself. ORL (later AT&T Labs Cambridge), the birthplace of VNC, also took a significant interest in location-aware computing, firstly with the Active Badge, which could track users to the granularity of a room, and then with the Active Bat, which could do so within a few centimetres. I worked at the lab for a year before starting my PhD (which they sponsored), in the project exploring the sort of applications you could build with this sort of technology.

One of the simplest and most effective was display teleporting. If you wanted to show someone your screen, you just held your Bat (or, in earlier versions, your Badge) against their monitor and pushed a button. Hey presto, via the magic of VNC reverse connection, there it was. Even though this application hasn’t exactly become ubiquitous, the reverse connection mode that was added to VNC to support it has remained a standard and useful feature. The location-aware technology lives on as well.

I’ve been lucky enough to get my hands on one of the Raspberry Pi alpha boards. I have various plans for things to try with it, but I thought I’d post some initial thoughts about the experience of using the board, and the project as a whole.

If you’ve not heard the name before, it’s a charity that aims to “promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing”. To this end, they’re developing a $25 computer. Not a toy, or a working model, but a real computer that’s cheap enough to give to kids without worrying about them breaking it. This isn’t just pie in the sky¹, either: they’ve already produced two generations of prototype hardware, and should be on course to have the final version in production, at the target price², before the end of the year.

The board, pictured below, has at it’s heart a Broadcom system-on-a-chip based around an ARM CPU, with 128MB or 256MB of RAM stacked on top. There’s very little else on the board - the slightly more expensive version has a single-chip USB hub and Ethernet adapter, but that’s pretty much it. This simplicity is how they’ve managed to hit the ambitious price point.

This kind of SoC is more often found in set-top boxes and the like, so it has reasonably good graphics and sound. It really is a complete system - you just plug a keyboard into the USB port, a TV (or monitor) into the HDMI, and you’re away.

On first booting the board, I was taken back. Not to primary school and the BBC Micro, but to my first exposure to Linux at University. The disk image I have boots to a console, and I found myself dredging up knowledge of things like runlevels and virtual consoles that I hadn’t used for years. My soft hands suitably re-calloused, I proceeded to poke around, install various packages (including, I admit, X Windows and LXDE), and generally having a play. The current OS image is based on Debian, and so hundreds of packages are only an apt-get away. The list isn’t as comprehensive as it is for x86, but there are still plenty of interesting packages (such as TightVNC) to install.

The thing that struck me as I used the Raspberry Pi was how familiar everything is. This isn’t some kind of esoteric embedded system, but a real computer, with a real OS, and standard languages and compilers right there, running on the board itself. Granted, it’ll never challenge the latest MacBook Pro in terms of raw horsepower, but for the intended use - programming education - it’s more than enough.

You could, of course, stick Firefox on the device, and get a dirt-cheap, tiny, low-power client for the web. There are also myriad things that become feasible when you can get a computer for the sort of money that Curry’s would charge for an HDMI cable not too long ago - smart screens, tiny servers, automation, and many others. You could even stick LibreOffice on it and equip a school computer lab for a fraction of the price today. However, doing so would miss the point.

The project stems in large part from the observation that fewer of the eighteen-year-olds arriving at Cambridge to read Computer Science had a good grasp off how computers actually work³. This is not, of course, to say that they’re any less bright, but just that their exposure to computers has been markedly different from that of those of use who grew up in the eighties (or even the nineties).

There are numerous factors behind this change, but a big one is the rise of the family computer. This is a device that has a myriad of uses - banking, shopping, gaming, watching TV - which means that parents are a lot less inclined to let an inquisitive seven-year-old poke around in it’s innards. A Commodore 64 or Acorn Electron, by contrast, was useful for… pretty much nothing, out of the box. Even getting a game to load involved reading the manual and getting some mysterious incantation just right.

This initial uselessness is not only part of the charm of early home computers, but also a key to their educational value. To make them do anything of interest, you had to program them at least a little, and this gave curiosity a way in. Even copy-typing listings from a magazine⁴ gives you the idea that, far from being some kind of magic, this box is something that could be understood if you put your mind to it.

Modern computers are increasingly black boxes, with a big implied or explicit “no user serviceable parts inside” notice discouraging people from wondering how they work. This is appropriate for tools that are increasingly central to our lives⁵, but raises the question of where the next generation of programmers and hardware engineers is going to come from. By providing a cheap, open machine that kids can tinker with to their heart’s content, Raspberry Pi are providing an answer. It’s not the complete solution, but it’s a big part of it. What they need now are software and ideas, and if you’re a programmer of teacher (or both) that’s something you can help with. You can also help by buying one of the final boards under their buy one, give one scheme. I’ll certainly be getting one or two.

I've still not quite got my head around the recent rioting. However, I can fall back on sarcasm. So, without further ado, and with a nod to the sadly defunct Brunching Shuttlecocks, I present to you 'Loot or Fiddle'. Simple decide whether the item or the quote in question relates to the 2011 rioting and looting, or the 2009 expenses scandal.