Report on TUNES for operating systems course

[Francois-Rene Rideau]

> I am an undergraduate student(Senior) in the computer science
> department at UW-Parkside.
Hi!

> My group has been asked to do a report on your project.
I hope you also have more substantial projects to report about :(
I wonder how the work was distributed over the students,
and what the professor knows about Tunes, if s/he does.


> Specifically, we are to discuss the following points:
> 	1. What are the operating system objectives.
>
They are of two kinds of objectives: political and technical,
though there is no clear demarcation between the two kinds;
here are approximately from the most political to the most technical...

1- We want to provide as useful an OS as possible,

2- Because an OS is useful inasmuch as it allows
 interchange of useful information,
 the foremost principle is to design a system
 that allows better, smoother interchange
 of as expressive information as possible
 among humans and computers.

3- Because such is the brake to information flux,
 we want to reduce the money, time and proficiency overhead
 for both publishing useful code
 AND for integrating it into one's environment.
 -- hence there can be a fair free market for program modules,
 instead of the current racket.

4- the system must be as expressive as a system can
 [not to be as limited as current computer languages],
 so that
 not only local low-level syntactical things,
 but also global network-wide semantical things,
 so that computers allow people to go toward more abstract information
 (and perhaps someday the AI)
 instead of always being tied to the ground by low-level concerns.
 Anything a man can say about computer programs,
 the computer language must be able to say it, too.

5- All this means that
 a) small code fragments should be usefully publishable,
  instead of only huge bloated applications.
 b) the receiver has some means to be confident
  that the received programs works as it should
 c) all this should be done in a cost-effective way
  with respect to human and cpu proficiency, time, space, money
 -- actually, pick any two, you have the third:
 any solution to two of them is also solution to the third!

6-
 a) any code should come in portable self-contained modules.
  The language used should be maximally expressive.
 b) it should be possible to provide/require arbitrary
  logically expressible constraints on modules.
 c) The standard language should hence be able to efficiently
  express both those constructive and destructive constraints.

7-
a) arbitrary barriers between "normal use" and "programming"
 should be removed.
b) we want to remove all low-level constraints on the user:
 the user shouldn't have to explicitly manage persistence,
 network communication, encoding formats, CPU compatibility, etc.
c) The code writer should not be stopped by any barrier  preventing him
 to do high-level code
 by tying him to low-level details,
 or to munge with low-level details
 by not ensuring the semantical validity of such optimizations.

8-
 * The system as such needn't be compatible with any previous software,
  and won't be, because those software are written
  in unsecure stupid unexpressive languages.
 * However, Tunes can communicate with other systems,
  and reuse any previous data or protocol (particularly Internet stuff),
  while having facilities to migrate code.
 * The user can still run his old applications in emulation boxes,
  and POSIX will run in Tunes emulation boxes
  in the same way (and with the same interest) as DOS runs in POSIX boxes:
  no sensible POSIX user seriously uses DOS boxes or develops for it anymore,
  because DOS is so lame (and POSIX will be so lame to Tunes users),
  unless it's needed to run old software that hasn't been ported yet.

After that, it becomes technical enough
to go into your question 2/ and 3/ "features" and "implementation details"


> 	2. What are some of its features(e.g. how does it look to a user)?
>

1) The user will manipulate platform-independent objects,
 so is freed from concerns of architecture, bytesize/bytesex,
 cpu-type/revision dependencies, object file format, etc.

2) The user will manipulate implicitly resiliant persistent objects.
 = in
 instead of his having to explicitly save/restore/crash/recover them.
 to do point-to-point connections over a network

3) The user will manipulate implicitly global distributed objects,
 that are transparently accessed, replicated, migrated
 all over the network, in a transparent, consistent way by the system.
 = On current systems, the user has to manually/explicitly
  telnet, transfer data through sockets,
  checksum/verify everything, recover from errors,
  manage local/global resources, etc.
 = Of course, the advanced user still *can* manually manage those,
  to optimize his computing environment.
  He just is not *forced* to do it or to do it all;
  he can concentrate on what's useful,
  and be confident that the system will do the rest correctly,
  making full use of available resources network-wide.

4) The system will be persistent and distributed:
 objects can be migrated
 from computer to network to computers to disk to computer.
 = Hence, you can save your session on your pocket calculator,
  retrieve it on your desktop computer when you're at home,
  while the heavy processes will move to the a near unloaded CPU server.
 = All that will be done silently,
  and the system will respect your explicit constraints,
  but else do as it pleases to schedule objects in time and space.

5) The user will face a one unified environment that can do everything.
 = currently, the user has to learn thirty-six completely different
  task-dependent languages
  that cannot communicate with each other in any consistent way:
  point and click to select a simple job,
  ugly command line interface for more advanced jobs,
  with a stupid (COMMAND.COM) or powerfully complex (Zsh) shell,
  various application-dependent extension languages.
 = Tunes' UI does it all with a same language
  (includes both point-and-click and command text)
  that can dynamically specialize to whatever task it at hand:
  job control, text edition, database management,
  numeric computation, symbolic algebra manipulation, etc.
  Of course, there will be context-dependent specialized
  vocabularies, behavior, with user-defined objects/tactics.
  still, it will be essentially the same language,
  and inter-context communication should be a trifle.

