• The Jazz version of Recessional.
• "Billy Jean" arranged badly for bass and tenor recorders and bass.
• "We Like Knitting" - a rap track in which Paul expounds his philosophy of knitting and gives an emotional rendition of a knitting pattern.
• Some political prisoner or other who just sat in the corner and sulked all weekend.

Oh to walk my way with kindness,
And not betray my life to a cloud of suspicions...
How I wish that someone would believe me,
How I wish that I could believe someone.

To triumph in an unequal battle,
To embrace with love both small and big,
How I wish that someone would believe me,
How I wish that I could believe someone.

Let the silence burst forth with fury
And the eternal noise die down for good...
How I wish that someone would believe me,
How I wish that I could believe someone.

Temp             | -52 degrees C     | cr

In moderately recent time, Intel have taken to giving this temperature not as an absolute temperature, but have instead redefined the scale of Degrees Celsius so that it is measured relative to the "melting point" of the CPU.

Once this is compensated for, it should give the actual temperature of the machine.

The solution to this in some cases is to turn off extended virtual memory on the memory card (under Control Panel - Memory), as this appears to impact the way it 'boots' to go into charging mode. Battery charging appears to be largely software-monitored and controlled.

Of course, this rather depends on the machine booting in the first place; in some cases the machine will boot intermittently (which sounds like a timing issue), if it does not then a solution may be to get hold of an offline, 'dumb' nokia battery charger to give the tablet battery an initial charge.

You may also find that removing the battery for a while helps.

Watching.

All screenshots have been produced with LisaEm, which incorrectly draws scroll bars. This is an emulator issue and not an issue with the OS itself. Apart from this glitch, the emulator seems to be stable and usable.

It is tempting to view the Apple Lisa Office System as a prototype for the Macintosh; this is not, however the case, as beneath its slightly clunkier visual appearance, it is certainly a more sophisticated operating system than the Macintosh System was intially, and in some ways a more sophisticated operating system than any version of the Macintosh System that was ever released.

In addition to the Lisa Office System, the Lisa hardware could run Xenix, (rumouredly) CP/M, and with the addition of MacWorks and a video modification, the Macintosh System.

The Lisa Office System desktop

The Lisa Office System provides a spatial graphical user interface. The desktop is not a glorified folder, but a place for items in use to be put, more like the RISC OS pinboard. Icons can be placed here for quick reference by dragging them from a folder window; alternatively, open documents can be 'set aside', which puts them onto the desktop in their unsaved state ready to be opened again later, or to be 'put away' back into their folder.

Windows in the Lisa system are far more strongly identified with their originating icon than even on the Macintosh. The small icon corresponding to the originating icon is shown in the top left hand corner of each window, and to save changes and collapse the window back down to its originating icon, the small icon is double-clicked. This is equivalent to choosing 'Save changes and put away' from the 'File/Print' menu. When a document is opened, its document icon changes to the 'opened' state (on the Macintosh, this icon state could only be seen on folders and applications, because the one document to one window rule was abandoned).

The 'Walrus' document is open

The Lisa system is far more document-centred than the systems that replaced it; and it is fair to say that conceptually, the concept of an 'application' as a way of creating documents does not exist in the same way at all. Every document must have a corresponding icon within the folder heirarchy; so there cannot be any such thing as an untitled document which does not yet have an on-disc presence (as a side-effect of this, there is no 'Save As' or anything like it, as this would mean that a window could become attached to a different icon in the course of its lifetime).

By the same token, there is no such thing as an active application; when a document's window is frontmost, the appropriate menus for that document are displayed, but there is no application launch or application switch. It is worth noting that this is only possible because, unlike the Macintosh System, the Lisa Office System has true multi-tasking.

Documents must be created from a stationery pad (a concept which reappeared to some extent in System 7). Each 'tool' provides an initial blank stationery pad (named 'LisaWrite Paper', 'LisaDraw Paper' etc.), and any document can be turned into a stationery pad by selecting 'Make Stationery Pad' from the 'File/Print' menu while the document's icon is selected. When a stationery pad is double-clicked on, a new document icon is created next to it, named after the name of the stationery pad and the date. This metaphor extends to folders too; initially, the 'Empty Folders' pad is used to create folders, and any folder can become a stationery pad.

