My Green Life

I have to work on a Windows machine at work every day. It’s okay, I suppose, but it’s Windows with all that implies. I’m more of a Linux person - I find that I am far more productive in a Linux environment simply due to a user interface that works the way I want to. Because of this I also spend much of my working day using Linux - even going so far as to sometimes shuffle files over the network to the Linux box so that I can work on them in that environment rather than in Windows. Whilst I may occasionally shuffle files around, though, I don’t really want to spend all day shuffling myself back and forth between two machines. So I just connect to the Linux box remotely, and work with all my normal Linux tools from my Windows machine.

There are several ways to remotely connect to a Linux box and I don’t profess that this approach is any better or worse than any other - it’s just the one that I happen to use, and that works well for me. Please note, however, that the method I use (XDMCP) uses an insecure protocol - whilst it’s fine to use it within an internal network with a good firewall between you and the internet at large, it’s not at all safe to use when your machines are directly connected to the internet, or where your network may not be secure (e.g. a typical wifi connection, or you just don’t trust your co-workers). Don’t say I didn’t warn you.

Step 1: Get yourself a Linux box
It goes without saying that you’ll need a Linux machine to connect to - but I’ll say it anyway. It doesn’t have to be a real Linux box - a virtual machine running in VMWare Player or Virtual Box will do (other virtualisation products are available). In any case you need to ensure that you’ve got a network connection between the Windows machine and the Linux box (the venerable “ping” command should suffice).

If you are setting up a Linux box from scratch - whether real or virtualised - then I recommend Ubuntu, at least in part because that’s what the rest of this post is based on.

Step 2: Enable Remote Login
• On the Ubuntu box log in with an administrator account and go to System=>Administration=>Login Window
• Go to the “Remote” tab and from the “Style” popup select something other than “Remote Login Disabled”. I use “Plain” to cut down on the amount of data going over the network and because it works better with the rootless option I’ll be using later. I also turn off the Logo option, again to keep things simple and plain
• Close the dialogue

(click on the image for a larger version)

• While you’re logged into the Linux box you need to find out its IP address. There are several ways to do this, but in Ubuntu you can get this from the System=>Administration=>Network Tools application. You’ll need to select your Network Device from the popup menu near the top of the “Devices” tab - for a physical machine it’s probably eth0 or eth1, but for a virtual machine you might need a bit of trial and error. Once you’ve got an IP you should be able to ping it from the Windows machine to confirm that it’s the right value

Finally you’ll need to restart GDM for the changes in the “Login Window” dialogue to take effect. Rebooting the Linux box will do the trick.

Step 3
• Download a copy of Xming onto the Windows machine and install it
• Dig down in your Windows Start menu until you find the “Xming” option. Don’t launch it - you want to right click and select “Create Shortcut”. This will add an extra item to the menu, probably called “Xming (2)”
• Right-click on the new menu item and select “Properties”
• In the properties dialogue select the “General” tab and give the shortcut a more descriptive name. Then go to the “Shortcut” tab and edit the “Target” field to look something like this (all on one line, including the quotes - I’d copy and paste it if I were you):

"C:\Program Files\Xming\Xming.exe" :0 -clipboard -lesspointer -notrayicon -rootless -once -query 10.0.0.249

- The path should point to the real location of Xming.exe.
- Edit the IP after “-query” to be the IP of the Linux box you’re connecting to

• Apply the changes and close the Properties dialogue

Step 4: Your first remote connection

You should now be able to select the shortcut to launch Xming and connect to your Linux box. With luck you’ll be presented with a login screen, and should be able to log in.

If you don’t get a login screen then there’s clearly a problem. In my experience it’s likely to be one of two things:

1) The changes to enable remote login on the Linux box haven’t been applied properly. Check the settings in the dialogue, then reboot the machine to make sure that GDM gets restarted.

