------------------------------------------------------------------------------
[MOOSE Manifesto]

Status:
------
	everything here is first proposed and thus not yet contradicted.
	Later drafts will be divided according to status.


What is an OS
-------------
	* An OS is essentially a frame for computer programming semantics.
	* It should ideally provide features so that any high-level
	 construct you use can be directly interpretable inside this frame
	 (else you'll have to build your own intermediate system).

What's basically WRONG about currently widely available OSes
------------------------------------------------------------
	* Current OSes are all based upon "C", and C's semantics is the frame.
	 This means no protection apart from huge processes, difficult error
	 recovery and parallelization, flat memory model, no easy reflexivity
	 (=producing code from code), no true dynamic (runtime) linking/code
	 enhancement.
	* The OS also offers standard libraries and tools of code&data that
	 handle common user data. Most of it is dedicated to manage special
	 cases of argument and error verifying and reporting (not even
	 handling !) and I/O multiplexing (which does not save you from
	 doing your own I/O multiplexing as no generic tool is provided).
	* Due to C heaviness, most of current OS is a burdensome multiplexer/
	 demultiplexer and straightforward call translator, that is very
	 difficult to extend.
	* Due to C poor error handling, processes shouldn't be expected to
	 be permanent AND carry important data. Modified data must thus be
	 saved on disk regularly; but disk security and error handling must
	 then be assumed by the user program, and it must rewrite entirely
	 its data saving library as no generic data saving is available.
	 Modified code that was a challenge to produce is a double challenge
	 to save. That means any complicated object persistency is very
	 difficult and heavy to obtain (but not impossible) under these OSes.
	 Databases are heavy and very prudently used applications, whereas
	 the good ol' text editor becomes the tool of choice for everyday
	 small databasing.
	* Due to poor C parallelizability, distributing data (not to talk
	 about code !) on a parallel machine and/or on a network is another
	 kind of challenge, and can't be done directly (doing it IS rewriting
	 an OS layer). That's why we always hear about the centralized
	 "client/server" model as the state-of-the-art technique, whereas it
	 is only the (reliable but) stupid slow straitforward oldest technique
	 available for sharing data.


What is OOness
--------------
	* Object-orientedness is a means by which all this multiplexing stuff
	 is done by the language implementing system, not by the program
	 writer.
	* an OO OS will provide a generic multiplexing/demultiplexing
	 interface able to understand all kinds of high-level and low-level
	 calling convention, and that's all.
	* An OO OS is NOT only an OS internally written in an OO language
	 making maintenance simpler but not changing the interface.
	 It's an OS whose entire interface is designed in an OO way; if it's
	 written in an OO language, it must still export the OO facilities
	 dynamically (which means an open language with partial evaluation
	 and/or reflexivity, which C++ is not, for instance).
	* Libraries (purely low-level libraries corresponding to what's
	 called drivers on older OSes) are just objects that can connect to
	 this interface.
	* The interface provide standard nodes to connect on. This
	 actually is a conventional mechanism orthogonal to the interface
	 implementation itself. Standard libraries connect on the other side
	 of these nodes, to provide their standard services.

What is persistency
-------------------
	* Persistency is having objects survive a session. i.e. when you
	 shut down the system and relaunch it, the object is still here.
	* Code may be persistent as well as any other object: you shutdown
	 the computer, but your computation will automatically go on when
	 you launch the system again. A "save game" option in a game will
	 thus simply consist in saving the running game object (a "save
	 session" option is the same for any software).
	* The system thus behaves like an object-oriented database, that it
	 actually is.

What is secure formal programming
---------------------------------
	* Formalization/Prototyping: when designing a program, you put
	 together both the code and some specifications about what it should
	 do. The system constructively verifies that the code complies to the
	 specification.
	* In such a way, the compiler can ensure there will be no run-time
	 failure or bugs (unless both the code AND the specification are
	 jointly buggy) and/or tell exactly where to add error managing.
	* Of course, a danger comes from low-level I/O drivers not being
	 well specified, but we can under-specify them if it suffices to our
	 needs.
	* Underspecifying (telling the computer "trust that code anyway if
	 you can't prove its correctness) is the way we'll use when we don't
	 have time to prove our software.
	* Undercoding (telling the computer "if you can't figure out how to
	 do it, ask the user to do it manually and just verify the result")
	 is the common way to have secure but not completely automatized
	 programming.

MOOSE semantics
---------------
    Object-Orientedness
	* MOOSE considers interfaced objects. Each such object must abide
	 by the laws of MOOSEing. Other objects don't quite exist for MOOSE.
	* Interfaced objects can be any size, tiny to huge. Of course, it
	 is costly interfacing tiny objects, but you only need interface
	 them 'til they are linked. If they are linked once, just forget
	 the interface; if they are linked very often, the interface is
	 worth its cost.
	* Linking objects one with the other is one function of the OS.
	 Another one is to close existing links. An object that does no
	 more export some information may then be optimized so that this
	 information disappears if not used internally. This process is
	 done automatically and at run-time. That's partial evaluation.
	* Information exported by interfaced objects:
	 - external objects accessed.
	 - internal objects exported.
	 - properties required and or provided by these objects. This allow
	  a proof of object linking correctness, a great concern for
	  reliable software. This is the main entrance of

    Secure formal programming
	* The system will provide standard nodes to verify or produce
	 code and/or specifications that comply to each other.
	* When linking objects, it will ensure the correctness of the
	 linking (whereas the only correctness in current languages is
	 typechecking, which is quite good but just not enough in the
	 general case: it's a formal lossy interpretation, some
	 deterministic hence under- specification).

    Persistency
	* Not only can the system link, but it also can unlink (still)
	 exported objects, and save each object separately on disk.
	* The OS itself provide a way to ensure consistency of the
	 saved data. Data written on permanent media (disks) will not
	 be acknowledged, and older versions not erased, unless it has been
	 marked consistent by the system.
	* It also ensures that data is saved regularly, thus
	 achieving true reliable persistency.

    Parallelization
	* Many objects live and evolve at the same time.
	* This means the system is somehow "multitasking" as it simultaneous
	 objects can be computing without waiting for all the others to have
	 finished.
	* ...Garbage collecting...
	* ...sharing context
	* ...extending and overriding one's own context...
	* ...accessing another one's context (if exported)...
	* ...system verified linking preconditions on exports
	  can ensure arbitrarily secure exports, not only
	  stupid sstrwxrwxrwx rights...

