[Oberon] Re: n-o: timer-reset chit-chat

[easlab at absamail.co.za]

> cg>   1. as I have repeatedly reported: after an abort eg. power down
>    to modem during ppp connected, the ser-control to modem
>    fails on further dial attempts.
> 
> Peter E.  wrote:
> I've probably observed that more than once.
> Certainly Oberon PPP needs work.
> 
I wish you'd mentioned that before.
When every one else remains silent on a reported problem, one
must consider seriously that it is one's 'own' unique problem;
perhaps even one's hardware.

Have you ever tried Ctrl/Break; immediatly after
   NetSystem.SetUser pap:<id>:<paswrd>@PPP ~
or what ever the [latest] syntax is.
This always works for me, even if I have to do it 10 times before
the 'lock-up releases'.  I (have to) quickly move my right hand
from the mouse activated NetSystem.SetUser <arg> to the
break key, apparrently because I found-out/thought that the
'break' must be caused during the actions of NetSystem.SetUser ?!
This is all in the realm of speculation/black-magic.  
That's why confirmation from others is valuable.

I usually have 10 days of frames pending attention, so it's very
inconvenient to re-boot.
BTW, has the 'newer' version fixed the problem that if you
 Backup.Directory a non-perfect diskette, it Traps and you 
can't use Backup.*  without re-booting?   Most annoying !

> Previously you mentioned the difficulty in 
> comprehending the PPP sources and in tracing
> execution.  A "small" project, which would 
> really help, is to write an EBNF representation 
> of the protocols.  It is mentioned in 
> http://carnot.pathology.ubc.ca/PPPnotes. 
> My current effort is in setting up PPP on a 
> Linux system so that I have something to test 
> Oberon PPP against.
> 
OK, but right now I can't allocate active thinking to ppp.
I read news:comp.protocols.ppp because it has several knowledgable
contributors, including the man from sun who 'wrote the book'.

> cg> ... ISP has allocated me a login-name with
>   an embedded "@" char ...
> 
> That might be fixed.  Have a look at Edgar's 
> latest release.  
> 
Well, I'm afraid to change over (or even try - loose time) to
a latest release; I need a reliable system for use every day.

> cg> The lack of these types of simple 'Howtos' ...
> 
> Doesn't the Web based documentation cover that 
> requirement?  Thanks to André Fischer and others, 
> there are many well written pages.  Mention a 
> few of the most bothersome deficiencies and 
> someone might be able to address them.

My mistake: Howtos exist. 'Tips' re. trivial matters, like how to 
swap between sending your correct return-adr for email which 
needs it and sending news-articles where you want to hide it.
Such problems arise unexpectedly and with urgency, and can't
wait for a well planned Howto.

> cg> ... n-o usage will never grow.
> 
> If Oberon/AOS do remain in a niche, is it so bad?

Well it's all based on the economics of colaborative software.
If there are 10 times more contributors, the value to each, is
greately increased.  Efficiency in quantity.  Same principle
as the economics of a network - colaborators ARE a network.

> s>  use of it as a practical tool is, at best, 
> a pipedream.

Not true ! I've been using it for years as my main OS
(95% of the time) for text based stuff: inet-fetch, sort and
store, search and especially for extracting meaning from text
via the quick colour-fonts change.

> Oberon works very well in tandem with another 
> system.  At home I routinely edit files with 
> ET and RX in Oberon and send them to an old
> Mac IIfx for processing.  The file transfer 
> happens in a second or two.  I can continue  
> editing in Oberon while OzTeX on the Mac formats. 
> ET and RX are much more efficient than Alpha 
> on the Mac.
> 
> At work Oberon is beside Debian Linux.  
> Oberon is much better than vi for reading manual
> pages and Oberon is better than Lynx for most 
> Web browsing.  Conversely, Linux provides a pdf 
> viewer.

Yes, all the more reason why the machine should not need to
reboot for 'failing'  Backup.* operations, to move files to other
OSs.  Altho` linux also won't recover from failed operations to
fd0. If it was inevitably caused by the PC-BIOS calls, then
why is linux  mdir a: less problematic ?

== Chris Glur.