2) A firewall is blocking the connection. Temporarily disable any firewalls to see if that fixes the issue. If it does then you’ll need to open ports in your firewall to let the XDMCP connection through - but that’s outside the scope of this article (hint: at the least you’ll probably need to let UDP port 177 and TCP port 6000 through, search for “XDMCP firewall” or something similar for more details)

If you are having problems, make sure you quit any existing copy of Xming that may be running before trying again (right click on the taskbar entry and select “Close”). If you’re still having problems, bring up the task manager to ensure that there are no rogue XMing processes running which aren’t present on the task bar.

Step 5: Going rootless

If you’ve got this far then well done. You should now be able to log into your Linux box and use it as if you were sitting in front of it - with the exception of any fancy 3D or composited stuff (wobbly windows, spinning cubes, 3D games and so on) which unfortunately don’t work over a remote connection like this.

As you can see in the image above we’ve now got a full Linux desktop running, with the Windows taskbar at the bottom. Just above the Windows taskbar is the Ubuntu taskbar, showing the three Linux windows that are open. Conversely the Windows taskbar has just a single entry for Xming - all of the Linux windows live within a single “layer”. If you minimize Xming then all of the Linux windows go with it. Conversely if you bring Xming to the top of the window stack, all of the Linux windows come to the top as well.

For many people who just need a way to remotely access a Linux box, this will be good enough. But there are a some extra steps that you can take to make it a bit easier to switch between Linux and Windows.

• In Ubuntu press ALT-F2, type “gconf-editor” into the dialogue then press the RETURN key

• This should have launched Gnome’s registry-alike system
- Drill down to Apps=>Nautilus=>Preferences in the panel on the left
- Uncheck “show_desktop” in the panel on the right
- Close the window

• You should now find that your Linux desktop background has vanished. This is the result of using the “-rootless” parameter when launching Xming, and telling Nautilus not to draw the desktop via the gconf-editor setting in Linux. If you want the desktop back again, just re-check the option in gconf-editor.

In the screenshot above you can see the effect of disabling the Linux desktop - the Xming layer becomes transparent and your other Windows applications show through beneath your Linux windows. This means that you can easily bring a Windows application to the top of the window stack just by clicking on it. It also makes it easier to arrange your windows so that you can refer to the content of a Windows window whilst working in a Linux application.

The downside to this rootless approach is that you can no longer access any icons or mounted drives that appear on the Linux desktop. It’s not too bad, however, as the desktop folder is available from the “Places” menu, as are any mounted drives. For icons in particular you can always drag them to one of the Gnome panels if you want to have quick access to them.

On the subject of the Gnome panels it’s worth noting that they are highly customisable. With the default Ubuntu settings you’ll get two Gnome panels in addition to your Windows taskbar, but if this is too distracting you can remove one of the Gnome panels (or add others), move them around, or add various launchers and applications to them. A common option is to tweak it to a point where you have one Windows bar at the bottom of the screen, and one Linux bar at the top, making it easy to switch mental contexts between the two enviroments.

Step 6: Sharing a clipboard

Using the “-clipboard” parameter in XMing should allow the X-server’s clipboard (i.e. the Linux clipboard) to integrate with the Windows clipboard. Unfortunately this doesn’t work when you’re using GDM on the Linux end - i.e. the standard case for Gnome-based distros such as Ubuntu.

To fix this, edit the /etc/gdm/gdm.conf-custom file to include the following line just below the “[daemon]” line:

KillInitClients=false

(you’ll need to edit this file as an administrator - press ALT-F2 then type “gksudo gedit /etc/gdm/gdm.conf-custom” into the box, without the quotes)

You’ll need to restart GDM for the change to take effect (e.g. reboot the machine), but thereafter you should have an integrated clipboard between the two environments. It only works for copying and pasting text, but it’s still pretty handy.

In case you’re not aware, Linux systems have two clipboards. There’s a Windows-style clipboard that you can use via menu entries or the usual CTRL-C/V/X keyboard shortcuts. But there’s also a “quick clipboard” - if you highlight some text, then middle-click somewhere else, the highlighted text gets inserted. This can be very useful when you get used to it, but does pose some problems for clipboard integration between Windows and Linux, so here are the basic rules:

