google bads

This may the first in a series - I had Google Ads enabled, in standard text-only mode, on my two blogger blogs, when, lo and behold, one of them started displaying a full picture strip add for Scientology. I have had previous encounters with that cult (yes they ARE a cult) and there is no way I will allow my sites to be associated with them - it seems there are a lot of others complaining about the Goog serving up scientology ads on their sites also... I will be investigating further, but meanwhile I have removed all advertising from my blogs. How has the Goog become influenced so strongly by a cult that they start breaking their own rules? Whatever happened to "don't be evil"? I am seriously considering migrating my blogs to another host (and my other uses of Google, e.g. Gmail), as the inevitable slide of the Goog into the dark side seems to be well under way....

the WORM database

The WORM database is a proposed object database system, with the following features:

- a HEAD containing the current version of each object, and indices for key attributes. The head is stored in one file.
- a TAIL containing the version history of each object: all data committed is stored sequentially in the TAIL, as "transactions". The tail is stored as one file (although more complex segmented setups are feasible). It is only ever appended to, and otherwise is read-only.
- each transaction in the tail is incremental: i.e. it stores only the changes since the previous version
- the HEAD can be generated from the TAIL. Thus the head can be regarded as transient: for example, it could be stored in RAM. However, the re-generation of head from tail should be considered an exceptional process, and may be slow, and resource hungry.
- the TAIL can be stored on a WORM drive, giving massive storage potential and great security to the data recorded. For lower-security implementations, read/write storage may be used, but even this will be more secure than a conventional database, as no amendment to data is attempted.
- many different storage and backup strategies are feasible. For example, if storage is tight, the tail can be CLEANed, whereby a new smaller tail is created from the old without any deleted objects or unwanted old versions. The backup can be SEGMENTed: for example a daily backup can be done by simply copying the segment of the tail that was created that day to a backup file. The tail can be TRUNCATEd, whereby a new tail is created from the old, staring at a selected point in the sequence, with SUMMARY copies of the state of the objects at that point.

There are various types of TAIL TRANSACTIONS, for examples:
- CREATION: this contains the initial version of the object, which is is allocated a sequential generated ID
- UPDATE: incremental change to the object. This links (relatively) to the previous update, or creation. Object versions are derived (for storing in the head or in a summary, or for giving a version history) by starting with the object creation and applying all updates to date.
- FORK: this allows a copy of the object to be derived, which is is allocated its own sequential generated ID. Both forked objects then share the same version history up to the fork.
- REVERT: this links back to the version we are reverting to. Intermediate versions can then be disposed of when clean-ing.
- UNREVERT: cancels a previous revert
- DELETE: this marks the object for deletion - it will be disposed of when clean-ing the tail (unless there is a subsequent undelete).
- UNDELETE: cancels a previous delete
- SUMMARY: this is like a creation, but is used for existing objects to store the current version of an object (in full), for example, when truncating the tail. The summary is derived from the previous tail transactions for that object, and these other transactions can then be disposed of, if desired. Summaries can also be done as of an intermediate point in the tail, for example, when truncating old data, but wishing to keep recent version history. Current summaries are also maintained in the head.

The HEAD contains a mapping of object IDs to object summaries (i.e. the current version in full, of each object). This allows efficient access to current versions, which are what we want most of the time: older versions have to be derived more slowly by accumulation from the tail transactions, or by undoing changes backwards from the head summary. Each object summary includes a link to to its last transaction in the tail (which in turn link to previous transactions).

In addition the head can contain whatever index-objects are required for use in searching the database efficiently. Searching would normally be restricted to the head only: there may sometimes be a requirement to search through old versions in the tail, but for most applications this would be exceptional, and so does not have to be efficient. Some types of applications (e.g. accountancy) may require more efficient searching of the tail, in which case suitable indices to tail data can be generated and maintained in the head.

In Python the head would be implemented as a dictionary of summary-objects, and the tail as a list of transaction-objects.

