Qualities desired for the "ideal OS"

[Francois-Rene Rideau]

[This is an answer to a message in comp.os.misc]
[I've fully quoted and reformatted original text
for tunes mailing list readers]

>: sl65r@cc.usu.edu (Paul Hepworth)

> Greetings!
>      I am doing research into the characteristics
> of the "ideal" user environment.
Let's say you only mean "better than what exists",
and don't run after the ghost of an absolutely best system.

> I do not use the term OS,
> because I'm interested in things from a user-interaction standpoint,
> not a machine-control standpoint.
> (Specifics of machine operation is irrelevant to the user.)
Good idea! What counts is actual observable behavior,
not compliance to commercial hype and pseudo-technical religions.
I use the term "computing system" for such an overall environment.

> I wish to form a specification for the ideal user environment.
> Later, if time permits, I intend to
> implement this user environment in some way,
> perhaps on top of the Java virtual machine
> or on a platform-abstraction layer on top of existing OSes.
First find your specifications,
the get/write a platform abstraction layer that fits.
Unless your specs are lame,
neither JVM nor its standard implementations will do.

>      I am currently at the "brain storming" point.
> I am interested in hearing
> what behavior you wish you had in your current OS
> and what behavior you wish your current OS did not have.
You might be interested by the lot of ideas already collected
by the Tunes project and its mailing list.
http://www.eleves.ens.fr:8080/home/rideau/Tunes/
I'd appreciate that you join us,
and contribute your ideas in a subproject
that ought to examplify what a better system could do
from user stand-point.
For joining, see the following page:
http://www.eleves.ens.fr:8080/home/rideau/Tunes/mailing-list.html

>      Here are a few of my suggestions to give an idea what I'm looking for:

>      One application should not forcibly remove keyboard focus while
> I am in the middle of typing in another.  Instead, warning messages should
> be indicated by bright colored and/or flashing icons on the task bar or in a
> "warning zone" at the edge of the screen.
Yeah. To me this means that applications
should never access physical devices or low-level abstractions of it,
but only interact through logical, high-level, entry points.
Hence, a program that would warn the user,
will NOT explicitly open a window and draw text on it;
instead, it will "warn the user",
and the interface system, as configured by the user
(who could have it arbitrary customized, or let some good defaults),
will take appropriate measure,
which might be displaying stuff on the screen,
sending text to a line printer,
voice-synthetizing a warning,
changing the feel of a braille console,
throwing an exception,
or whatever.

>      It should be possible to add, remove,
> and configure components/programs/drivers
> without having to reboot or terminate other applications.
Linux has some kluged limited support for that:
at the low-level, the kernel accepts first-order modules,
though the main functionality is monolithic.
At user-level, recent distributions have package systems,
but they interact badly with running application.
   Tunes should be a fully modular higher-order system,
where everything can be upgraded on the fly:
running components will continue to run,
by either accessing the new component,
perhaps through a compatibility filter,
or sticking to the old one;
such component management taking into account differences in
design/protocol/vendor/version/release/patch/whatever,
should be standardized very early in the system.
   Of course, in cases when a new component
asks for a unique resource already managed by another module,
and there is no known way to ensure hot replacement (or replacement at all),
the user will still have to take some difficult measures:
he might terminate clients or stop them
until a compatibility solution is found
(which might be reverting to a compatible driver after
using the incompatible one).
   The big difference between Tunes and other systems
in treatment of these cases, is that the system will
automatically maintain consistency
in verifying specifications of inter-object connections,
so someone replacing a module knows what he's doing,
and is warned beforehand of possible problems,
so he can actually take measures,
instead of being backstabbed as is the case in current systems,
where programs suddenly cease to function properly
and possibly corrupt data,
because of some  borken upgrade, or virus, or whatever.

>      Data objects (files, for instance) should be seamlessly accessible 
> regardless of whether they are on local drives, network, ftp sites,
> web pages, or any other media.
That I called a *Unified*, *Distributed* system.
"OO" and client/server hypists claim to have achieved it,
but just don't have a clue.

>      Object-centric (aka document-centric) model with automatic persistence.
> I.e.  If I work on an object, my work is automatically persistant;  there is
> no need to "remember to save."
That is called "orthogonal persistence",
and have been successfully implemented for a long time,
only not in mainstream systems.

> Likewise, if I wish to rename an object, I may
> do so from the toolset (application) with which I'm working on it.  I do not
> need to do the two separate steps typical of other systems:  (save-as from
> file menu;  delete old from file-manager)
That is rather a matter of a automatic system-wide
1) *Unified* Interface: the same interface allows access to all objects
and all functionalities (that are but particular objects);
2) *Consistency*: changes -- names in that case -- are automatically
propagated to all objects that mind.

