Please help us make the project more understandable
to you and other readers by asking questions,
suggesting how the FAQ could be reorganized, etc.
More generally, this FAQ, as all of the Tunes project,
is currently under active construction.
Please help develop it with your feedback.
Please note that this mini-FAQ only addresses general questions about the nature of the Tunes project. Specific and technical questions about particular Subprojects are dealt with in documents from those subprojects.
If you still wonder about what Tunes is, please tell me (Faré), by sending e-mail to rideau@clipper.ens.fr. Mind, that is how I happen to know which questions are frequently asked ! If no one asks me clarifications, I cannot adapt the FAQ to real questions of people. But of course, do not ask again some existing question, unless you're not satisfied with the answer (-8.
Section 1: Project Goals
Section 2: Project motivation and history
Section 3: Project organization
Section 4: Project Advancement
Section 5: More about the project
the Tunes project claims to bring into an OS
lots of features thhat already have been separately implemented:
persistence, distribution, type-safety, garbage-collection,
specifications and proofs, open-implementation, hardware-independence,
etc.
However, these features have never been gathered on a one system,
and we believe there is a deep architectonic reason about that:
current computing systems just do not allow system features
to work together if they have not been co-developed,
while such features as we listed
are complicated enough so that
an efficient, reliable implementation
must be done by an expert.
We at the Tunes project do not pretend to be simultaneously
experts in all the above fields;
but we do pretend to provide a system architecture
that will allow experts so separately specify and implement
their respective features,
yet have these features work together.
We do pretend to decouple the specification of the features,
their implementation.
We claim to achieve what others failed to do,
by use of an essential tool that others have
unjustly but volontarily ignored,
despite its being naturally obvious,
because of a quasi-religious fear
of well-known paradoxes
that a naive approaches to it could raise:
I'm talking about reflexivity.
Language designers have voluntarily over-restricted
the scope of their language so that they
could understand whatever use their language could have.
People having achieved some kind of open-implementation
never dared to use Turing-expressive filters,
and hence either would open the implementation
to serious undetectable bugs as well as minor real enhancements,
or they would limit possible enhancements in such a way
to make their implementation not so open as claimed.
...The silly idea that a perfect program source
should include no data from computer interaction...
...because people fear they could not control it...
...a programmer ultimately controls the computer,
hence does control the feedback...
...if someone is too stupid to control what he does,
he shouldn't program...
...actually most people are intelligent enough,
but do not try to learn techniques for feedback control...
...surely Turing expressive filters mean
that compiling the program may not finish,
but only for buggy programs;
this is definitely NOT a problem for finished programs;
surely this means that a correct program with holes
that could be compiled under some circumstances,
with proper compiler tactics,
would not compile properly under other circumstances.
But this is precisely because the program is NOT finished:
it does contain holes.
The simple solution is to consider as the finished program
not the correct holed human written source,
but the human written source annotated by the hole-filling
proofs that the program can be completed into a finished,
hole-free program, which will indeed compile properly
independently of the compiler tactics.
That is, to make explicitly appear in the program
data that was implicitly added by the compiler during the
successful run.
This data can or not be then reworked by the human and
integrated into the main sources.
...again, programming is an *interactive* activity...
...people debug...
...why arbitrary limit something
(in that case reusable information
available from computer feedback)...
...at least why limit it for others?
if you want to limit yourself, please do,
but don't the fuck limit others because of your own fears...
...you fucking asshole deserve only shit who will impose
your fascist limitations to me...
...note that I do respect and thank
those who *allow* me to limit myself;
I fuck those who'd *force* me...
Section 2: Project organization
What are existing structures ?
To ensure development openness, a Charter
ensures that anyone can freely join development, that decisions are taken
fast when possible, but democratically in case of disagreement, and
dictatorially in case democracy fails to yield a decision.
How can I participate to the Tunes project ?
You can contact me (as main project coordinator):
François-René RIDEAU
6, rue Augustin Thierry
75019 Paris FRANCE
What about copyright and property issues ?
Section 3: Project motivation and history
Why such a project ?
"to make an apple pie from scratch,
you must first create the universe"
.
How did it begin ?
What will it bring that other systems don't ?
What won't it bring that other systems do ?
What does liberalism have to do with this project ?
Section 4: Project Advancement
What is the latest release number ?
What are supported hardware architectures ?
and a second portable one for on any 32-bit+ computer
with a some POSIX-ly correct system.
What are supported software standards ?
Section 5: More about the project
Where to find more information about Tunes ?
What are other related works and projects ?
To Do on this page
Because one of the goals of Tunes
is reliability/security through provability,
whereas the utter unprovability of the underlying OS
makes it a very relative notion.
Of course, this doesn't preclude the use of an experimental
platform that runs over POSIX,
only that platform must sacrifice part of the real-time control,
of the data security, of the resiliance to bugs, of potential performance,
etc.
Actually, the Tunes project is rich enough that even with
this sacrifice, it can be a useful software.
Still, a fully-functional Tunes must be essentially a standalone OS.
Faré