• If you highlight some text in Linux you can then switch to the Windows environment and paste it using the menu option or CTRL-V
• If you copy/cut some text to the clipboard in Linux, using the menu option or CTRL-C/X, you can then switch to the Windows environment and paste it using the menu option or CTRL-V
• If you copy/cut some text to the clipboard in Windows, using the menu option or CTRL-C/X, you can switch to the Linux environment and paste it by middle-clicking with the mouse
• If you copy/cut some text to the clipboard in Windows, using the menu option or CTRL-C/X, you can switch to the Linux environment and paste it using the menu option or CTRL-V
• When pasting into Linux make sure that you don’t highlight any text first - if you do, that text will become the new clipboard contents, as per the first bullet point. In other words, you can’t highlight the text that you want to replace then paste the clipboard contents in because the clipboard contents will have been changed by the action of highlighting. If you want to replace some text, delete it first then do the copy and paste.

Extra bonus tips

In the instructions above, where you edit the properties for the shortcut, there’s a “:0″ string. You can run more than one X server (i.e. more than one copy of Xming) on a single machine, by giving each one a separate screen number - “:1″, “:2″… (you’ll need to open ports 6001, 6002… on your firewall if you do this)

This lets you have more than one Linux desktop co-existing on your Windows desktop, which can be useful if you need to access multiple Linux machines for some reason. If you do this, then I recommend moving the taskbars to different locations and using different window themes for clarity - that makes it easier to keep track of which windows belong to which server.

You might want to consider putting SAMBA on the Linux box to allow your Windows machine to access files from it. Alternatively you could access a share on the Windows machine via the Ubuntu “Places” options (”Network” or “Connect to Server”), or by mounting the share with the SAMBA client tools. With the Gnome UI I’ve had most luck using the “Network” browser, then dragging my shared folder to the list of shortcuts on the left. Unfortunately not all applications like working with files that are accessed this way, but it is quick and convenient if you just want to be able to copy files between the two environments. Mounting a Windows share using the SAMBA client tools is a more widely supported means of accessing your Windows files from Linux, but requires more technical expertise to set up (see this page, for example).

Ubuntu has the ability to connect to an XDMCP server built-in. If you’ve enabled remote login on your Linux server as described above, then on another Ubuntu machine on your network press F10 at the login screen and select the XDMCP option. It will automatically scan for any XDMCP servers on your network and let you choose which one to use to log in.

You can even do this from the Live CD. Boot into it, then when the desktop comes up, log out (not shutdown) to get to the login screen, then press F10 as above. This can be very useful if you need to temporarily give people access to a Linux desktop but don’t want to install Xming on their Windows machines.

When you come to shut down the server you’ll find that there’s no option to do so via the XDMCP connection. You’ll need to shut down on the Linux server (or in the virtual environment) itself - use the “Options” (F10) menu on the Ubuntu login screen. Alternatively you can remotely log into the server’s command line using “ssh” and shutdown that way, if you know what you’re doing.

Yesterday I stumbled across this post about showing favicons for bookmarks which appear on the bookmarks toolbar of a Mac version of Firefox. This reminded me of a long-standing bugbear I’ve had with the bookmarks toolbar: sometimes I want to create a bookmark without a favicon.

This may seem like a strange thing to want - after all, the presence of a favicon makes it easier to identify specific bookmarks by sight so is, in general, an improvement to the user interface. However there are a couple of possible reasons for wanting the favicons gone:

1. Sometimes they don’t actually help you to recognise the bookmark
2. They take up space in the toolbar that could be better used by an additional bookmark

The first problem is usually a result of bookmarking a site that doesn’t provide its own favicon. Firefox simply uses a generic favicon for these bookmarks, which does nothing to help you uniquely identify the bookmark in amongst a sea of similarly generic icons. You also get the generic icon if your bookmark isn’t to a site, but rather to a bookmarklet.

