[Oberon] Re: Oberon digest, Vol 1 #18 - 5 msgs

[muller at inf.ethz.ch]

"Ghost in the Machine" <cangelich at famvid.com> wrote:
> Once a program has verified that it's CWD is a new directory (or subdir)

The notion of a "current working directory" is useful in command 
line shell-based user interfaces, when the current directory is 
always displayed in the command prompt.

In windowing interfaces (e.g. Oberon's textual user interface, or 
MS Windows) a global "current directory" is a bad idea, because the 
different windows represent different working contexts.

If the current directory is somehow bound to the window context,
and is made visible, it could be useable.  I don't think this
would fit in well with Oberon's user interface concepts.

Chapter 2 "Basic concepts" of Wirth and Gutknecht's "Project Oberon"
book is good background reading on this topic.

> > OFSTools.Mount AOS AosFS IDE2#5 ~
> > OFSTools.Mount C FatFS IDE0#1 ~
> > OFSTools.Mount RAM RamFS 512 2048 ~
> 
> I may have missed the "C" in "CFatFS"?  That looks different to me
> right now.

The "AOS", "C" and "RAM" above are the prefixes under which the 
file systems are installed in the file name space.  So instead of
"C" I could use "DOS" and then access a DOS file as "DOS:/filename".

> The Native Oberon OS  is installed into one large (30 meg) file on my
> hard drive. I had the impression that within that file Oberon was using it's
> own file structures.

Native Oberon has two "native" file systems: the original native file
system (NatFS) and a newer file system compatible with Aos (AosFS).
Since the new file system supports larger partitions and files it
is now the default.

> If Native is not Aos what is it?

For some background on Aos, see:
  http://www.oberon.ethz.ch/active/

The system based on Aos was recently renamed to Bluebottle:
  http://bluebottle.ethz.ch

> I understand that you, and others, have other priorities that are of more
> importance than Oberon is right now and I agree with your priorities.

I'm glad you understand.

> I guess I'm a bit surprised that after a decade or so rather than become
> more organized Oberon seems to have splintered off into multiple
> versions each one at various stages of development.

A strength of Oberon is that it is simple and flexible enough to
easily adapt to different requirements.  That may be the reason 
for the many independent developments, which can be bewildering
for a newcomer.

With ETH Oberon we have been shifting slowly to a more distributed 
development environment, with people outside the ETH contributing
and maintaining ports (e.g. Günter Feldmann, Edgar Schwarz, 
Günter Sawitzki, Peter Matthias, et al.).  This is becoming more 
important now that several "Oberon" PhD students have finished 
(Erich Oswald, Emil Zeller, Patrik Reali and me) 

> A suggestion would be to unpack all those MODs into
> separate files on the FTP server in a directory for that
> purpose, one for each ARC or ZIP so that people like
> myself can grab just the MOD they need at the time and
> not wrestle with entire archives of source just to fix one
> MOD?

It would be very inefficient for the various ftp mirrors to
transfer all the little files.  We are considering better
ways to manage the sources (e.g. CVS), which might address
this problem also.

-- Pieter

--
Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich
Native Oberon OS: http://www.oberon.ethz.ch/native/