A database like this might provide an ideal back end to The Journal front end that I proposed earlier .

Google Chrome OS

Two days ago, Google announced a new open source OS: Google Chrome ... heard that name before? Yes - the new Google OS is in fact the existing Google browser fitted on to GNU/Linux underpinnings. This is a great development - exactly what I have been wanting to see for some time now : an OS that misses out the desktop, and just gives us a browser! Yeay - on you go Goog! Keywords in their design overview are "fast" and "lightweight", and "the user interface is minimal to stay out of your way, and most of the user experience takes place on the web". I like all of that :) There was a reference to a "new windowing system" in there.. I would rather see no windowing system, but maybe they will be minimal in that department, making the browser default to full screen, and other apps open within the browser tabs? I hope so...

This evolution of the Chrome browser into a browser-based OS was planned from the start, it seems - as Techcrunch noticed last September:

Expect to see millions of web devices, even desktop web devices, in the coming years that completely strip out the Windows layer and use the browser as the only operating system the user needs.

Nevertheless it is encouraging to see the Goog consolidate their strategy and now talk openly of the launch of a new OS. It was always going to require giant resources to go head to head with Micros*%t, and liberate us from archaic OS paradigms (a task that Apple seems to eschew - their "new" Snow Leopard makes no significant steps away from their traditional approach to OS interface, despite their groundbreaking work with the iPhone). Google have the giant resources that are required, and, it seems, the vision also.

Of course the Goog envisions us using their web apps for most of our work, and storing most of our data on their servers - I have already railed against this centralization approach on my post The Great God Google. But with a browser based OS the apps can be hosted anywhere, and there is nothing to stop them being hosted locally. So there is no reason why this approach should prevent the development and use of truly distributed systems, whether or not Google move more in this direction themselves.

Anyway, I look forward keenly to getting my hands on a copy of this new OS.

Now if they would only include The Journal in there also... dream on...

the journal

The Journal is a replacement for conventional filesystem interfaces: I first encountered the concept in the OLPC Human Interface Guidelines. It is a shame that the OLPC project seems to have foundered - I always thought its focus on third world children seemed patronizing and unrealistic, but we seem to have missed another opportunity to move beyond the inefficient and frustrating tired old paradigms that rule the computer world. However, the Journal can be resurrected, and it should be, in a more generalized context.

The Journal is a generic subsystem for storing and fetching versioned data, accessible by owner, date-created, date-accessed, by type, by key, and by tag. It is intended as a replacement for direct use of both file managers and databases.

The Journal is thus the aggregate of all kept data on the system, and the human interface to that content.

The Journal must support multiple users, and allow sharing of data between them, while maintaining security of data where desired.

The Journal consists of many items: each item is a version of an object, and each object is a file or other piece of data, which will have an associated default action or activity. The associated data - the text, the image, the dataset, whatever - is embedded in the entry, along with its owner, date, other metadata keys, and tags.

"save early, save often"

In principle, every data input will be kept: amendments to an object are made by keeping the new version of the object, without destroying the old.

The aim is, wherever possible, to require no explicit "save" by us, the users.

The journal will keep a record of our every request and our every input, including accessing an item.

Incremental saves (backups) should happen automatically, and these will expire when we (implicity or explicitly) keep the object.

"keep things that we want to hold on to, and the rest just fades with time"

To conserve space, and ease finding things, the temporary, the experimental, the duplicate, and the unwanted items should be removed over time, leaving only those that remain important to us.

The journal will be kept tidy by automated, rule-based garbage collection: each type of data will have a specific lifespan. Any item exceeding its lifespan, since last accessed, will be flagged as expired. The lifetime of backup items expires when a new version of that object is kept. Expired items may be deleted by the system at any time, though certain items may require confirmation by us (eg the latest version of an object that we created explicitly).

By default, the journal is organised temporally - by the date/time an item was created. Therefore it is trivial to find the objects you were last dealing with.

Items may have any number of tags associated with them - typically some are set automatically by the action, and others manually by us.

