Guido:
Thank you for your comments, and please pardon my delay in replying -- my personal mail gets an incredible amount of spam, so I don't check it very often.
> -i found it difficult to install (got only to the ztstflp, booting
> it gives a lot of messages and the "kdb>"-prompt after looking for the
> harddisk partition, if it would help i can give more details. I
> used Suse-6.2-compiler&tools.
The SUSE tools are almost certainly not going to work. I recommend that you build the cross environment and use that instead. Apologies in advance for the build problems with GNU Make; they seem to have set up a version of autoconf that does the wrong thing in the makefile.
> IMHO, I suggest a howto document describing all the
> necessary steps, and what it is able to do then, all
> in a single document.
The release notes were trying to do that. Things have evolved, and they need to be re-examined.
> -looking trough the sources i had a quick look at bcopy.S...
There was indeed a bug. I have fixed it in my local copy, and will check it in soon. Thank you for pointing it out.
> -Reading the documentation i miss so far something
> about persistent hardware state (e.g. grafics card,
> tv card). Some of these are unlikely to be made
> persistent with a memcopy...
Hardware state is not persistent. It's state is reinitialized on each restart. This is generally the right thing, since connections need to be reauthenticated in any case.
> I still have some trouble with data only beeing stored
> in processes. E.g., i draw some grafics in (the
> hopefully EROS-ported Gimp) for my web page, then
> i minimize the window (exit would destroy the objects)
> and can integrate them in my web page or use them
> in an other application. If, for some reason Gimp crashes
> (unrecoverable for the keeper), all my images will be lost.
> More, over the time the number of (open) images in
> Gimp will [grow very large...]
You have made a very natural error of understanding.
It is not expected that GIMP (to use your example) would retain all state within itself. Rather, it is expected that GIMP would save and load these objects as it does now. However, the notion of a "file" is implemented by a process rather than by the operating system. Alternatively, we might imagine some well-defined "bitmap object" (perhaps a file object specialized to store bitmaps). The GIMP application might be built around this object. When the GIMP application exits, the bitmap object is left around in a suitable directory.
Does this make matters any clearer?
> A filesystem alike directory tree is at least for
> me quite easy to remember.
Indeed, though I think you mean "a directory tree" rather than a "file system". It is the naming discipline that helps you. This naming discipline is *one* of the features of a file system. The file system typically *also* implements stabilization (i.e. writing things to the disk). In EROS, the second function is not necessary, and it is possible to entirely replace the file system object easily (and even to debug it).
> Is it still true, that there is only one complete checkpoint
> guaranteed over all time? What happes if (Murphy knows)
> exactly here a glitch or bad sector apears?
In KeyKOS, it was possible to write checkpoints to a tape. This allowed you to recover any checkpoint you like. If you don't do this, there is a small amount of critical system data that needs to be replicated, and the rest is no different from losing a disk sector in a UNIX file. There are multiple superblock equivalents in the EROS volume layout.
> How about removable media for data interchange,
> will it be possible to change EROS volumes with
> someone else, or only the old way over filesystems?
It is not really sensible to exchange EROS volumes in this way, as the volumes don't stand alone; the whole is a single system. It remains possible to exchange things via conventional file systems.
Thanks again for your interest.
Jonathan S. Shapiro, Ph. D.
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085 (Tieline: 863)
Fax: +1 914 784 7595