GEN,ORG far13

[Michael David WINIKOFF]

> 
>  To me, an OS is an interface between the programs (that is, nearer or
> farther, the user) and the hardware, and for programs between each other.
>  We see with previous systems that what wasn't proposed as a standard with
> the basic system (as is delivered with the system package) could never
> get properly dynamically exchanged; hardly can it be filed if there is an
> international standard (example: pictures, more recently sound, in the
> near future, animations). No high-level standard could be achieved as no
> generic enough language was found to EFFICIENTLY replace all others (and
> it most probably never exist), and a high-level standard cannot support
> inter-platform data communication. So
>  For example DOS don't manage anything;
>  To show how embedding code and data IS useful, you can imagine how
> horrible it is for an user to see that existing apps don't have ALL
> the required features to treat his data, and that he only have choice
> between rewriting his own app (which even if he can will take a great
> amount of time and/or money, and won't even allow him to communicate
> his data to others !), or manually maintaining references through a huge
> database and not having the app do correctly the work expected and having
> your data take much more place than needed and still be limited in
> single entry size. Let me give you an example I know well before
> I continue with general ideas.
> 
[stuff deleted]
> 
>  Well, every one doesn't have the same problem, and the vietnamese problem
> can be (partly) solved with unicode. But there are many many similar
> problems (for example mathematical and/or symbolic expressions and graphs).
> And you can be sure there will always be a need for new data formats. So
> if the system doesn't allow a standard generic interface for data AND
> accompanying code, you will forever have to recompile your apps each
> time you want to include a new data format, provided the app was built
> to accept change (because IT had the OO system the OS failed to implement)
> and you have the app's sources (not all are public) and someone was
> patient enough to implement a patch for each application you use.
> When the gap between end-user objects and system capabilities becomes too
> large, there will just be another funny groups like moose who'll want to
> rewrite the system again from top to bottom !
>  That's no fun. Object embedding should NOT be let entirely to application
> writers or we're not getting anywhere. Of course apps should be able to
> use as they will local variables; of course they can publish new object
> formats; but there should be a format-describing standard so that
> automatic format translation (including real-time exchange with the 'same'
> object being accessed in different formats in more than one window) is
> easy with as few user work as possible (none is ok). Of course you can't
> foresee everything; that's why the format itself must be extensible, and
> flexible; it should not so much describe how raw data is organized (which
> can be horrible; see a LZ compressed sequential access only file), but
> how it can be accessed, and what properties it has (logical propeties,
> scheduling limitations, quick or slow aspects); it should be generic
> so that you can build general purpose apps (to stick to my example,
> the database should be able not only to keep french/vietnamese data, but
> also to sort it the french/vietnamese way, which is not a mere
> lexicographical on the letter order, as yo take accent order after
> letter order, and letter order not being harware coding number order,
> as some letters have been deplaced above the 7 bit limit).
>  You won't ever be able to dynamically manage data, and/or to manage
> subdata otherwise, so that the system is unuseful. We're not building
> a system JUST to implement a new trick we like; we're also building a
> useful and easy system for the end-user, both computer-scientist or not.

This is analogous to device independance.
Consider a program that works on pictures.
You can't seriously expect it to do something useful with a sound file.

Bascically what I'm saying is that a typical program/application should
be polymorphic in the sense that it'll work on any data type that has
sufficiantly close sementic properties.

(Much like Unix programs work on files/terminal/pipe)

I agree that this is a good idea.

I think Amiga OS 3.0 has done something along these lines. Anyone have more 
details?


> 
>  Moreover, I don't see what a NEW OS would bring but that. All the rest,
> Unix that; and Unix is widely spread, and has good implementations on
> any computer, including PC's (see linux), Mac's, Amiga's, etc. You just
> want standard calls for threading, small files, your language and/or
> a GUI ? Just write (yet another :-) library to do it and a server to
> centralize calls from multiple end-users; don't bother rewriting all the
> system. And most probably an existing extension of Unix does it; you

Good point.

The conclusion of this is that we shouldn't bother writting the system
from the bottom up but build it based on some multitasking OS.

Any comments?

The impression I got from Dennis' original mail was that he didn't want to
do this since Unix'es tended to be big.


> just have to find it on the net and recompile it. You don't find it
> standard or extensible enough ? Haha ! Then now YOU ask for the standardness
> and extensibility you previously refused when writing the system.
> 
>  Well, I hope moose is not going to correct only implementation problems
> (that is just better implementing what was to slow/clumsy under previous
> systems), but also and mostly conceptual problems (that is, what makes
> other systems a nuisance to use, and what forces you to go round the system
> instead of using it).
> 
> 		     ,
> 		  Fare,
> 	200% time moose programmer,
> 	   computing day-dreamer.
> 
> P.S. I dont have time to re-rea all that, so excuse me if there are mistakes,
> mistypes, omissions, etc. An added correction may come.
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.