Solipsism Gradient

Lamentations about the disappearance of classical “science kits” appear on the media every few years. Recently, the New York Times, Boing Boing and others wrote about it.

A chemistry kit from Kosmos (a German company that still makes them) was one of several my parents gave me, and I used it intensively for several years. Here’s a picture of the kit itself:

and here’s a list of the contents (in German):

(both pictures are courtesy of Hugo Rune). Several compounds, notably sulfuric acid, nitric acid and hydrochloric acid, were not sold with the kit – for safety reasons – and my father obtained them at his company. I soon learned that there were a few chemical supply houses in town, where I could buy extra test tubes, glass and rubber tubing, and replacement chemicals.

As far as “safety reasons” go, I believe that almost none of those chemicals would be allowed today. To quote one manufacturer of modern kits (from the New York Times piece):

Basically, you have to be able to eat everything in the science kit.

I suppose that for today’s kids, with their nanosecond attention spans, atrophied self-preservation instincts and parents who sue anybody at the drop of a hat, these precautions are necessary. For myself, I was used to seeing my father handle dangerous tools and substances in his workshop, and although I had a few scares with exploding reagents, nothing serious happened. For a few years – until I discovered that there were actual computers available outside of science-fiction books – I even thought I would pursue chemistry as a career.

Even so, this kit was extremely important and life-changing for me. At the time, my father still smoked occasionally – this was in the early 1960s. My kit included a simple glass aspirator pump (it’s not on the above parts list, for some reason), and I noticed that one of the glass tubes had a flared end that was the exact fit for a cigarette. I hooked the pump up to most of my glass tubes and soon had a primitive cigarette-smoking machine. The pump vacuum was strong enough that a lighted cigarette was smoked down to a nub in less than a minute! But the most impressive result was that the tubes were completely clogged with a black, foul-smelling, viscous substance.

Cleaning the tar out of my precious tubes made me strongly resolve to never start smoking in any form, and I think that my father stopped smoking very soon after seeing the results of that experiment. Maybe some educator should consider selling such smoking machine kits; the episode was certainly decisive for me.

I also fondly recall several other science/engineering kits from my childhood. My chemistry kit, unfortunately, no longer exists, but I still have the Märklin Metallbaukasten I got at the age of 3 (and even use it now and then)! I also had a Lectron Elektronik kit, several other electronic kits from Brazilian companies (Heathkits were, unfortunately, unavailable), and uncountable puzzles and educational games. We also subscribed to several magazines about such subjects.

In retrospect, I’m extremely grateful to my parents in making these and other materials available to me under difficult circumstances.

Update: just found a scholarly paper by Daniel Wolf about science kits (in German); very interesting.

 

Wow, today is the 10th anniversary of this blog; at least that’s the oldest post still preserved in my database. Most of the pieces were already in place in early 2002, but it took me some time to get everything running. At the time, I based the blog on phpbb, but a few years ago I migrated to WordPress; only the support forums, which get very little use these days, still use phpbb. Here’s a screenshot of the early days:

The cringe-inducing title was patterned after several similar ones I saw at the time; later on, no doubt under the influence of Iain M. Banks, I changed to the current “Solipsism Gradient”, which I still think quite descriptive. I’m still working up the nerve to ask him to use the name in an upcoming book, though…

But earlier versions were still more cringe-inducing, look at this one, from mid-2000:

At least I can safely say there’s no <blink> tag, and the animated GIF for the visitor counter was actually well-received; can’t really use it again as there are too few digits to be future-proof, but here’s what it looked like:

Well, life goes on. In a few days we’ll take a month off, flying in to Denver and driving around the parks between Mt. Rushmore, Yellowstone, Salt Lake City and Bryce Canyon. If all goes well, I’ll be able to work and post from underway. To coin a phrase, “we have cool things in the pipeline”…

Just saw this over at Amazon:

Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers.

…

Amazon EC2 changes the economics of computing by allowing you to pay only for capacity that you actually use.

…Start, terminate, and monitor as many instances of your AMI as needed, using the web service APIs.

Pay for the instance-hours and bandwidth that you actually consume.

…Amazon EC2 passes on to you the financial benefits of Amazon’s scale. You pay a very low rate for the compute capacity you actually consume.

…etc.

History repeats itself… this is very close to what we used to operate with in my mainframe days. You punched out a job control deck and ran a job that used a virtualized instance of the OS. Later on you’d get billed by so many seconds of actual CPU time, I/O bandwidth, and storage. In fact, my M.Sc.-thesis-to-be (1975, I vaguely remember) was about implementing just such a billing system.

So, half a dozen softwares are now out there that unlock the iPhone in various ways. In the simpler case, they allow the installation of various third-party applications and/or twiddling details. In the more complex case, they mess around with the various phone/SIM settings to allow the iPhone to be used with other provider’s SIM cards.