The second problem is simply one of space. The space on the bookmarks toolbar is limited, and using it to display favicons that aren’t useful is just wasteful.

My particular issue is a combination of both of these problems: I have a few bookmarklets on my toolbar which I’ve taken from the Pornzilla website. The site itself contains no pornography, just a collection of bookmarklets and links to extensions which make it easier to surf the web for porn - however what works well for porn also works well for images and links in general, so I find that some of the bookmarklets there are handy for day-to-day browsing as well. In particular I have the following five bookmarklets on the left of my bookmarks toolbar:

Look at the labels I use. Short and to the point. So short, in fact, that the addition of a favicon causes the bookmark buttons to be twice the size they need to be. Here’s what the left-hand end of my toolbar looks like by default:

For those of you that don’t know, the user interface of Firefox - including the bookmarks toolbar - is specified using a language that is similar to HTML, the language used to write web pages. It’s also possible to style it using CSS, the same language that is used to add styling to HTML. So if you know how to write CSS (which I do), it’s possible to override the default Firefox user interface quite easily. In fact they even provide an official way for you to do this: the userChrome.css file.

I won’t go into a lot of detail about the userChrome.css file, but suffice to say that any CSS in that file can be used to override the default Firefox styling. The file doesn’t exist by default, but there’s an example file provided with Firefox which lives in the correct place on your hard drive: details of finding that file can be found here.

Once you’ve found the right place on your hard drive, and created a userChrome.css file, simply put the following CSS in there to get rid of those pesky favicons:


@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); /* set default namespace to XUL */

.bookmark-item[label="+"] > .toolbarbutton-icon,
.bookmark-item[label="-"] > .toolbarbutton-icon,
.bookmark-item[label="< "] > .toolbarbutton-icon,
.bookmark-item[label=”>”] > .toolbarbutton-icon,
.bookmark-item[label=”NL”] > .toolbarbutton-icon
{
display: none !important;
border: 1px solid red !important;
}


The main thing to note is that the label that you provide for a bookmark in Firefox is actually applied to the “label” attribute of the bookmark - which is a fancy HTML way of saying that you can make your CSS match particular bookmarks by using code like that above, where the “label” parts of the first few lines are populated with the actual labels you’re using in your bookmarks.

The result of this jiggery pokery, after restarting Firefox, is a bookmarks toolbar that looks something like this:

Much better

I haven’t posted anything in this blog for a few weeks now for one reason: I decided to move the domain to a new ISP.

Now you might think that this should be a simple task - taking a few days at most. And you would be right, it should be a simple task. Unfortunately in this case it wasn’t.

So here I am, 18 emails and 6 weeks later, finally able to report that the domain has moved and that usual service can now be resumed. Of course, “usual service” still doesn’t mean that I’ll be writing very regularly - but at least now it will be due to laziness rather than technical issues.

Many years ago one of my colleagues purchased a Dell server complete with an expensive SCSI-based tape backup system. About a year ago we began to have recurring problems with the tapes, and the drive itself started to get very fussy about which tapes it would actually use. Due to the age of the drive it also only supported relatively small capacity tapes, compared with current hard drive sizes. There was much discussion about whether or not to replace the drive with a newer model, but one thing quickly became clear: a new drive, plus a new collection of tapes, was going to be very expensive.

So I suggested that we simply buy a number of external hard drives instead. They all connected via USB, so could be hot-swapped as needed - and because all of the drives were identical we only needed to have one power supply and one USB cable available. Everything worked well, the capacity of each drive was far in excess of the old tapes, and the backups completed more quickly than before.

A few days ago one of the SCSI hard drives in the server died - not one of our USB backup drives, but one of the drives in the machine itself. The server was pulled out from our collection of servers (not an easy task - it’s a heavy box in an awkward location), and attempts were made to recover what data we could from the drive. In practice there wasn’t much on there worth saving, so we decided to ignore it.