Creating a new LisaWrite document

As an aside, the Lisa system does not appear to have any issue with having multiple files with the same name; and, conceptually, why should it? If the icon is the window is the document, the file name is simply a label used as a memory aid by the user in association with the icon and the spatial position of the icon.

Documents and folders can be password-protected; the password is set from the 'Attributes of...' menu item in the 'File/Print' menu (which is the equivalent to the Macintosh's 'Get Info' item). When a potected document or folder is opened, the system will ask for the password before opening it.

"Attributes of LisaWrite Paper 09/07"

Opening a protected document

It is possible to have tools that are not associated with documents; two examples of this are the clock and the calculator. To launch these, their icons can be double-clicked; but to show that they are not documents, the resulting windows have a different style of title bar with solid corners and solid black when active. This is a convention that was carried over to the Macintosh.

Desk accessories

If a document-centric tool is double-clicked on, then the tool tells you to tear off a piece of stationery.

Using the Lisa makes the choice of certain terminology in the Macintosh make more sense; the existence of the 'Put Away' menu item on the Macintosh to return an icon on the desktop to its original location is a feature for those who wish to use it in a Lisa-like fashion. Visually, the Lisa is less clear and well laid-out than the Macintosh; it feels considerably more cluttered, the icons are less ideographic and the fonts are less well-constructed. In terms of feel, however, the Macintosh feels less well-thought-through; it suffered greatly from being a single-tasking operating system, a constraint which must enforce a program-centric approach in user interaction with the system. By the time the Macintosh OS had gained some degree of multitasking with the MultiFinder, it was impossible to re-integrate the document model into the spatial interface; and in the MacOS X UI the spatial elements were effectively abandoned altogether.

Running MacWorks

This is an attempt to create a userland semantics for a roughly UNIX-like filesystem that nonetheless is a directed graph rather than a simple tree.

It is important to note at this stage that filenames in the UNIX filesystem are in fact not node names at all, but edge names. Files are uniquely identified by a node number on disc; and by that, every instance of a file in the filesystem has the same node number. However, every instance of a file in the filesystem can have a different name; see the following example:

~$ mkdir a b
~$ touch a/dugong
~$ ln a/dugong b/walrus

dugong and walrus are now two names for the same on-disc file; in other words, this part of the filesystem now looks like:

Fig. 1

Using the cd command to change directory is to traverse the named edge in the directory tree.

Early versions of UNIX did in fact have a directory graph rather than a directory tree (see Dennis Ritchie: The Evolution of the Unix Time-sharing System); this did not last very long, because it violated a principle herein called (in honour of Tom Stoppard) the Elsinore principle. It made much greater use of hard links than is customary in more recent iterations; notably because to change to a directory that 'contained' the current directory required significant contortions, which made the resulting filesystem considerably more difficult to use and incomprehensible than the tree-based version which succeeded it.

This leads to the statement of the Elsinore principle: that "every entrance is an exit somewhere else" - or, in other words, that doors or edges do not disappear once you have gone through them.

It is trivial to see that the tree-based UNIX filesystem adheres to this principle. The subdirectory relation defines two links between the directories involved, the named link, pointing from the parent to its subdirectory, and another called '..' pointing from the subdirectory to the parent. As soon as one of these edges is traversed, the 'door' remains visible in the form of the other. The UNIX filesystem is a tree so that users can backtrack through the path from which they came. How can this be done in the graph case?

A naïve approach which makes a lot of intuitive sense says to reserve a set of filenames (much as '.' and '..' are reserved), one for each parent. A sensible choice would be filenames beginning with the ^ character. If, in the above example, dugong were a directory rather than a file, its list might look somewhat like:

dugong$ ls -a
.         ..        ^a        ^b
file.txt

This falls foul of the nature of the filesystem, however: in the UNIX filesystem, edges are labelled, and the parent directories have no inherent name. If the filesystem is a graph, any given directory could have any number of names. This would evidently be extremely confusing for the user, which leads us to another principle: people generally want to know where they are with more urgency than how they got there, and where they are going to be with more urgency than how they are going to get there.

This leads us to what will be referred to here as the Castle principle: name rooms in preference to doors. Name doors as well, if you so desire, but name rooms primarily.

In terms of physical spaces, this seems moderately obvious; going from an unknown place through a door to another unknown place, only to turn around and find that all the doors have been relabelled would be a deeply disorientating experience, and pity the poor user who steps through 'The ill-fated door of Sir Boris the Vertiginous' into a teetering mass of turretry, the only exit from which is directly downwards.

In software, where there are no 'physical' direction cues, this problem is exacerbated.

It should be noted that it is potentially useful to label doors; and so perhaps a 'relabel' command would be a useful thing to have.

Another point: whither '..'? Need we sacrifice this very useful convention?

To a great extent, this convention can be reinstated by storing the full path through which the current directory was reached as the current directory rather than just the node number of the current directory; this acts as a directory stack, where using 'cd' with an absolute path loads the stack from the pathname, 'cd' with a relative path pushes all elements of that path onto the stack, and .. refers to the directory reached through all nodes in the path except the very last. It is unclear how heavy a demand this would place on the computational or storage capacities of the computer, but it seems feasible.

This is only possible if the system contains the possibility of absolute paths; it can be argued (and has been by Jimmy) that if the filesystem is a directed graph, there is no need to have a 'root' directory, and rather base each user in their home directory. However, while backed by sound spatial reasoning (if the home directory of the user is identified with their desktop, then the 'visual' root of the screen corresponds to the conceptual root of the filesystem) this falls foul of the Castle principle, as places on the computer no longer have place names that are independent of the viewpoint of the user using it. In addition, the operating system needs to know where to find its own system files. It thus does make a good deal of sense to have a single 'root' point from which all edges are outgoing. Even the archaic UNIX graph filesystem had a similar concept to this; although it had no pathnames, every directory had a special 'dd' directory which linked to the directory of home directories.

That being said, why make a distinction between outgoing and incoming edges to a directory? The answer to this one is quite simple from a user's perspective; if all edges are equal then all recursive operations will eventually spread out to fill the entire filesystem, making most kinds of operations on directories at worst extremely space-hungry and marginally useless and at worst actively dangerous.

Some problems with this approach:

• One clearly cannot expect users to give every file and directory on their system an entirely unique name. Not only would this provoke outright user rebellion, it would also render operations like 'copy directory' entirely useless. How can situations be dealt with where a directory is 'in' two directories which have the same name, such as the not unreasonable case where a directory called 'html' is within two different directories called 'www'? A bruteforce approach would be to call the first-created uplink ^www and the second ^www2, but that seems ugly and just pushes the problem further along; one cannot simply label each non-unique parent with its own parent, as it may have multiple parents.
• How does this interact with a spatial browsing approach? All the above is couched in language strongly influenced by the navigational-browsing metaphor enforced by a terminal-centric interaction approach. While the act of moving to a subdirectory is conceptually modelled by the user as moving from one room to another then these assumptions hold; even if a subset-like containment approach is taken, then these assumptions may hold, as any given subset can be a subset of multiple supersets; but what of the conceptual model where subdirectories are truly 'within' each other, nested "like Russian Dolls"? This does not seem too far distant from the subset problem, if you view directory boundaries as permeable, but requires more thought.
  

This is heading in similar directions to some of the work Jimmy has done; one question is how to decide which set of cases is necessary and sufficient to describe the set of operations the system provides. Should applications be able to define their own?

This does not affect the UNIX pipe, and and or operations and others like them, as they are conjunctions; the input and output redirection operators, however, would become shortcuts for a pipe, the verbs 'read', 'write' or 'append' and a locative or ablative noun.