Items are locatable by metadata (date, type, user defined keys) and by tag.

The ordering of search results may take into account how many times we have accessed each item, how recently we have worked on it, etc.

There will be sophisticated indexing, filtering and sorting facilities.

The journal must be stable, and thus requires automated backup to an external location, with simple restore.

To implement this Journal system, we can leverage existing technology. We can utilize a conventional filesystem for storage, and an RDBMS or other conventional database system may be used for indexing, if this is an efficient solution. We simply keep these complex and archaic systems hidden beneath a very simple and intuitive human interface.

Here are some extracts from the OLPC Guidelines:

We believe that the traditional "open" and "save" model commonly used for files today will fade away... Instead, a more general notion of what it means to "keep" things will prevail. Generally speaking, we keep things which offer value, allowing the rest to disappear over time. The Journal (gives)a time- based view of .. activities.

Most of us heard the "save early, save often" mantra, largely ignored it, and incurred the consequences. [We] eliminate this concern by making automatic backups. This lets [us] focus on the activity itself.

Incremental backups occur regularly and are also triggered by such activity events as changes in scope, new participants, etc. To cater to the many types of editing environment needs, activities can also specify "keep-hints" which prompt the system to keep a copy. For instance, a drawing activity may trigger a keep-hint before executing an "erase" operation. [We].. may choose to invoke a keep-hint by selecting the "keep in journal" button, but the increasing adoption of this new concept of [automatic and prompted] keeping should ultimately eliminate this.

..Each kept Object is a separate instance of the activity which created it. This eliminates the need to "open" a file from within an activity, replacing the act of opening with the act of resuming a previous activity instance. Of course, [we] have the option to resume a drawing with a different set of brushes, or resume an essay with a different pen, providing "open with" style functionality, but [with] no substitute for an "open" command.. [in] an activity's interface.

Along with the idea of implicit keeping, [we] drastically minimize the hierarchical filesystem as a means for organization, replacing it with a temporally organized list of activities and events, [hence] the Journal metaphor. [This there is no need] to specify a location in which a newly started activity should be kept: naturally [it] will appear as the most recent entry in the journal.

Temporal organization functions naturally in the absence of explicit or hierarchical methods, since humankind's intrinsic relationship to time gives them, at the very least, a relative notion of "how long ago" something happened. By moving back through the Journal, [we] can simply locate the period in time within which [we] know [we] made something, and then employ additional use of searching, filtering, and sorting to pinpoint exactly what [we are] looking for.

Our minds, generally speaking, maintain a high level of granularity with respect to very recent events, but only a low granularity for events from several years ago. Moreover, this granularity tends to follow a logarithmic curve, where the past few minutes remain quite clear, the past few hours more blurry, and by last month quite vague. When we look years into the past, only specifically memorable events stand out in our minds.

[With the Journal] the principle remains the same. With a finite amount of memory, there must exist some means of managing what's remembered, or kept; and what's forgotten, or erased. An intelligent algorithm will assist .. in identifying "forgotten" entries. Taking into account how old an entry is, how many times [it has been] viewed, how recently [it has been] worked on it, how many hours [we] worked on it, how many people [we] worked on it with, its tags, and even more forms of automatically generated metadata, the Journal can suggest .. those entries which it feels can be erased. [We] will then have the opportunity to review those items prior to their erasure ... and can keep any [we] still feels attached to.

The temporary, the experimental, the duplicate, and the unwanted files will naturally fall off the bottom, maintaining a browsable history of those that remain important to [us].

Implicit journal entries will be the most common. These appear .. most commonly when engaging in an activity. Other implicit entries might appear when [we] take a photo, or receive a note from a friend, or download a file from the Web. In all of these cases, the journal entry itself has a basic format which conveys important information about the event which created it. Most importantly, the associated Object - the photo, the message, the drawing, the story - becomes embedded within the entry. It also includes key metadata, such as its name, when it was made, and who collaborated on it.