Then the problems began. We plugged in a USB drive for our nightly backup, but by the morning the backup was still going. We restarted the backup process and tried again… the backup was running very, very, very slowly. Wild theories and speculation began: perhaps the network connection in the server’s current location was problematic, causing the data throughput to be throttled. We moved the big, heavy server back to its awkward location alongside the other servers and tried again. Still the backup was slow.

Perhaps the dead SCSI drive was somehow to blame. Could it be putting erronous data on the bus, causing the processor to be so burdened with error messages that everything was being slowed down? We removed the big, heavy server from its awkward location and removed the errant drive. We even cleaned out the dust bunnies (though they were so large that perhaps “dirt pookas” would be a better description). Still the backup ran slowly.

We were about to boot from a Knoppix CD to rule out Windows configuration issues when someone spotted the problem. As I mentioned at the start, this machine was purchased many years ago. So many years, in fact, that the USB ports were all USB1, which has a maximum data rate of about 12 Mbit/s (1.5 MB/s) - i.e. very, very, very slow.

When we first switched to using the USB drives for backups we were aware of this limitation, so bought a USB2 card for the server. USB2 allows for a theoretical data rate of 480 Mbit/s - i.e. about 40 times as fast as USB1. The underlying cause of our problem was quite simply that someone had plugged the backup drive into the wrong socket.

Ignoring the embarrassment of three otherwise technically-competent men taking several hours (and two unnecessary moves of a heavy server) to spot the problem, I’d like to focus on how this problem occurred in the first place. You see, in their wisdom, the designers of USB2 decided that it should use identical sockets to USB1. I wouldn’t mind this if the two systems were similar - perhaps with USB2 being twice as fast as USB1 - but we’re talking about radically different things here. Yes, they might share some technical details, but to all intents and purposes USB1 is for slow devices - mice and keyboards - whereas USB2 is for much faster devices - hard drives. Up to 40 times faster.

When two sockets offer such radically different levels of performance then I, for one, would rather see a break from the old standard with the introduction of a new socket. They could be made electrically compatible, so that a small and cheap adaptor would suffice for those people who really do want to plug their USB1 mouse into a USB2 port, but a slight mechanical difference would have saved us many man-hours of work.

Better still, they should have abandoned the idea of USB2 before it ever really got off the ground. USB for mice and keyboards, Firewire for hard drives and other fast connections. Two different standards for two radically different requirements. But I guess that would have made too much sense.

I’ve finally got around to upgrading the copy of WordPress that powers this blog from the rather ancient version 1.5x that I had been using, to the latest stable release. The main improvement, from my perspective, is that it now comes with a plugin to automatically filter out the hundreds of spam comments that I was having to deal with each week.

With less time spent on spam fighting, maybe I’ll find the time to actually post here more frequently. Then again, knowing how much of a procrastinator I am… maybe not

The Newton 2100 had so many great features that it’s impossible to list them all in a simple blog post. Given that this is one of a series of posts about pen-based computers and PDAs, however, I’ll focus on a few points that individually seem relatively minor, but which between them show just how much care and attention the Apple engineers paid to the Newton platform.

The Newton was designed from the ground up to be used with a stylus, and to be used on the move. Unlike so many devices that have followed it, the Newton had no pretences at being a desktop machine. There was no attempt to shoehorn a desktop UI into a handheld device; instead the whole system was designed around the stylus, rather than simply trying to use it as a poor mouse replacement. Text and images were deleted by simply scribbling through them. Handwriting could be recognised on-the-fly, or deferred for recognition later (ideal for taking notes without the recognition slowing things up), and there was even a mode for recognising hand-drawn sketches which would transform my rough scribbles into perfect lines, squares, triangles and even circles.

Having created a modernist masterpiece (or more probably sketched a map) it was extremely simple to edit and change the design. Pressing the stylus to the screen for a couple of seconds elicited a small squeak from the speaker, and switched the Newton into selection mode. Drawing on the screen in this mode produced a thick line which could be used to circle multiple items for selection. Tracing over individual lines - or parts of lines - would also select them, so having drawn a square, for example, it was easy to select just one side of it for removal.

