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.