The journal entry also provides some means to interact with it. For instance, each entry has a description field where a child can tag it with meaningful related words which will make searching for it in the future a breeze. This field will automatically receive any tags that the activity itself associates with the entry. In addition to this tag field, several buttons will allow direct manipulation of the Object, making it possible to resume the activity, place the Object on the clipboard, send it to a friend, print it, or erase it, among others.

In addition to implicit ones, [we can] create several special kinds of entries [manually]. The first of these, the Note, has the simplest form. Taking a cue from a traditional journal, a Note entry simply provides a large text entry field. This freeform entry allows [us] to write down short descriptions of [our] day to day experiences, just as one would within a real journal... The Journal really does provide more than a filesystem, as an actual record of events and interactions with the [system] and with [our] peers.

In practice, [we] may also use this feature as a means of jotting down a note to themselves - a reminder. In these instances, a simple control within the entry will turn the note into a "to-do" note. As a to-do entry, it will have a checkbox indicating its completion status. By filtering the Journal to show only these entries, it doubles as a basic to-do list...

Clippings serve a slightly different purpose in the journal. Similar in spirit to notes, [we] can create a clipping from anywhere, or from within any activity on their laptop. As an extension of the copy to clipboard idea, clippings copy a selection - some text from a chat session with a friend, an image from a web page, etc. - directly to the journal for safekeeping. This provides a quick and easy way to keep a quick record of anything that you might want to keep around for future reference: a phone number, a link, a password, etc.

Taking the temporal aspect of the Journal one step further, Events act like "future" journal entries. By specifying a name for the event, a brief description, and a time, these Journal entries serve as a basic planning system. A control within the entry also enables an audible alert, so that Events can act as alarms.

In many cases, entries will appear at one point in time but the desired result of the entry won't be immediate. This might occur, for instance, when downloading a file from the Web, receiving a file from a friend, restoring a file from [a] server, or saving a large Object such as video or audio data. All of these processes take some non-trivial length of time, and so when necessary, Journal entries will provide a progress indicator stage. When the download, transfer, or task begins an entry will be created in the journal to indicate that. This entry will include a progress bar with estimated time until completion; once completed, it will transition to a standard entry. This makes the Journal a consistent place to keep track of progress, and also provides an easy means to pause and resume transfers, which will prove extremely useful when in areas with intermittent connectivity.

Despite the flatness of the Journal, finding past entries shouldn't prove difficult thanks to a tagging structure... By associating relevant descriptive words with each journal entry, searching for an entry becomes as easy as describing it. These descriptions will manifest in two ways, tagging and metadata. The former provide a straightforward manner .. to describe and organize .. stuff, while the latter provides a more technical means by which activities can associate relevant data and tags with all Journal entries they create.
..
Each journal entry will have a field for tags. Likewise, each open activity instance will have a tag field adjacent to its name field, so that the act of naming a particular activity or Object becomes associated with describing it..

Metadata adds an additional level of sophistication to the tagging model.. consider it a means of tagging tags. Metadata [is] an extension of the basic tagging model where the tag itself consists of a key:value pair. Or, you could simply consider a tag to be a metadata pair with a null key. Whichever way you look at it, this categorization of tags has powerful implications when it comes to organizing and categorizing data.

The Journal itself assigns a variety of useful metadata tags to entries as they appear. These include the time of the entry, its sharing scope, who participated in the activity, its size, and more. The Journal will also keep track of other useful metadata, such as the number of times [we] view a particular entry, the number of revisions an entry has gone through, etc. Likewise, activities will deal primarily with metadata rather than simple tags. This allows activities to define specific parameters, or keys, that make sense for the Objects they produce, and then assign values to those dynamically. In a music composition activity, for instance, potential keys might be beats per minute, the key the composition is written in, the length of the track, and the composer, among others.

Of course, since tags and metadata both follow a very basic format, [we] can assign [our] own metadata associations with Journal entries once [we] have enough experience, simply by typing key:value pairs into the description field.