Once selected items could be moved by dragging, resized by dragging one corner, or deleted with a quick scribble. Dragging selected text or drawings to the side of the screen caused a smaller translucent representation to be docked there which could be dragged back into a different application - copy and paste using only the stylus. An extension for the 2100 allowed you to access a hidden OS preference to set the number of these docked items that could be held at once - up to a maximum of 20. This made it simple to copy and paste multiple different items without losing track of any of them. How I wish that this feature was implemented in a desktop system.

The attention to detail in this pen-based system even went as far as the hardware design. Not only did the 2100 have a full-sized and very comfortable stylus that clicked satisfyingly into a sprung chamber in the body of the device, but they also included a small pull-out stand to rest the stylus in when it wasn’t in use. Again, this is a small thing that’s sadly lacking from most modern pen-based systems.

Finally, still on the subject of hardware, it’s impossible to really consider any mobile device without giving some thought to its battery life. This is one area where the 2100 really did excel. Whilst its green-backlit greyscale screen might look primitive compared with more modern full-colour devices, it had one huge advantage: low power consumption. With just an hour’s charge the 2100 could nominally run for 24 hours with the backlight off. In practice the battery life was less than this, but the way in which a PDA is usually used - just a few minutes at a time - meant that a single charge could easily last a week, or even a month. Travelling overseas and worried that the charge might run out? No problem, just use the Newton’s international charger with simple slide-on adaptors for different power sockets. Or just take the battery tray along with you and rely on easy-to-obtain AA batteries instead.

What if the worst did happen, and your poor Newton ran out of power completely? Thanks to the early use of flash memory in the 2100 it wouldn’t lose any data. When you finally found another power source, your Newton would boot up with all your data intact. Which is something that definitely can’t be said of the Palm Pilot…

Fast forward to 1997. I’d finished university and had a real job. It was also one of those rare periods when I had no significant financial burdens. With no major outgoings, and fresh from the penny-pinching days of studenthood, I seemed to have a lot of spare cash floating around. What was a man to do, other than spend stupid amounts of money on new tech?

So I found myself traipsing off to the (not very) local Authorised Apple Reseller to have a play with a Newton 2100. This was the latest and greatest of the Newton line: a king amongst PDAs - with a royal price tag of £699. I may have had money to burn, but not even I was stupid enough to pay full price to an Apple reseller. My trip there was simply to try the 2100 out, to make sure that the upgrade of the operating system hadn’t ruined the things that I’d come to love about the MP100. I wasn’t disappointed - although the salesman at the shop definitely was.

I had a couple of friends who were also impressed by the MP100 - but not £699 worth of impressed. They decided to buy a Newton 120 each - the same basic operating system as the 2100, but with significantly less powerful hardware. The three of us pooled our money to make a single purchase with a mail-order company in order to negotiate a better deal. So it was that in December 1998 my Newton 2100 arrived. Little did I know at the time that only two months later the whole Newton line would be discontinued by Apple.

The 2100 addressed some, but not all, of my issues with the MP100:

• Although it didn’t have a case, it did have a removeable screen cover which is still the best I’ve seen on any PDA
• The faster processor (162MHz rather than the 20MHz of the MP100) meant that the handwriting recognition was far faster - and it also seemed to be more accurate
• The 2100 had a new version of Newton OS - version 2.1 compared with 1.3 in the MP100. One of the things that the engineers concentrated on when developing the 2.x series was reducing the amount of handwriting that was required. I might expand on this in a later post, but suffice to say that the reduction in the amount of writing that was required was significant
• The synchronisation tools were still quite poor. With the abandonment of the platform a couple of months later this is a situation that was never to improve
• It was still physically large - moreso than the MP100. The functionality and power it offered made it a viable replacement for a laptop in many ways, so its size could actually be considered as quite small. However for those occasions when you just needed an address book, it was a rather hefty lump of plastic to have to carry

On the whole it was a great machine: powerful, extensible and delivered everything it promised and more. In the next post I’ll look at some of the highlights of the MP2100.

