untyped

Much has been written about the iPad since its launch. I’m sympathetic to the concerns about the closed nature of the iPad, and I think the iBookStore (along with the Kindle) is going to have a big effect on the book market, but I want to focus on something I haven’t seen much discussed: the A4 chip powering the iPad.

What you need to know about the A4 is this: at its core is an ARM Cortex-A9 MP CPU. ARM cores also power the iPhone and about every other smartphone out there. Intel just can’t compete in this market as their chips require too much power. This weakness is, paradoxically, a result of their greatest strength: the Intel instruction set. Even the most modern Intel chip still retains the ability to execute code for the ancient 8086. This ensures you can run just about any program ever written for an Intel machine on the latest CPU, giving Intel an enormous software base to leverage. However supporting this instruction set comes at a cost. The 8086 instruction set is not a good fit for modern CPU designs, and the instruction set has accreted decades of cruft to try and wedge modern features into it. To get acceptable performance all modern Intel chips have vast amounts of silicon devoted to instruction decoding; that is, the process of turning instructions into so-called micro-ops, which are what the CPU actually executes. All this silicon takes power, which is why ARM handily beats Intel on performance-per-Watt.

Now this wasn’t an issue for Intel even a few years ago. But we’re seeing three things that ought to make them worried. The first is the iPad, showing that little devices can grow bigger and perhaps move into the PC market, in much the same way PCs took over from the scientific workstations of Apollo, DEC, Sun and others. The second is the increasing concern for performance-per-Watt from people like Google and Amazon whose huge server farms power the major Internet services. The third is open source software, and particularly GCC’s support for just about every CPU on the market. This means the software can be easily recompiled for a new architecture. Suddenly Intel’s dominance doesn’t seem so assured.

So perhaps in a few years ARM will become the dominant architecture, rather than Intel. Apple have already shown that switching architecture (twice!) isn’t so painful. And as someone who has been writing an Intel assembler for fun I can’t say I see this as a bad thing.

In case you were wondering, we’ve moved our web presence to a new server (but still hosted by the most excellent Bytemark). The weblog was migrated/updated, and some things have moved around.

Our Feedburner RSS feed is the preferred way to keep up with the blog.

Scribular is a website and iPhone app that takes the idea of folksonomy, adds in GPS data from the iPhone, and gives you access to user contributed notes about the place where you currently are. The best part about Scribular if, like me, you don’t have an iPhone, is that it is written in PLT Scheme. It uses the LeftParen framework and you know LeftParen has to be awesome because it in turn uses lots of libraries from Untyped! Woo! Congratulations to Rob on launching. It is great to see another entrepreneur using PLT Scheme in a commercial setting.

Did I really just write Folksonomy?

• This Wired article, though not very deep, gives a nice overview of Internet business models.
• I don’t normally like rants, but found this one well written and amusing. Also, the Jakob Neilsen style bolding of important phrases: I think it works. Look for more strong on Untyping in the future.
• We’re going to London on Wednesday presenting at QMUL on the work we’ve been doing for the School of Biological and Chemical Sciences. If you fancy meeting up, drop me a line and we’ll see if timetables can sync.

From my study I can pick up about six different wireless networks. They all have simple names: the name of the router (good old Belkin54g is always up and always open), the street, the owner. But in West Hollywood that is not the way they roll. How about fuckyougetyourownnetwork, or my favourite, Lesbian_Dildo_Vagina_Party? Is this a cultural thing? In all my time in the UK I’ve never seen a network with names like those. On the other hand I am pleased to see one of the networks is named after me. What are the networks around you called?

Back from ICFP, but a full review will have to wait. Meanwhile here’s some stuff I saw today that interested me:

• Y-Combinator tattoo. Ouch! Comments on plt-scheme revolved around the choice of font.
• From the same discussion came a link to Gentium, which is a very nice font and is also free.

Dave and I, representing Untyped, will be at the Scheme Workshop, ICFP, and CUFP in Freiburg. If you’re there, do say Hi!

Just some quick links. It has been a busy day.

• [T]he human race publishes a book every 30 seconds. If current trends continue, by 2052 the number of people writing and publishing a book in a given year will exceed the number of people who will read one.

  From Design Observer

  . Last night I had my first foray onto eBay. As I surveyed the hundreds of professional sellers my stuff would be competing for attention against I thought I’d missed the boat on this one. Looks like I have a few years yet to impress any book-length ideas on the world, but the window is closing.