>      All tools which modify a data object will allow full "undo."  (This
> capability may be provided by the object persistance system, by the tool, or
> it may be shared between the two.)
This is *Reversibility*. Though full Reversibility is not possible
for arbitrary devices (I can't unprint bogus printer jobs),
or for arbitrary large object changes (limited by size of disks and tapes),
a good system should automatically and consistently manage
what can be achieved of it in a system-wide way.
I imagine that institutions and corporations would constantly
have several tapes (or other write-once device) being used
to log changes in a reversible way,
so that the system memory is guaranteed to be restorable in case of
hardware/software crash/mismanipulation/malfunction/damage/etc.

>      Tools will all have the ability to install and remove themselves.
See above. Tunes will not build an arbitrary differentiation
between "system" and "user" components.
The fact that scoping prevents some objects or functionalities
from being used without special rights
will implicitly differentiate arbitrarily finely between priviledges,
without having to kludge the whole system with
a stubborn static fascistic inefficient unsecure differentiation scheme.

>      Applications will be aggregates of fine-grained components.
> The users may replace components to suit their preferences.
Yup. That's *fine-grained* *modularity*.

> For example, if I like my mail
> tool except for the behavior of the entry-fields, I may replace the entry 
> fields with my own preference (maybe a vi-like entry field :).
Good simple example.

> (Very high
> level, complex controls may be used to build applications (like in Visual
> Basic), but these complex controls will themselves be aggregates of simpler
> controls which may be replaced or subclassed at will (very much UNlike VB).
Yup. Everything should be reflectively customizable.

> (Fine grain control vs. course-grained throw-in-the-kitchen-sink approach.)
Down with coarse-grained software!
Note that coarse-grainedness is promoted by proprietary software vendors
to better racket customers and take them as hostages.
Free software works better with fine-grainedness,
that allows for easier value increment.

>      As an example of the seamless access
> of "data objects" whereever they may be stored,
> the WebBrowser would not exist in its usual start-up-the-
> browser-so-I-can-access-the-web mode.
> Instead, search engines and bookmarks
> would appear right on the desktop
> (or whatever metaphor drives the workspace).
>
> HTML-rendering windows will pop-up as links are selected (similarly to the 
> way a text-editor pops up when a text-file is clicked in a file-manager).
> New links may be configured to replace the current view,
> to pop-up an additional view,
> or to do one or the other depending on which mouse key and/or
> shift keys were pressed.
Yup. Again, we have a Unified system.
Note that though "OO" hypists pretend to bring unification,
their lame "inheritance" model just doesn't allow
for incremental addition of features,
so that they just can't "intern" new features into the system
(like Unification of the networking capabilities
to achieve make a global distributed system):
they have no way to keep consistency in dynamically defined features,
so that any new feature cannot be transparent.

>      Multiple views, for example documents being edited in separate windows, 
> may be linked into a "ring" so that a hotkey may move the focus to the next
> window in the ring.  If the user prefers, several "logical views" may be
> placed in a single window, the hotkey bringing the next one to the visible
> "front" of the ring.  (I.e. the hotkey either switches between several edit
> windows or switches documents in a single window, according to the user's
> preference.
That's again a question of system-maintained *Consistency*,
as opposed to human-burdening inconsistency,
that limits the size of working systems to what a single human can manage.

>      Closed folders (or whatever metaphor)
> will give some indication of thier contents.
>
> For example:  a mailbox will indicate the number of messages and
> if any new messages have arrived;
> a folder would indicate the number of files,
> etc.
> Additional information would be available from "spring-up" message boxes.
> If folders are used, it should be possible to "drill through the heirarchy"
> without having to open folder, open child, close parent, repeat, ...
> Instead,
> the popup menu would include a list of sub-folder menu-items which include
> their subfolders, etc.,
> making it possible to open only the folder you desire,
> even if it is several layers down in the directory structure.
That's what I've called "active attributes".
We don't manage a passive structure, but active objects;
current systems force people to manually
under-emulate limited active objects through passive representations,
because they are too lame to provide
orthogonal persistency of active objects.

>      Drive letters are silly.  Named volumes are acceptable.
> Added new drives/partitions would not mess up
> the names associated with existing drives
> (as it does with drive letters in some systems).
> A single root filesystem and
> mount points approach as in unix is okay, too.
Filesystems are silly to begin with.
Persistent stores are much better;
"folders" are then just the same as the structured objects
you use in your favorite programming language,
with the same way of nesting objects,
without the need of a special interface for persistent objects.
[Note that after forty years after LISP implemented it,
AT&T rediscovered the joy of scoping,
and proudly added it to their Plan9, Brazil, and Inferno
filesystemish interfaces, as if it were a new revolutionary concept;
forty years from now, they might at last realize
how stubborn filesystems are to begin with]

>      etc. etc.
>
>      Please add your suggestions, likes, and dislikes.  Thanks.
See the Tunes WWW pages...

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"