For the price I paid, the MP100 was a great device. But looking at it from a more independent (i.e. less money conscious) viewpoint, it was clear that there were several shortcomings with it:

1. The £40, fell-off-the-back-of-an-apple-cart, model lacked any sort of case or screen protection
2. The handwriting recognition was slow. There was an option in the handwriting preferences to set the trade-off between accuracy and speed - but going for fast recognition only ended up taking more time overall due to the need to make corrections.
3. It relied too heavily on the handwriting recognition
4. The tools for synchronising it with a desktop machine left a lot to be desired
5. It was physically large

The first issue was easily dealt with by a combination of an old plastic videotape case, some green fabric (for the outside), some soft furry fabric (for the inside), some glue and a couple of hours embroidering the Newton logo during the Eurovision Song Contest (no, really). It took a while to construct, but the result was a dirt-cheap hard case which housed the Newton quite snugly.

The second issue was more problematic. The slow handwriting recognition made the whole system seem a little sluggish. The Newton developers had clearly also seen this as an issue, and included a useful mode called “deferred recognition”, which would leave your scrawl untranslated, but allow you to trigger the recognition routines later on. This was handy for taking notes, but not much use for entering data into more structured applications, such as the address book. Of course the Newton had an on-screen “soft” keyboard (several different types, in fact), but using that was also quite slow (due to the hunt-and-peck nature of on-screen keyboards, rather than due to the speed of the machine itself). Indeed the handwriting recognition was so problematic for some people that an early version of Calligrapher was available for the Newton as a third-party application - long before the invention of the Palm Pilot, which used it as the primary method of input.

The speed of the handwriting recognition might not have been such an issue if it wasn’t for the fact that it was used everywhere throughout the operating system. It was almost as though Apple was so proud of the handwriting recognition that they felt it should be used as much as possible - even where it wasn’t necessarily the best option.

The tools for synchronising with a desktop machine were not good. Whilst the Newton’s internal applications were excellent, getting data to and from a PC or Mac was fraught with problems. It didn’t help that the Newton’s applications were just so much more flexible than just about any desktop PIM software of the time - so there was inevitably a mismatch between what the computer could do and what the PDA was capable of.

Finally, the size of the Newton was an issue - it’s just that nobody realised it at the time. It was the size of a paperback book, but far more flexible than any one book could be. But unfortunately for Apple a lot of people don’t want to carry a paperback book when all they actually need is a small address book. It took Jeff Hawkins to realise this when he created a small wooden prototype of the Palm Pilot - perhaps the device that did the most to secure the Newton’s eventual demise.

When I left university in 1997 I was still enamoured with my Newton, despite these shortcomings. So as soon as I could afford to, I decided to treat myself to the latest and greatest (and, ultimately, the last) Newton: the MP2100. Did this upgrade address any of the issues above? All will revealed in the next exciting instalment…

The term “Personal Digital Assistant”, or PDA, was originally coined specifically for Apple’s Newton. These days it’s a more common term, applied to everything from Palm devices to Windows Mobile systems. But perhaps it’s bandied about a little too easily these days, because whilst these young pretenders to the name are both “personal” (they’re small and pocketable, and typically used by only one person) and “digital” (they’re… well… digital), they’re not really “assistants”.

The Newton was most definitely an “assistant”. It even had a built in application called “Assist” which did exactly what you might expect of a personal assistant - or at least of a digital one. Scribble “Lunch with Simon on Tuesday” into the assistant, and it would schedule a lunch appointment with the most likely Simon from your address book. Scrawl “fax this to Bob” and it would find Bob’s fax number in your address book and fax him the document you were currently looking at. It may have drawn the line at beating up Martin, but otherwise the Assistant worked pretty well.

The reason why the Assistant was able to perform its magic is due to one of the underlying design decisions made by the Newton team. Rather than storing data in simple text or binary files, as most PCs do, they were stored instead in database files called “Soups”. Each soup was accessible by any application on the Newt, and it was possible for a program to access a conglomeration (or should that be consommé) of all of the soups stirred together as one big database. This allowed any application to access the data from any other application - and the databasey nature of things gave it all some structure.

