Retro and the implementation chronology

[Pete Gonzalez]

Ken Evitt wrote:
>[...] It would be a royal pain in the ass
>to implement any kind of TUNES-like system on existing systems and then try
>and phase out the underlying system. With Retro, instead of phasing anything
>out we can write a system from the ground up that does what we want it to
>do.

Hardware is constantly changing, and so are the low-level operating system
components built upon it.  High-level components are dynamic also, as user's
needs change and as new algorithms and ideas are continually being discovered.
Thus, I believe you will ALWAYS find yourself "phasing out the underlying
system."  I thought the whole idea of the HLL and kernel-less OS was to make
this "phasing" task easier; Tunes can provide a high-level computing
abstraction that allows old code modules to be dynamically and reliably
adapted to new uses.  The goal, then, is not to build The Final OS, but to
render OS's irrelevant.

>From this perspective, device drivers, filesystems, process schedulers, etc.
are merely "hardware" details.  I would argue that Linux, Retro, or even
Win32 (!) are all equally suitable foundations.  Pick whichever one has the
most complete support for the hardware you use, and build from there.
(On the other hand, maybe I'm understressing the "E" in TUNES.)  ;-)

Pete Gonzalez