The search field provides the most direct means of locating a particular Journal entry, returning instant results as the search is typed, and offering auto-completion for popular tags. In order to find anything ... [we] need merely describe it, since the tags [we have] associated with it already appear within its description field. [Our] searches also apply to the metadata associated with the entry by either the Journal or the activity that created it, making it even easier to find things.

For simplicity, the search field will employ OR logic to all terms entered, which ensures the least amount of confusion.. As such, a search for "orange cat" will return a list of everything orange and also every cat. Of course, any entries tagged with both orange and with cat will match more strongly, and will automatically filter to the top of the results. However, in keeping with a primary goal of the laptops, this won't eliminate the possibility for more complex boolean searches. Full support for AND, OR, NOT, and parenthetical grouping of terms will be built into the search engine, providing advanced functionality for those who desire to enter more complex queries.

.. Fuzzy match algorithm[s] will .. return some results even when the corresponding tags don't match what they typed exactly.

Support for .. filtering [will] appear together [with search] in the toolbar, since searching could also be interpreted as filtering by tags... Several fundamental filters exist. First and foremost, there is an advanced date filter.. present[ing] a timeline .. with visual indication over the length of the timeline of the number of entries present in the Journal from any given point in time. By expanding and contracting the selected area [we] can select anything from a single day to all time, and by sliding the selection through time, [we] can filter out all entries that don't lie within the specified range. Other basic filters include the activity that the entry represent, and the activity participants. Other .. filters allow [us] to locate specific kinds of entries, for instance .. all entries that have been tagged by the Journal for [automatic] removal; [or all of our] notes, or to-dos, or events, or starred items, or in progress items, and more. The system will provide adequate flexibility for finding anything in the Journal nearly instantaneously.

The sort bar .. offers a popup menu from which a number of options such as date, title, activity, size, participants, and others may be chosen. In addition to this fixed list, a dynamic list of options also appears, providing a list of metadata keys that are present in the majority of the entries within the results list... The true functionality of the system arises from "then by" sorting. When desired, [we] can specify up to three levels of sorting hierarchy. This feature shouldn't be overlooked, since it serves as an extraordinarily powerful means of viewing and organizing data hierarchically, even when no hard hierarchy exists. In fact, when used to its full advantage this approach can be more useful than a hard hierarchy, since the order of the hierarchy can be adjusted dynamically to suit [our] needs at the time. And, in conjunction with the intelligently compiled list of metadata keys on which to sort, [we] can not only find what they're looking for, but can browse through [our] journal in any way that suits [us]. Consider, for instance, that [we] filter [our] journal so that all of [our] music appears in the results. Since nearly every song Object in [our] Journal has metadata keys for artist, album, track, and year, [we] could sort by these keys to arrange [our] music collection for browsing. Sorting by artist, then album, then track, [we] can obtain a traditional view of [our] music. In order to view a discography for each artist, on the other hand, [we] could sort by artist, then by album, then by track. Or, to see a timeline of [our] music, [we] could sort by year, then by artist. Since many forms of metadata will apply across Object types, the possibilities are nearly limitless.

As mentioned before, the [system] automatically save, or "keep", objects in the Journal at regular intervals. This eliminates the need for [us] to constantly worry about saving, and reduces the chances that an unexpected circumstance will cause data loss. These individual keep events are incremental, meaning that the changes within the file are kept in a nondestructive manner. Therefore, the Journal not only stores Objects as [we] create them, but also keeps track of the revision history for each one. This allows the Journal to function as a versioned filesystem.

[We will be able to] browse through .. [archives on a remote] server directly from within [our] Journals. Since this browsing functionality will integrate cleanly with the entries stored on [our] own laptops, [we] will be able to search, filter, sort, and view anything [we] ever entered without having to think about the technicalities of the data's physical location. Apart from a visual indication within the entry, the experience of browsing through backups will be seamless. [We]can browse through [our] past creations, much as we might browse through a photo album. [We] will have full ability to resume any instance of an activity, to view its contents. A copy-on-write approach will be taken, so that if [we] attempt to modify a temporarily restored item, it will behave identically to a partial restore for that Object, writing the modified revision into a new journal entry.