As I wrote before, Apple has apparently allowed this to happen by not implementing strict security measures. Now that the various unlocking techniques have stabilized, Apple has announced that an upcoming software update might cause “modified” iPhones to become “permanently inoperable”. Just a few days later, the iPhone update to version 1.1.1 came out; it featured the same warning in bold on its installation screen; and it did, indeed, cause some modified iPhones to lock up – the new vernacular is “bricked”, which I think somewhat of an exaggeration. Furthermore, the new software seems as tamper-resistant as the iPod touch software, indicating that Apple has checked out current unlocking techniques and implemented harder locks.

So far, all that was to be expected. What was, to me, unexpected was the reaction of some sectors of the press and of some users – mostly the same people who opposed the iPhone price cut, it seems.

Legally, it seems Apple is in the clear. The warranty and license agreement clearly say that any such tampering is at the phone owner’s risk. Surprisingly, some people seem to feel “entitled” to get warranty support even if they completely disobeyed the license! (Just as they felt “entitled” to have the price kept constant for a long period after they bought it, I suppose.)

The core of the argument seems to be “I paid for the machine, therefore I have the right to do whatever I want with it…” (I completely agree so far) “…and Apple has the obligation to give me full support, warranty and updates no matter how I mess with it!” Now here is where we part company. Sure, I suppose current consumer protection legislation may sometimes be interpreted that way (note I’m not a lawyer and less familiar with US legislation than with the Brazilian one); but you surely can’t pretend that Apple is a public utility or a non-profit charity.

Even from the technical standpoint, these expectations are unreasonable; allow me to explain this in more detail. The problem is one of “state“, in this case defined as ” unique configuration of information in a program or machine”.

In the first computers, the state of the computer was completely predictable when it was turned on: if it had Core memory, it was in essentially the same state it had when it was last turned off, and if the computer had reasonable power supply sequencing, you could just press the start button and continue. For more complex machines this was too hard to do, and the manufacturers declared that the machine was in an undefined/unreliable state after power-on, and that therefore you had to reload the software. For newer machines with semiconductor memory, everything was of course lost during power-off, and software reloading became equally necessary. To do so, you had to enter a short program in machine language using the front-panel toggle switches; this program, in turn, would read the actual software you wanted to run from a peripheral. This was the direct consequence of the machine coming up in a “null state”.

It wasn’t long before people thought of several ingenious ways to make this process more convenient. On the IBM1130, for instance, the hardware was set to read a special card from the punched-card reader, interpret the 80 columns (12 holes each) as 80 16-bit instructions, and execute them. The most commonly used of these cards simply repeated the process with the built-in cartridge disk drive, reading the first sector on the cartridge and executing it. Later on, the falling cost of ROM led to the boot software simply being built into the machine – the Apple II had a complete BASIC interpreter built-in, for instance. The apex of this evolution was the original Mac 128, where most of the system software was in the boot ROM – the system disk simply contained additions and patches. (The QI900 microcomputer I helped design in the ’80s had all system software, with windowing, multitasking and debugging, built into its ROM.) Here we had a well-defined “state” when the machine came up – it would execute a well-known program, and do predictable things, until external software came into play.

In the ’90s the limitations of this became apparent. OSes grew to a size beyond what could be stored in ROM, and no single Boot ROM could do justice to all models and peripherals (*cough* BIOS). Flash memory came up, the built-in software was renamed to “firmware”, and updates to that became commonplace. It was easy to “brick” a system if power went out or if you otherwise interrupted a firmware update before it was complete. In that event, a motherboard swap was usually the only solution, because the interruption left the firmware in a partial, nonworking “state”.

Consider now the iPhone. Its entire system (OS X 1.x) is built into firmware, mostly in a compressed state. This is expanded and run by the main ARM processor, obeying a built-in boot ROM. Supposedly, there are at least two more processors, taking care of network communications and of the cellular radio; each of these has its own boot ROM, and the radio processor has separate flash memory to hold state information regarding the SIM card, cellular system activation and so forth. One of these processors no doubt controls the USB interface to allow the main processor’s flash memory to be reloaded externally. Furthermore, every SIM card also has flash memory on it, containing the IMSI number, network identity, encryption keys and so forth, bringing one more source of complexity to the process.

In other words, you have a complex system of at least 3 processors interacting, each one with a boot ROM, two with flash memory containing state information. Powering up such a beast is a complex dance of each one waking up, testing its peripherals, checking its own state, then trying to talk to each other, then communicating to bring the entire system into a working state. Furthermore, the necessities of the cellphone system and of testing out such a complex piece of hardware mean that the iPhone must decide, on each power-up, in which of several states it’s in: factory testing, just out of the box, activated, reloading the main firmware, working, “plane” mode, and so forth. This is usually done by writing special values to reserved sections of the various flash memories, and of making sure they are always consistent with each other by checksumming and other technical arcana. Should they be found inconsistent, the system will probably try to regress to a simpler state and start over there, in the extreme throwing up its metaphorical hands and plead to be returned to the factory. Ideally, firmware writers strive to make it impossible to “brick”, unless an actual hardware defect occurs, of course; in practice, it’s rarely possible to envision all possible combinations of what could happen, and too few designers do assume a malicious agency is trying to trip them up at all times.