• Just everyone has linked to the Profit Calculator, which lightly skims over how a variety of NY businesses make money. Most interesting for me were the drug dealer, the yoga studio, and Nobu.
• Mark Fletcher asks if distributed development leads to better communication. Interesting idea. So far I’m undecided on the basis of our efforts.

Want to feel better? Think fast. A study shows that people forced to think quickly feel better:

[Emily] Pronin and … Daniel Wegner … experimentally manipulated the pace at which participants read a series of statements … The researchers found that regardless of the content of the statements, people felt happier, more energetic, more creative, more powerful, and more grandiose when they read the statements at a fast rather than a slow pace.

This type of behaviour is very similar to manic behaviour, so whether it is beneficial in the long term in debatable, but it’s at least an interesting result. Perhaps it explains why so many of us put off work till the last minute — we want the rush of working at a fast pace. At least we now have a plausible argument for such behaviour!

Currently, untyped lives on a virtual machine provided by Bytemark. The service they provide is excellent, and we recommend them highly. While we are building our own server we hope to continue to host with Bytemark, but instead of being on a VM, we’ll be on our own hardware. We’ll see how that goes.

Today, Christian and I spent a few hours working on the most fundamental part of a server: the filesystem. Before I go into any detail about the decisions we made, I’ll give you a sense for what we’re working with:

This server has seen use before, but we’ve replaced all the moving parts; we’re quite pleased with its condition, and think it will provide us with a number of years of good service. And, we hope that we don’t need to do a low-level install again in the next few years.

The first thing we did was to grab a Debian 3.1r1 “testing” net install CD image. We had to boot the 2.4 kernel, as the 2.6 kernel fails to load appropriate CD drivers from the install CD; this didn’t really matter. Then, we came around to our filesystem layout; what we knew was that we wanted to partition off different parts of the directory tree (/, /boot, /var, /usr, /tmp, /home); we didn’t know exactly how much space to give each part of the filesystem, however. Do we make home 40GB, or 60GB? What about usr? The list goes on and on.

We started by setting up a 4GB swap partition at the end of each drive, a 400MB boot partition at the front of each drive, and setting aside the remaining 245GB or so for the main parts of the filesystem. We then used the Debian installer to turn the 400MB partitions into one RAID set, and the 245GB partition into another. This way, both our boot partition and the main part of the drive are in RAID, but we’re guaranteed that our boot partition is at the front of the disk.

(What is RAID? I’ll stick with the Wikipedia on that one. It keeps our two disk drives in perfect sync; this way, if one of them fails, we might be able to replace it before the second one does, thus keeping our system running with little or no interruption. This is a Good Thing.)

Then, we dove into that big, 245GB space. We used LVM—the Logical Volume Manager–to partition the rest of the disk. LVM is great because it essentially ignores the physical layout of your disks, and allows you to dynamically resize partitions without any great gnashing of teeth. So, we laid out 40GB for /home and /data, 20GB for /usr, and 4GB each for /, /var, and /tmp.

Note that this is only 112GB of space; we had (roughly) 245GB of space in that big RAID set. Our intention is to grow those partitions as we need to. For now, we chose large, but reasonable values for each of these partitions. In time, we may decide to increase the amount of space allocated to /home—perhaps from 40GB to 80GB. The point is, we have around 116GB of space to “grow into”, and we can allocate it to any of the partitions we currently have… or we can create new partitions. In either case, these operations don’t require us to shutdown the machine, or even take it entirely offline—we only need to “stop” the logical volume that the partition is on.

While we could do this more quickly the second time around, this took us between one and two hours; we were careful to check our assumptions, and rehashed and discussed a lot of the decisions in light of how we might want to use the server in the future.

Once the filesystem was set up, the rest of the installation went quickly; things were pulled in automatically over the network, and we rebooted into our new machine. The filesystem looks great, and we expect that the decisions we made will serve us well in the future. Now, we’ll work on upgrading the kernel to a 2.6 series (with SMP support), and then begin replicating those services that currently exist on the VM to the server.

Links that came in handy:

• http://www.die.net/doc/linux/HOWTO/LVM-HOWTO-4.html
• http://www.die.net/doc/linux/HOWTO/LVM-HOWTO-9.html#ss9.9
• http://aplawrence.com/Linux/lvm.html