[Oberon] User report on LNO

[easlab-absa]

I'm writing this from LNO, which I got working again, after several
years. 
[System.Time 15.04.2011 19:39:05
ETH Oberon / Linux Native 12.Jan.2002]

The value of LNO, for me especially, is that on the same machine,
together
with 'ETH Oberon for linux', I can access the Native Oberon partitions,
where I've accumulated a lot of valuable files during the years that I
used N-O, before 'ETH Oberon for linux' became available.

Under linux, you've got the most advanced internet facilities,
and recent hardware drivers,
and an 'unlimited' directory-tree,
and facilities like *.pdf handling, which ETHO lacks;
and with LEO and/or LNO, you've got the superior 'text handing'
capabilities of ETHO.

So together: linux + ETHO gives a powerfull/productive system.

A disadvantage is that, after you've used it for some time, you
can have a nervous breakdown, when forced to use the
lame-cartoon-Micro$loth-Windows system.
You develop unrealistic expectations.

Linux.Tool reads:-
> To mount a second oberon disk file, Disks has to know about the 
> file before. This is done by 
> 
> Linux.OpenDisk	/dev/hda1
> OFSTools.Mount	Old NatFS /dev/hda1
> OFSTools.Unmount	/dev/hda1
---
I would rather say:-
Multiple files and N-O partitions are each mounted via 2 steps, eg:
Linux.OpenDisk	/dev/hda1
OFSTools.Mount	<chosenName> <FileType> /dev/hda1

Under N-O mounting partitions ...etc. was simplified by
just 'selecting the required switch in the list':-
Configuration.DoText MountSocEcon
Configuration.DoText MountAImisc
Configuration.DoText MountPersnl
...etc.
Configuration.DoText MountMed  
Configuration.DoText MountTelCom
Configuration.DoText MountLegal
...etc.
Where each eg. MountMed looks like:---
!OFSTools.Mount  Med  AosFS  IDE0#39 ~ 17 Oct 2005
!OFSTools.Mount  Med  AosFS  IDE0#14
OFSTools.Mount  Med  AosFS  IDE0#08  ~ 10Feb 2006
! OFSTools.Mount  Med  AosFS  IDE0#08  

! System.Directory  Med:*
! OFSTools.Unmount  Med
!  SmartDir.Directory Med:*\r3
! Med:SearchTemplate
-----------------------
And the same format applies for LNO where I've just
derived MountMedL from MountMed .

ETHO is too easy!

Some of my N-O partitions don't mount.
But the oberon.log trace might help to debug that.
Reading the literature, shows that the development of
partition-tables, over the years has been inconsistent;
but redundancy has allowed work-arounds. [Linux doco
mention some errors/inconsistencies of FAT.]
I'm suspecting that my partition-tables, are not 'good
enough' for LNO, but the systems that HAS been using
them [N-O], used a work-around, or didn't do the 
extra checks which LNO does.

Also, when I switch-out of LNO, to write elesewhere,
and return to LNO, I've lost keyboard inputability.
Under ETHO, it can take quiet some time to realise
that the keyboard is not working -- with all the tasks
that are done without need to keyin.
And then ASCIITab.Tool is also a good on-screen-keybrd.

Perhaps a later version of LNO, than this 12.Jan.2002,
is easier?

Thanks,

== Chris Glur.

PS. writing this with ETHO was easy [hence the size];
but get it mailed via the abusive Wintel monopoly
constraints is Not easy.