ARGON

[Francois-Rene Rideau]

> Dear Tunes People,
> 
> If you wanna come eye the competition, I've recently updated my ARGON 
> page with the most recent incarnation of my plans. It's at 
> "http://www.abwillms.demon.co.uk/os/"...
> 
I cheerly welcome competition (BTW, where are you, Jecel?).
I'd have lots of comments about ARGON,
but no time to write a detailed criticism now;
I hope someone on the list will post a review.
Actually, I hope not only Argon,
but all the software in my Review/ pages
will eventually be reviewed...

Here are some quick remarks:

General design:
* You say "So it is important to find the correct level -"
	  "too abstract, and it's slow. Too concrete, and it's inflexible.",
 hence looking for a static compromise.
 the Tunes approach is to build no such compromise in the OS:
 let the user reflectively define their needs and adapt the
 concrete implementations and abstract specifications.
* It is unclear how ARGON behaves wrt to persistence, distribution, etc.
 How different in principle will ARGON be from traditional OSes?
 Any new OS has tradition against it.
 It can be successful only if it brings some deep structural difference
 that brings features impossible to achieve on traditional platforms.
 I know what Tunes wants to bring: clean reflectivity.
 What does ARGON bring?

A Few Details:
* why create (layer8) your own 16-bit character standard
 when there's Unicode already, of which you are aware?
* why limit to 8/16/32 bit architectures,
 when 64-bit are already out,
 when the cheapest performance/cost ratio is 20/21-bit,
 and who knows what the future will bring?
* why should there be files,
 and why must their attributes be text stuff?
* why make a /tmp directory equivalent,
 and force people to manually avoid clashes,
 instead of just providing scoping?
* likewise, how will you organize the system cache?
 I like the idea of applications being able
 to notify what is a cached value as opposed to a source value,
 and how much the cached value would cost to compute back,
 vs how much it is expected to be used.
 This is not a trivial task...
* As for object types, I hope you realize that Acorn and MacOS
 object tags are registry-based conventions.
 The problem is that these low-level systems do not enforce
 conventions, so that you face basically the same security/reliability
 problems as with untyped systems, just having an added special attribute.
 Are you providing more than that?
* As for object names, I think you're overspecifying things:
 = surely, internal format should be binary
 = case (in)significance can pose compatibility problems
  when trying to read/write from existing filesystems.
 Why not let each filesystem choose its own significance,
 perhaps asking it for canonicalization?
* How do your "layers" sit on top of each other?
 Are they really layers, or modules?

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