"Tornado"? What the hell has that got to do with computers?
It's a good question. Many will express a vague familiarity with the word in an Acorn context, although, it being nearly a year now since the AU and Archive mention of it, it would not be excusable if few could remember any specifics.
I could launch into those specifics, but I won't - after all, read all about them at http://www.armature.net.au/~tornado/ - it will also save me 50k of text or so, and still we wouldn't be far into it. So, perhaps, maybe I should give a brief outline and give a few examples of what all this will mean for the average computer user.
In a nutshell, tornado is a graphical user interface based on some rather different ideology than is traditional.
Like for example, its emphasis. Normally, desktop environments are aimed at ease of use. Not so tornado. In fact, the emphasis of tornado has been carefully laid out from the start, and they read as following (in order):
In the execution of these goals, it uses cutting edge techniques and fast all-assembler code to deliver a powerful, productive and complete user interface.
In other words, it lets you get on with what you want to do without annoying "easier to use" gagets or closing the dialogue box you were just using or obscuring the very thing you're tweaking. Indeed, one major irk on Risc OS is missing - the way one task can halt the machine, preventing you from getting on with your work.
In addition, things aren't over-engineered like much of RO3 is with its method of heaping extra calls on top of RO2 ones without properly rewriting the interface - instead operations are grouped out into logical and user-definable groups.
Tornado is also adaptable to its surroundings in a way unlike current interfaces - for a start, every application can have its toolboxes and menus user-defined or changed according to user preferences as depending on the user currently logged into the machine. Indeed, ultimately, as most of the sources of tornado are supplied, you can directly tweak the sources.
Tornado also adapts to its surroundings automatically. Depending on CPU power available or memory or machine or whatever tornado can automatically customise itself to use its available resources to the best possible effect.
An extension to this is the utilisation of extra CPUs where available, whether via being directed plugged in to the motherboard or available via other machines on a network. Connected tornado machines can share their CPU power and public resources creating in effect one massive computer.
Despite its all-ARM-assembler liniage, tornado is still designed for the future. It has been designed to allow transportation to other operating systems and architectures so code written for tornado now should function tomorrow on non-ARM non-Risc OS environments.
At this stage however, the development multitasker only supports code written in ARM assembler, BBC Basic V and APCS C. An innovative part of tornado is how the multitasker directly interfaces with programs written in these languages allowing it to be written with the minimum of alteration of natural writing skills whilst retaining a maximum of efficiency and ease of writing.
To simplify the interfacing between tornado programs (and indeed segments of one program written in different languages), a common integrated and dynamic interfacing protocol is managed by tornado on your program's behalf allowing many tornado operations to happen without your code participating at all. In addition, many tornado resources are shared, like file rendition code, file readers and library tools (eg; common search and replace tool or dictionary tool or colour pick tool) - and public, meaning other tornado machines connected to it can share those same resources.
Another useful design feature of tornado is that it is capable of integrating itself with other GUIs or operating systems, allowing a large amount of functionality from a small base of natively written software.
And one need not worry about tornado becoming locked in the past like many operating systems both past and present have done or will do. Tornado's modular design is object-orientated in nature, so that updating one data structure used by one tornado call need not affect older programs not able to handle the new format or indeed effect any other data structures anywhere else in tornado. Newer programs can use new features while older ones can continue to function as always - however, this is not to say they still won't benefit from newer routines - an example would be a search routine in the library - if it replaced by a better faster more flexible one, programs written for the older routine still work fine - while not being able to use new features, searching will still be quicker.
Whether it ultimately succeeds or not, tornado is already here. Preliminary work on the multitasker is already almost over, and the first functional multitasker is not far away. So whether you believe any of the above is possible or not - interest yourself in the project, check the web pages every now and then, and keep watching. Who knows, maybe every machine on the planet may be using tornado some day - it has happened before, and with products far less advanced than tornado!