5) User Interface would be done in a completely modular way,
 instead of requiring applications to include everything from
 bitwise management to interaction toplevel.
 = As an example of a fine-grained module,
  it should be trivial to add support for, say,
  another language (including non-ASCII input&output methods,
  sort methods, standard layout for dates, letters, system messages, etc).
  If the martians land tomorrow,
  anyone should be able to add martian-language support the next day.
 = As another example, user-interface would be object-based,
  instead of objects being UI-based.
  Hence, the same database application could automatically be run
  with a voice-based interface (for the blind as well as people
  who would not stay before a screen for some reason),
  without changing a line of code.



> 	3. What are some of its implementation details
> (e.g. how does it look internally)?
>
The problem is that there currently is no actual implementation :( :( :(

1) We will have a family of hardware-independent implementations,
 so that the user needn't ever worry
 about adapting software to his platform(s).
 a) the system-wide language standard
  will be a high-level language (HLL)
  with *NO* implicit system dependency (contrarily to C,
  whose integers and pointers vary in size from systems to others).
 b) there will be an interoperable binary format to exchange objects,
  including source and (semi-)compiled code.
 c) there will be half-portable low-level
  languages/formats (I prefer FORTH-like)
  adapted to common architectures,
  to be optimized/compiled for whatever machine the code will run on
 d) platform-specific preoptimized code
  and precomputed optimization tactics
  can be published for critical portions of programs,
  to replace generic platform-independent code when useful.

2) The HLL will be expressive enough
 so that just *anything* can be done with it.
 Particularly, the language should be *reflective*
 and self-extensible, so that
 a) code written in older lesser languages can be
  reused into emulation environment:
  for instance a family of C emulation mode to efficiently
  translate programs from various kinds of C coding styles.
 b) the HLL will be a safe language, w/o pointers et al.
  That's why a generic C emulation mode would be inefficient;
  but hopefully C programmers are good enough
  so that low-level hacks are isolated
  in a few modules (functions&macros) that we can replace,
  while the rest is high-level and easily typeable.

3) 
 a) ANY piece of software can reuse parts from ANY other,
   provided the specifications are correctly fulfilled.
 b) we use a specification system and theorem prover
  that can express just any logical requirement a code fragment may have,
  and any feature it might provide.
  = use of the using Curry-Howard isomorphism as in Coq
   allows an exact mapping between programs and proofs,
   and a smoother integration of the specification system
   as part of the programming system,
   using the very same tools to build proofs and programs.
  = We add reflectivity to it,
   so it works in a dynamically reflective system.

4) Efficiency is achieved despite
 reputedly inefficient meta-programmability
 through aggressive dynamic partial evaluation,
 which is much more general than
 just-in-time compilation:
 = a running object's execution ain't indirected
  into its meta-object's execution at runtime,
  but at (dynamic) compile time.
 = tight loops involving hardware dependencies
  need not go through library calls;
  small hardware-dependent routines (e.g. pixel plotting)
  are dynamically inlined in high-level code
  that is then optimized.
  When/if the object is to be migrated out of that
  video screen, the partially-evaluted code is invalidated.
 = particularly, there will be no runtime "kernel"
  as in microkernels et al, as all OS services,
  including security, etc, will come as objects
  that will be dynamically partially evaluated.
 = Surely, there will be some synchronization, and security tests;
  but these can be inlined, so no need for a runtime kernel.
 = Inlining, etc, can be done safely
  because we use a safe language with clean semantics,
  unlike shitty unsecure C that would fuck us from behind.


> 	4. What is good about it?
>
Everything, when it's done.


> 	5. What is bad about it?
>
1) It doesn't exist yet.
 Couldn't be worse, could it?

2) Also, the first versions will run
 On Top Of POSIX (or other operating systems), so
 = we don't have to rewrite device drivers, but
 = we can't provide real-real-time constraints.
  [virtual-real-time might be fun].

> 	6. How does it compare with other systems?
>
* Can't compare actual results since no actual implementation.
* Will be very different, and hopefully much better.
 see above for qualitative difference in *principles*.
* Initial implementations will be
 = slow overall by lack of time/money to optimize,
 = hopefully more responsive than POSIX by better design,
 = quick enough for everyday use by virtues of today's powerful hardware.


> 	The above questions are to be covered in an overview of the system,
> followed by a focus on a particular feature.
>    Any input from
> you as to an appropriate feature to focus on and as to any specific
> research material available will be greatly appreciated.
>
I fear there is no actual feature.
So if you are to focus on something particular, you might take
* reflectivity (see LISP systems; see our epsilon constructs),
* faithful object specification (see the Coq project),
* reflectivity-based UI (see epsilon constructs, tactics and logic programming),
* process migration (see the migration page),
* portable interoperable low-level language (see TAOS project),
* open free developed OSes (see Linux, HURD, etc),
* vaporware (ahem, I hope not forever; even the HURD is running today!).

I might have forgotten things about Tunes.
Please tell me/ask me...

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