Christopher Blizzard wrote about the OLPC journal concept:

the critical pieces.. are.. the document itself, who you worked on it with, name and metadata in the form of tags, and the ability to easily share it with other people.... Note that we’re using “Resume” instead of open. The idea here being that you can actually restart an activity in the context of the people that you were originally working with on the document. So it’s not just about about the “what” of the data but also the “who” and the “when”, each of which is missing from our current desktop metaphors.

The Journal solves quote a few problems: How to find data. What to do with data when you find it. Where did it come from? How do you give it to someone else?

Simply adding time and a simple value (i.e. if it’s important) means you can make all kinds of value decisions on the things you carry around with you. That’s very difficult to do with a standard desktop model.

Because the journal is time based, backups can be easily managed. Old items can be archived to offline storage, and subsequently reloaded, or simply accessed seamlessly from that remote storage when a connection is available. The "important" flag makes it easy to decide what to throw away, when you are running out of storage space: simply delete old stuff that you haven’t starred as "important" - this can be done automatically if desired.

So there we have it - a blueprint for a much simpler, consistent, and intuitive, way to interact with our machines.

serving silently

What's in the name "silent servers"? I see three levels to this:

3)Servers that are quiet: My lifework has, for many years now, focused on internet technology, and that means using servers. I progressed to this from traditional client-server work, and I much prefer the paradigm of webserver-browser, as you no longer have the considerable overhead of maintaining multiple client installations, and the technology is immensely scaleable and is universal in usage. So my work focuses on web servers - programming and administering them. I never did like noisy machines. My first computer was a Sinclair Spectrum which made very little noise - a faint buzzing only. My first PC was an Amstrad 1512 which had no fan and also made little noise - only the quietish whirring of the add-on Seagate hard drive. I took badly to the "progression" to ever-bigger and ever-noisier beige box PCs, making an infernal racket with their whirring fans and clunky disk drives. I moved to laptops to escape the worst of the racket. Finally, about 6 years ago I progressed from PCs to Apples, and quietness was a big selling feature for me - there were many pother excellent reasons for the move, but that can be fodder for another post.... For me the perfect computer makes no noise - this means energy efficient chips that don't generate excess heat, so that fans are not required. And quiet disk drives - generally laptop drives are much quieter than their larger brethren. I happily trade performance for silence. And so, now, I use a Mac Mini, which I never hear - I can thus happily leave it on all the time, in my living room. I think Mac Minis make ideal servers for many purposes, with more than enough performance for most real-world requirements. They are tiny and quiet, and use hardly any power, thanks to their use of of laptop components - an external or networked drive is required for backup, as you cannot trust their drives not to fail, but otherwise you have an inexpensive and unobtrusive silent server. The other way to achieve silence in a server is to have it in another room - preferably at a server farm - it may make as much noise as it likes there, but from your point of view it is silent!

2)Servers that are unobtrusive: much more importantly than making little or no noise, a server should not harrass you in any way. Servers should be discreet and undemanding - they should simply exist invisibly in some unknown place and reliably serve up your websites and web applications 24/7 with no fuss and no drama. This means no error messages, and no active maintenance required. This is my aim when installing servers - script everything that has to be done for administration, and use exception alerts to the technical staff to inform of any problems that arise. From the users point of view the existence of the server should not be apparent.

1)People who serve others in a humble and incognito way: the highest definition of Silent Servers are human beings (servers) who serve other human beings (clients) in a low key and dependable fashion. People are more important than machines, and so the human servers are more important than the mechanical ones. No matter how advanced your technology is, it will be of little help to you if you have no willing human expert to make it do what you want it to. Human servers are the ultimate servers. And silence, for human servers, means (as it does in transcendental spirituality) much more than the absence of aural distraction. Silence means single-mindedness: the one-pointed peaceful mind of the buddhist. From such silence comes calm and tranquility, love and compassion, caring for others. From such silence also comes the wisdom of intuition. A silent server will work for the love of the work, and not just for monetary gain. They will aim to help others, as an end in itself. They do thorough and professional work, yet do not proclaim their abilities. I work with people who exhibit such qualities. These silent servers make the world a better place.

