Saturday, May 14, 2005

Correcting Operating Systems

Assumption: files are at the centre of the hard problem of operating systems in modern computing.

All operating systems still operate via root/directory*/file hierarchical, apart from add-on systems that interface with the old system to provide a database front end. There is one at least that i know of that can override KDE? file dialogs.
Database filesystems seem to be a great idea, but thats not all that is wrong with computer operating systems.

Programs are either running, or not running... sometimes when i am debugging 2 or more apps at the same time, i want to seperate my tasks off into different sessions (like user logins under *nix), but that is quite a cumbersome technique that dissallows any crossover / moving of one app to another schema.

So the initial assumption may need to be bent a little to encompass applications as well. What is similar between these two problems?

both consist of human interface representing all the things of one type a computer has... (all files versus all open applications).
most of the time the user is looking for one of the items (looking for a file, or looking for an application)

the assumption that you might look for more than one file (e.g. find a picture collection), probably wont apply to applications (looking for internet apps? nah, rather look for internet app executables to run (which are files)). But is a multiple file selection any different than a single file selection? Lets look at what normally makes up a multiple file selection.

People normally look for multiple files as part of collections. Collections are collections for a reason, and therefore have something in common. This commonality is rather well defined in database operating systems (and we are assuming here that a "better" OS will be running a database filesystem), and searches can be quit before a singular result is found (e.g. the result of the file finding operation was a set rather than a singular).

Does this mean that all file searches may as well be multiple file searches? I think so, because even a singular result is normally selected from a refined set.

So, both running applications and files are sets of items that the use wants to work with. With this assumption, can we then join the two? *nix has a process directory in its /dev directory, (/dev/proc i think), and because of this, a non databased hierarchical filesystem already has access to applications (in a wierd way)... how useful would it be to search for apps by the same system as searching for files? This is more of a selection system than a search system, so what have we assumed here? Users want to be able to quickly "select" things? I think so, therefore a new operating system (and associated applications) should be designed to work on the idea of selecting and reselecting any resources the computer has available.

how about some ideas of selection searches?

i copied some files from my camera recently, and i want one of the pictures, i know its a big one... so here goes:

select all (root select)
refine by action: was copied to local harddisk.
refine action by time: after last tuesday
refine selection by filetype: is an image (drops all non images from selection)
refine by action: was copied from camera (drops ones loaded from CD)

selection should be rather small now...

refine by file attribute: size larger than 640x480
refine by file attribute: colordepth higher than 16bit

now quite a refined selection, the viewable list should be small enough to select by hand. (tab through? or use arrowkeys :) )

how about getting an app, a currently running calculator

select all (root again)
refine by type: is running
refine by attrib: is utilty
refine by attrib: is maths

at which point we have a short list of apps, one calculus app, and two simple calculator apps, use arrow keys to select them.

At this stage, an idea comes to mind that the calculators will be exaclty the same as each other at this stage, so how can we tell any difference? The simple answer would be to add the same kind of labels to running applications as there are to files.
This leads to thinking about how to label applications. In my opinion, applications should be able to label themselves (such as an art package labelling itself with sizes of all its current open documents (but maybe not, i shall speak more on my ideas regarding documents later). Applications should also be able to labelled by the user (calculator one might be labelled as "simple maths", whereas the second would be labelled as "current account", and maybe a third as "coder debug helper". With these labels, the different applications could be quickly differentiated from each other.

I think this same system is good enough to help search for anything...

But thats just my opinion.

Maybe, just maybe, application instances ARE files... but again, more on that another time...

Rant over...

(next installment, documents / files rethought)

No comments: