My TUNES Wish List -- are any of these doable now?

[Chris Harris]

This is a multi-part message in MIME format.

--------------25DD60C810BA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello TUNES people!

I've just made up a wish list of features I'd like to see in TUNES 
someday.  You can find the list both attatched to this message and 
a "http://simba.lakeside.sea.wa.us/~chrish/tunes.html".  I know 
that most of these things are talked about in one way or another 
on the TUNES pages, but I wanted to articulate what some of the 
most important parts of TUNES are to me.

If you people find anything on this list that you think would be 
good to start work on now, please let me know.  Writing documents 
is okay, but I think we'll need to do much more than that to get 
TUNES off the ground.  It's easy to convince people that a new OS 
would be cool; it is hard to make the new OS that is cool.  Do you 
think there's anything on my list that could be started now?  If 
so, any ideas how?

Thanks.

-Chris

--------------25DD60C810BA
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="tunes.htm"

<BASE HREF="file:///C|/users/Chris/tunes.htm">








Chris' Tunes Wish List




Speed


Take advantage of availible hardware. (Start with most basic drivers,
but eventually it'd be good to have support for my #9 SVGA card, etc.)

Don't bog down hardware that's fast enough for my needs with software
that I'll never use. Make my 16 meg Pentium 90 scream, unlike NT, which
makes it run like a slug. (It strikes me as dumb to have a better machine
than most people in the world and still have things become exceptionally
slow when having five or six mostly-small apps running, most of them not
doing any processing.)


Ease of Use/Flexibility


(note: ease of learning isn't necesarily the same as this. We want the
basic TUNES concepts to be simple enough that they are easy to learn, but
we also want to reward further learning with ease of day-to-day use.)


no undue abstraction -- THIS INCLUDES SEQUENTIAL APPLICATIONS!

Intelligent install/uninstall of packages.

On request, automatically determine which packages are unused (by users
and and other packages), and present them for possible deletion.

If a package A is unable to function, because it lacks a certain other
package B to link to, the system should tell the user, in English (or whatever
the native language is) what sort of package B is, and where it might be
obtained. (Actually, if the machine is on some sort of trusted Tunes network,
it could ask if it should automatically obtain and install B.)

Powerful things aren't necesarily hard. With our HLL, specifically,
let's let the programmer/user deal with the problem at hand, and not with
all the silly details of memory management, mapping data to disk, etc..


(a package, in my mind, is whatever the base unit of tunes software
will be -- be it an "object", a "world", ...)


Consistancy


There should be no difference between accessing a package interactively
and accessing a package through a script. In a modern OS, I may have
an interactive program to convert GIFs to JPEGs, but if I wanted to
do this from within a script, I'd probably need a completely seperate program.
This should not be.

There should be no difference between "standard" system calls
and "external" library calls.


Persistance


I don't want to have to quit my applications (or "unlink
my objects from the rest of the system", as might be said in TunesSpeak),
either to turn off my computer or to free up RAM. Really, I'd like to leave
all my internet apps, a word processor, some object management stuff, programming
things, ... all open at once, and be able to switch among them. Perhaps
switching to certain things that have been idle for a few days would take
a few seconds, but I still don't want to have to quit.

Crashes should affect this rule as little as possible.


Reliability/Security


I don't like machines that crash. Period.

In the event that a machine has a chance of crashing, perhaps TUNES
should provide some network-based redundency, so that in a machine were
to crash, its processes would not be lost

Let's have optional modules to support multiple user logins, object/file
security, etc., in a manner similar to "normal" OSs.


Universality


On a network of Tunes systems, I want to be able to log in anywhere
and have the same look and feel that I get when I log in at home,
or at least to have this true to the highest extent possible. If, at home,
I have a teal blue desktop background, four applications running with
a web browser window above everything else, I want to go to anywhere else
in the world and see the closest approximation of this possible. Perhaps
I'd be logged into a text system, and so I'd only be able to see one app
at a time, or perhaps some apps wouldn't be availible, because of the lack
of graphics. But to the highest extent possible, everything would be the
same.


A Reasonable Price Tag


If we decide to keep TUNES free, that would be great. Otherwise,
let's keep it so that individuals can obtain it.

Make TUNES software so modular that you can buy bits and pieces
of it to add to your system, rather than buying programs such as MS Word
that cost $300 when you only use about $30 worth of the features.


Compatibility


As cool as TUNES will be, it will be a long time (if not forever) before
we get enough software to support regular, day-to-day computing. In the
mean time, can we support some existing software standard?  (POSIX?
Win32?)




--------------25DD60C810BA--