So, what do these various hacks do to unlock the iPhone? They rely upon bugs in the communications software, firstly, to make the system fall back into a state where it pleads for an external agency to reload its main firmware; cleverly substituted instructions then make it do new things. After several, progressively more complex, phases of this, new applications can be installed. Up to this point, only the main flash memory has been affected and installing a new software update will just bring the system back to the standard state. Now, one of the new applications may try to mess with the radio firmware; it will clear or set regions of it to bring the radio processor’s state out of step with reality, or even write bogus activation data into it.

Now, of course, the system’s state has been moved completely out of the state space envisioned by its designers. When it powers up, the state is sufficiently consistent – the various checksums check out OK, for instance – for the various processors to confidently start working. However, a few actual values are different from the intended ones – enough to let a different SIM card work, say. Now, if the hackers had the actual source code and documentation available, all this could be done in a reliable way. But this not being the case, they had to work by testing changes in various places and observing what happened, clearly not an optimal process.

Consider, now, the software update process. It assumes that the iPhone’s various processors and firmware(s) are in one of the known states – indeed, this is required for the complex cooperation required for uploading new software. If this cooperation is disrupted, the update may not begin – leading to an error message – or, worse, it may begin but not conclude properly. At this point, one or more of the iPhones processors may try to enter a recovery routine, either wiping the flash memories or to reinitialize them to a known state. No doubt this will be successful in most cases, and the new update will then be installable on a second attempt. However, the recovery may fail – since the exact circumstances couldn’t be foreseen – or it may be assuming false preconditions (like, a valid AT&T SIM card being present). The system will probably try to recover at successively lower states until falling back to the “can’t think of anything more, take me back to the factory” mode; or it may even lock up and “brick”.

Should Apple’s firmware programmers have tried to prevent this from happening? Well, up to a point they certainly did, as many problems other than hackers can cause such errors – electrical noise, badly seated or marginally defective SIM card, low battery, for instance. The system has to fail gracefully. However, it’s certainly not reasonable to expect them to specifically recognize and work around (or even tolerate!) the various hacks; after all Apple’s contract with AT&T certainly requires them to evidence due diligence in preventing that.

Firmware for such a complex system evolves continuously. The new 1.1.1 iPhone software seems to do many things differently from the original version, even though much of the UI is the same; same goes for the iPod touch software. Neither has been hacked as I write this. Did they now put TrustZone into operation? No idea; time will tell. My hunch is that Apple will eventually come out with an SDK for third-party applications sometime; the question is when. Perhaps after Leopard, perhaps at the 2008 WWDC. Does Apple need AT&T, or any partner carrier, at all? Maybe for now they do, and the unlocking wrangle will continue. In the long run, Apple will be better off with a universal phone that will work anywhere; possibly we’ll have to wait for the current generation of carriers to die before this happens. Interesting times.

It’s been about 38 years since I first saw a somewhat simpler version of this:

It’s still true, and still funny. Thanks to the excellent Dark Roasted Blend for reminding me.

I’ve been getting some positive feedback lately about my “Interesting Times” articles, so I thought I’d repost some pointers to them. The column itself is, sadly, now defunct, but new material crops up now and then; I’ve decided to post it here instead. In retrospect, the way this blog/forum is organized could use a few revisions, but that’s not likely to happen very soon.

So, “Highly Advanced But Obsolete” talks about the QI900, which was an 8-bit CP/M-based computer I helped design in the middle-80s:

…the Z80 was too slow for a fully graphical interface, and we hadn’t the mechanical know-how to build a mouse.

…here’s the final result: the QI-900 had menus…

…and moveable windows…

…and, even better than the original Macintosh, it had preemptive multitasking – or rather, multithreading inside the same application.

I promised a follow-up article with more details, but never had the time to do the necessary research. Maybe later in the year.

Everybody’s favorite seems to be, however, “This Internet isn’t worth anything…“, where I tell some stories about setting up a commercial ISP in the early 90s:

(At Embratel – that was the government’s telecomm monopoly)

Me: “I want an Internet connection.”

Embratel Salesman: “OK. I suggest a 2400 or 9600 link, the price will be X cents per packet. That’s 20% of what it costs to send a TELEX. Isn’t that revolutionary?”

Me: “A packet means how many Kbytes?”

Embratel Salesman: “What? It’s 64 bytes per packet!”

Me: “And if a user decides to download a larger file, say, 500 Kbytes? It’ll cost hundreds of dollars!”

Embratel Salesman: “Don’t worry, that will never happen!”