[Oberon] Re. linux oberon ++ Aos documentation

[Chris Glur]

Jan de Kruyf wrote:-

> The ETH version is too old for my box it looks like
> It gives a segmentation fault on installing.

AFAIK the latest PC must run all 386 software ?

But yes I get segmentation error crashes too.
So I continually save my work.
Since leo takes about 3 seconds to start, I'm using it as
an editor for any linux directory.

`lob $PWD` runs a copy in the 'present directory'
so that you've got a good multi-frame editor [normally using
EditTools.StoreUnix & EditTools.OpenUnix] on linux files.
I've got 4 running at present.
I consider each directory as 'an object' and lob as an inherited
method, which can directly edit any file in that dir, without
navigating through the directory-tree.
Navigating the dir-tree with linux -> mc is easier; and when
I get to the dir, it's easiest to just start a new leo on/in that
dir.

lob is the original starter-script, with some directory/s modified.
IIRC the original starter-script had a miss-spelling of "noth??"
I can't remember why I had to use the no-thread version.

You've got to make utilities to eg. transfer  path/fileS
to and from linux.   I develop an extra little 'utility'
every month, so that the productivity keeps increasing.
====================
A. Fischer wrote:-
> Where on earth did I mention a diskette in that short text?
That's why we don't TOP-POST ?
> The only way is to customiye whatever you believe is necessary 
> and to burn a CD.

Admittedly diskettes
are obselete, but is it documented how/where to 
insert the edited bytes in the CD image?

It's impossible tedious to test the many configuration
combinations manually. 

A 'staged' approach should be laid out.
That's why I asked " If it doesn't respond to Ctrl/Alt/Del
then it hasn't passed stage N of the start-up proccess".

Repeatedly guessing lucky-numbers is not good science.
A good way is to have confirming output at several stages.

The way that linux displays the progress during booting
is potentially very valuable.

If for an unlikely reason, the display has to be switch out of
'DOS-display-mode' early in the boot-chain, a beep-count
could mark the problem stage.

I guess an incrementing beep counter, tracing the boot
process would be unacceptable, unless it was dis-ableable?

== Chris Glur.