[Oberon] re: USB, bloat, LNO, SCSI/IDE & etc.

[easlab at absamail.co.za]

shark at gulfnet.sd64.bc.ca wrote:-
> This is a little disconnected but the topics 
> are too interesting to pass up.

All the topics are related by some higher/over-arching principles.


> jj> Someone should tackle a native port to the old 680x0 Macs ...
> 
> Nice.  Has any Oberon or Aos display driver 
> ever been written outside the ETH?

Do you mean "has any display-driver been written in the Oberon
language [I'm guessing that Aos has not yet reached outside 
the ETH], other than those written at ETH" ?
Well yes, since the Oberon language HAS somewhat been used 
outside of ETH -  what about [? what's it called = Blackbox ?].
And if you're thinking of porting from such source to ETH-oberon,
then porting from the bigger source-populations of Modula,
[turbo] Pascal and even C becomes viable. 

I don't think an automagic port is possible.
You always need human intervention.
You just get increasingly better tools to help.
Like we can get from NY to Tokyo much easier than our ancestors,
  but we still need to 'walk a bit'.
Similarly early A[rtificial] I[ntelligence] had unrealistic 'automagic'
expectations initially, but has settled into realistic tools [auto
 combined with human intervention] now, like man-plus-google.

Trying to install the newer [12 Jan 2002] version of LNO is an example,
you have to struggle over several hurdles to get to a useable level.
Which is one very good reason NOT to update.
Every time you update, you need to relearn/reset your personal
'settings'.  Moving house/spouse is traumatic.
-----------------

Internet connectivety MUST be seen as an important part of
'computing'.
Increasingly ETH-oberon-family is falling behind in inet capabilities.
IMO N-O still has the best-ever text handling capabilities.
Since Unix/Linux is THE standard for inet communications, LNO
seems to offer the best possibility of keeping N-O's superior text 
handling of the Linux-inet-fetched-text.

As noted above, automagic porting/installing is unrealistic
without a long testing cycle, with many users [beta testers] to
remove most of the unanticipated problems from the combination
of various hardware...etc.

How would the developer imagine the problems introduced by the 
fact that Ver. 2002 is drastically different re. installation compared
to Ver. 1999.  Only an outsider who's fallen in the hole, can contribute
a valuable note, to avoid others falling in the same hole.

The repository of usefull knowledge:
Desktops.OpenDoc"http://www.edgar-schwarz.de/cgi-bin/moin/\
LinAosDevEnv"  shows Error 404 today.

To the existing [fetched previously] info:

> Linux Native Oberon
> ....There are some pitfalls on
>    installing.  Be  careful  that you start it from a Linux console (E.g.
>    Ctrl-Alt-F1).  It uses the framebuffer, so /dev/fbdev should be there.
>    If   you   must   create  a  new  file  to  install  NO  in  use  e.g.
>    "Linux.[23]MakeDisk  oberon.dsk  64  ~ Linux.[24]OpenDisk oberon.dsk ~
>    Partitions.Format  oberon.dsk#0  AosFS  0~  ".  In  case of permission
>    problems  (See  oberon.log)  either use root or even better adjust the
>    permissions.  Also "xhost localhost or xhost +" can help if oberon.log
>    shows any problems.

 one could add the following fuzzy-knowledge:
  Apparently if a suitable X-configuration is not avilable, a framebuffer 
  can be used [ see the 2 Display*.Obj].  Whereas normally VT usage
  shows a 80x25 display, at the bootprompt, entering linux 'vga=ask' 
  will prompt you for different settings .....
  Apparently 'ls /dev/fb*' will show if framebuffer facilities exist,
  although it's difficult to know how/if the actual  existence
  of framebuffer driver code relates to the existence of
  /dev/fb* entries.
  In my case the existence of such /dev/fb*  [in one of my linux
  installations] urged me to persevere.   The LNO facilities additional 
  to the 1999 version look very promising - so far towards the 
  intallation. 

Q - the "*": an essential char for linux & N-O; is only available
  as a single-finger-fetch, from the num-keys.  Can the disabling
  of the num-keys be fixed ?
-----------------

My main point is that we need a knowledge repository to refine 
the LNO installation information, to allow more users to have
linux inet facilities, for users who want to have the text handling 
capabilities of N-O/LNO.

== Chris Glur.