damn the desktop

Desktops are for WIMPs. I don't like WIMPs. I never did, and I never will. Windows, icons, mice, pointers, desktops.... yuk.

Windows are for letting the light into a building, and for letting the occupants observe the world outside. And they can be opened to let air in. They have no place in a computer screen. There is only one natural window on a computer, and that is the screen itself: it has a frame and sometimes even a glass. What is this telling us? There is no need to subdivide this window into smaller windows. And if you just can't help yourself, then at least tile the windows, as with old-fashioned window panes - split the window into a number of smaller panes. But the slippery, sliding, overlapping "windows" which have become the norm in computer interfaces, are nausea inducing - they certainly make ME sick. If graphic designers can't live without them, then let their graphic applications create and maintain their own hideous mess of overlapping views. For the rest of us, this abstraction just steals lots of our screen estate, fills it with unnecessary clutter, and converts much of our time into frustration as we try to find the "window" we were trying to get some work done in. So, go FULL-SCREEN (or for Apple geeks: "mega-zoom"), and get back to basic simplicity. I want full screen when I am watching video. I want full screen when I am looking at pictures. I want full screen when I am reading. I want full screen when I am writing. I want full screen when I am programming. I want full screen. I want full screen. I want full screen. Wahhhh.

Icons are for religious devotees. Images may seem like a good idea for representing menu options, as they are language independent. But in practice most icons are incomprehensible to most people. Words, on the other hand, we all understand, so long as they are in our language. These days computers have no problem handling different languages. So we don't need icons. An icon of a printer just causes the majority of naive computer users to say "how do I print this?". Most of them would already have the printed sheet in their hands if there had simply been a button saying "print". Even if they think the icon looks like a printer, they are scared to press it in case it actually means something else, such as "wipe my hard disk clean".

Mice are for entertaining cats. If your real desktop had a real mouse on it you would be calling for your cat, or else you would be running out to buy a mousetrap or some rat poison. Or, in the case of certain traditional women, you would simply shriek "eeeeeeeeeekkkk" and jump on a chair and dance around in a frenzy. This is what mice are for. They are not for helping you navigate around a computer screen. Even our WIMPy friends, the graphic artists, (and the CADs and their ilk) all prefer (even demand) tablets and pens. Nobody wants a plastic mouse. Even cats find them dull and boring. The point and click interface of the browser is very intuitive and useful, but no that we have touch screens that actually work, there is no longer any justification for plastic mice.

Pointers. The creator gave us several: One index finger on each hand, and a bunch of backups in case our primary pointers are eaten or cut off in some unfortunate accident. From very early childhood we naturally point at what we want. We don't need a "pointer" image on the screen to do it for us. Just a touch screen and a finger or two. Lets lose those middlemen, the pointer image and the pointer device. They just get in the way - the pointer devices specialize in malfunctioning, and the pointer images specialize in getting lost, and/or becoming invisible. Lets consign them all to the dustbin of history (along with the QUERTY keyboard, but that is another post..). When we need to remember where we were on the screen, we have good old-fashioned cursors - just like pointers but without the pointiness. I like cursors, just so long as they are big and flashy, so I can find them....