The obvious result of all this gazpacho was the Assistant. It could use the super-soup to easily search through all of the data in the Newton, and because the database model provided a little structure to things, it could safely add a new appointment here, or an alarm there. It was the Google Desktop of its time - only moreso, because it wasn’t limited to just searching for data, it could also create it.

Soups are just one example of the innovations that went into the Newton. The whole operating system had been designed from the ground up to be pen-driven, and to thrive as best it could within the limitations of the Newton hardware. Clever design tricks allowed the built-in applications and widgets to be easily extended by third parties, with soups letting them seamlessly work with the data from the native applications (or from other third-party applications). The “object oriented” operating system made it possible to extend the Newton’s core code (which was stored in read-only memory) without having to use up much of the precious RAM (the early Newtons only had 640KB of RAM - and at the time ROM was cheap, but RAM was not).

Technically the Newton was a triumph. The handwriting recognition worked well enough. The operating system could be twisted, extended and expanded in ways that its designers hadn’t even imagined. It really did live up to the idea of a “Personal Digital Assistant”, and I certainly considered it £40 well spent. But not everything was perfect with the MP100, and that will be the subject of Part III…

The Apple Newton was released way back in 1993 and although I thought it looked interesting, I steered clear of it for two reasons:

1. It was expensive. Very expensive. Several hundred pounds of expensive.
2. I’m left-handed, so figured that a device which relied so heavily on handwriting recognition probably wasn’t for me.

Fast-forward to 1996. I was a student in Manchester, and a whisper was spreading round the electronics department like wildfire: a local Apple store had a huge box of Apple Newtons that they were selling cheap. Very cheap. £40 of cheap.

I rushed to the shop, and joined the long queue of students hoping to bag a bargain. It seems that the rumour had spread to our department from the computer science department - and just about all of them had got there first. The queue was so long, in fact, that I expected to finally reach the door just after they sold the last one. But I was in luck: they actually had two huge boxes of Newtons - and I really do mean huge. By the time I arrived there was easily another hundred or more in the box, so I had no difficulty in getting one.

The truth is that a lot of the Newtons in the box were “dead” or locked. Some of the computer science people managed to track down the magical incantations required to restart or reset them, and picked up a vast quantity of “dead” machines at £5 apiece - which they then sold on at a profit, of course. For a few days afterwards there was much swapping and trading of devices as everyone shuffled parts around trying to get a better machine, complete with a battery cage (so that it could take standard AAA batteries - those who failed to get one had to subsequently get creative with a soldering iron instead).

So although I started with a first generation Newton - or an Original MessagePad (OMP), as it’s known - I quickly upgraded to an MP100 - the second generation which looked identical, but had a slightly later version of the operating system. I managed to get one with a battery cage, too - though I did have to solder up my own serial cable to connect it to a desktop computer.

Having dealt with issue (1), it was time to move onto issue (2) - how would the MP100 deal with my lefty scrawl? The answer, it turned out, was “surprisingly well”. It took a little training to get the recognition accuracy up to an acceptable level, but we’re talking hours rather than days. Once the little black box was used to my writing - and with a little adaptation on my part, I’m sure - it was pretty damned good.

Perhaps more important than the recognition was the fact that it was easy to fix mistakes. With each correction it would learn a little more, so that the recognition became better over time, but even without this benefit the OS designers had obviously realised that being able to correct mistakes easily is just as important as getting things right in the first place. When a word was incorrect you would simply double-tap on it to see what other possibilities it could be - or to edit it letter-by-letter if the Newt had really fouled up. When it did get something completely wrong, a quick scribble through the word (or letter) would blow it away in an animated puff of smoke. Very intuitive, and also very satisfying.

So having got the first obstacle out of the way - could I actually use the thing - it was time to take a look at the software which was built into the Newt… and that will be the subject of Part II.