Compatibility?

[Francois-Rene Rideau]

Hamdani <hamdani@indo.net.id> wrote:
> 	Dear Sir,
> 	I want to ask important question about your
> new OS:

Dear Hamdani,
   my OS is unhappily still in design phase.
Though most of the design is clear to me now,
I have to write articles about it,
and find some official job to implement it,
as I currently lack spare time,
earning my daily bread as a math teacher in high-school.
   So the bad news is that the OS does not currently
even have running Beta code.

> 	1. Is there any translator/porting tools
>            for apps from Cobol, RPG, CGI, Java, C, C++
>            PASCAL, Clipper, FoxPro, Basic, etc to your platform?
>
It is intended that there be such reflective translators.
Reflective means: the translator can be dynamically enriched
so as to better translate one's particular code,
instead of there being a unique one-size-fits-all unadaptative translator,
that never fits anyone's needs,
or produces unmaintainable code.
   Holes in automatic translation to software in a safe language
will then correspond to bugs, or to low-level implementation details
that can be abstracted out of the translated code,
and added as implementation notes about it,
to be used or not by the optimizing compiler.
e.g. systematic manual reference counts
in implementation of C++ objects can be translated
into an implementation note saying that objects might be
garbage-collected according to a reference count;
the compiler might use another GC instead,
C++ objects that would forget to manipulate the count
would be pin-pointed, etc.
Translation to a safe language could then also have the side
effect of helping to find bugs in the original program.
   Of course, appearance and maintenance of any particular translator
will depend on market demand.
But generic tools and standards will be established to
have such translators work seamlessly in the system.
   When a beta version is up and running,
I intend to take personally care of a C translator,
so that I can steal code from Linux,
and obtain a POSIX emulator for Tunes...


>         2. Can your new OS read various data format/image?
>
Currently, it just can't do anything :( :( :(
Eventually, it should read any format,
and the system interface be such that new formats
be dynamically added in such a way that
all applications can see any new format included.
   Well, it should be fairly trivial to choose
not restrict usage of unsecure fileformat drivers,
so that they do not constitute a security hole.

>         3. How to handle Endian problem?
>
Two hosts with same endianness will use this endianness
when communicating, speeding up marshalling.
When such assumption cannot be made,
the standard network protocol (big-endian)-: will be used instead.
   This is a particular case of what reflective programming allows:
instead of having a one canonical system-wide representation,
an object is always optimized for its current use,
which is safe because the system guarantees consistency;
tactics to optimize objects can be dynamically added,
and take into account run-time feedback.
The system will ensure that implementation tactics are correct,
and do not change the semantics for objects;
it will also ensure that only reversible tactics will be used,
unless it is specifically stated that no further migration is intended.
Of course, it will be possible to write and use tactics
that have not been formally proven correct.
Only these tactics will be tagged as such,
so that anyone using them is explicitly taking one's responsibilities.
   In comparison, current systems force a unique representation for objects,
which must be statically determined once and for all at compile time,
before the programmer has any information about the
actual conditions in which the object will be used.
Any attempt to change the representation for an object
in current systems means throttling execution of the whole system,
dumping all data to a file
(which must have been foreseen while initially compiling,
and manually implemented),
writing manually a conversion tool,
and recompiling the full system,
all that without having any guarantee that conversion will be correct
(hence great demise if there was a bug,
by loss of the entire run-time data).
This makes dynamic optimization and fine-tuning
extremely costly in current systems.
Also, because current development systems are not reflective,
any optimization technique that involves global code transformation
must be applied by hand, which is a source of potential bugs...


>         4. Can your OS run on a single system with multiple
>            types of CPU?
It should, See Tao OS for an available system that already does it.
Similar techniques will be used, with several differences:
there will not be a one universal virtual processor for the OS,
because this would prevent adaptation of the OS to future architectures;
instead, the common code representation will be a high-level language form.
However, local substandards can be established
as reflective implementation tactics,
so that a group of computers will always try to communicate
with the most fit common representation instead of the highest-level one.
   E.g. when migrating between two Pentium PCs,
code Pentium-optimized intel assembly code will be used.
When migrating code from a Pentium to a PowerPC,
a common language for 32-bit computers will be used,
much like what Tao OS does.
When migrating between completely different architectures
(say, from a cluster of F21 processors to a PC),
the high-level representation will be used.
Code can also be specialized for other things than CPU architecture
or word size, like video card architecture, presence of FPU,
local memory layout, other code with which to run, etc.
   This means that code will dynamically specialize for
optimized use in the current hardware/software context,
but that specializations are automatically invalidated
when objects migrate to a context that makes their required assumption false;
this invalidation of optimizations will be accompanied by
a reverse-transformation on data, so that the migrated object
keeps a consistent state accross migration.
This of course limits the possible optimizations done on migratable code;
objects known never to migrate can of course
be subject to irreversible optimizations.

>         5. Is it possible to run your OS on samll embedded
>            application? What is the minimum hardware requirement?
The goal is that there be *no* minimal requirement for a target system:
everything is modular, *without a kernel*,
so that only needed components are installed;
of course, there must be lower-level modules than other,
but they won't constitute anything like a compulsory kernel,
as they could be dynamically replaced,
and would not be a centralizing service provider.
   The minimal requirements for an interactive system should
be any PC-class computer (more or less powerful,
depending on the bells and whistles included as separate modules
in the user interface).
The minimal requirements for a comfortable development system
will be a serious workstation with tens of megabytes of RAM,
and several times as much disk space.
   It is expected that the system size requirement grow slowly
with the addition of Tunes-developed features,
even though Tunes packages might each take more space
than an equivalent package written in traditional systems,
because package sharing will be much greater.
   However, additional software to be used in compatibility mode
(X servers, TeX, commercial software) breaks this sharability,
and would take the same place as they do on their original systems.
Tunes is expected to eventually provide a Linux emulator
that can run native Linux binaries.
If Tunes is a commercial success, it'd be nice to port WABI to it.
   All these are long-term plans, of course.
But the design of Tunes make it possible to envision that,
whereas all these are not conceivable in a system like WindowsNT,
where everything comes in huge size: a huge kernel, huge applications, etc.

> 	At present I am running apps using ordinary PC+
> Mainframe card and also PC + PowerPC  cards.
> I manage several minis (AS/400, RS/6000) and Mainframe.
> Thank you very much for your kind attention.
   I never was very interested in minis and Mainframes.
It seems to me that lots of cheap computers running
a distributed OS in a network can achieve through software
more performance, reliability,
than a one big computer can through hardware
(see Amoeba, Plan9, and lots of such distributed systems):
there exists software protocols that guarantee that
even though one computer may stop operation,
the rest can adapt and work seamlessly.
   Of course, this also means that formal methods be used
to prove the software protocols correct wrt to a well-established
specification that should include fail-safe operation,
which is not a trivial task at all.
But was your mainframe proven correct wrt such a specification?
   Anyway, the Tunes design shall not make it impossible
to port it to any hardware, including minis/mainframes,
embedded systems, if anyone feels it worth.
The general design shall not rely on anything like word length,
endianness, memory size, etc,
but should allow versions to be optimized for whatever hardware
is present.

> Best regards
> (Hamdani)
> CIO
> Personal opinion.

Cordialement,

== 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/"