Desktops... WTF?!??@#$%^&*! I have a desktop. It is made of wood, and on it there is a hideous clutter of keyboard, mouse, headset, glasses, glass of water, empty coffee cup, random piles of paper documents, DVDs, memory sticks, USB cables, pens, you name it. A man's desktop is like a woman's handbag. One desktop is more than enough for me to deal with in my life. Why anyone imagined I would want a computer representation of a desktop is beyond me. And then they implemented it so badly that I can't even use it in a useful way, without a degree in computer science. What is this nonsense? A picture - fine, I like pictures, and I get to choose my own - but I don't want icons all over it! Maybe in place of the screen saver (screen savers!.. don't get me started..), I would like to have my favorite picture or pictures display full screen.. in fact that is exactly how I have set up my mac. So I have my picture. Who ever put a real picture on a real desktop? It is futile because it gets covered in junk, which spoils the picture. OK.. all those icons on the "desktop" - what are the for? If I want a representation of a bunch of files and folders and application shortcuts, then I have my home folder in my file manager. I can view that as words, if I like, or I can view it as if I want to introduce more serendipity into my day. So why do I need the separate "desktop" to do the same thing in a different (and generally dysfunctional) way? Short and simple answer - I don't. Computer desktops are truly superfluous.

So - give me a full screen browser and some decent web apps, along with a full screen file manager (and in my sad geeky case, a full screen terminal with a copy of mc), and I have everything I want and need from a computer interface. No windows. No icons, No rodents. No damned desktop. If only life were that simple.....

Evoke

My pet project for the past two years is the EVOKE web application builder:

http://evoke.versere.com

Here is some of my descriptive blurb from the site:

EVOKE is a web application builder, written in Python... EVOKE was written to simplify the creation and maintenance of community-oriented websites. Custom back end systems can be built easily and quickly. EVOKE has been tested extensively on live sites, since 2007, and it has proven stable and efficient. Why EVOKE? Simple design and a high level of integration make EVOKE intuitive to use while containing immense hidden power.

The underpinnings of the system are well proven: it is a rock solid platform for rapid development of custom web applications. You write at a high level in python and EVOKE manages a MySQL database and web-serving for you. Web pages are generated from EVO templates, which use a pythonic sub-language, which seems to delight those who learn it.

The system is carefully crafted and highly efficient, and follows throughout an ethos of "keep it simple, and effortless to use".

However, the superstructure - of login/registration/access-control, community discussion facilities, and website content management facilities - is less fully formed and less stable, though it is already successfully in use on several sites. This superstructure would benefit from restructuring and a tighter focus, which is tricky to engineer while retaining legacy compatibility for existing sites.

I would like to see evoke remodeled (or forked) to operate as a distributed system: i.e. a system of nodes, instead of server/browser, with each node storing data locally, and syncing with other nodes when connected. This implies packaging the system for easy installation on posix systems (including OSX) and (if we must..) Windows (and I won't be doing that bit!). It would also use Python 3, giving full utf16 unicode support (not just the current utf8). Also the heavyweight MySQL would probably be replaced with the more simplistic and lighter sqlite.

Unfortunately, I now feel I have run out of steam on this project. The development of EVOKE has dominated my life for the past two years, and it was always intended to be an open source community effort. So far there have been only three of us contributing to the project, with most of the work being done by myself. Perhaps I have been holding onto the reins too tightly, and if so it is now time to loosen my grip and trust the horse a bit more. I would like to continue co-ordinating the project, with a fairly hands-off approach, stepping back from the detailed programming... this requires other participants with enthusiasm and flair...

I am a long time user of open source code, but a naive beginner when it comes to forming and running an open source project. I tried registering the project on Sourceforge but so far have found that site to be unusable and thoroughly confusing. Without me asking them to, they have made me an admin on an existing and apparently inactive Sourceforge games-related project, called Evoke, but so far my attempts to get any sensible information about this project, and to take it over or replace it, simply result in delay and error messages.... I shall look elsewhere or else employ my customary DIY approach (meaning lots more work..)... The evoke website has been up for several months now, but nobody has yet discovered it.. even one of the existing project contributors ignores it! Is it really this difficult to open up your software to the world? It seems there are publicity skills required, which I sorely lack.. unless this blog does the trick?

Is there anybody out there? Give me a sign! Anyway I will write more about EVO and EVOKE on this blog in the days and months ahead :)