[Oberon] Improving Oberon-0

[cglur at onwe.co.za]

muller at inf.ethz.ch wrote:
> 
> > "Douglas G. Danforth" <danforth at greenwoodfarm.com> wrote:
> > > When trying to decide if one's machine is capable of running
> > > Native Oberon or Bluebottle such a Wizard written for MS Windows
> > > or Linux would seem appropriate.
> > 
> > I think time would be better spent improving the Oberon-0
> >  environment, especially diagnostic information when things
> > go wrong.  

Provided "environment" includes the humans and their organisational
 structure.

Douglas G. Danforth wrote:
> Yes, this certainly is needed.
> 
> > There is no guarantee that the environment
> > detected or presented by Linux or Windows is the same as
> > what would be seen when Oberon is booted.
> 
> I assumed that information concerning the hardware
> would be obtained identically whether run from the high level
> operating system or from the Oberon-0 boot.  That is, the
> high level extractor would simply wrap the low level
> extractor as an executeable.  I would not expect to make
> high level operating system calls to obtain the information.
> (But then there are interrupt issues and what handler
> is installed, so that conflicts between the extractor and
> the operating system become an issue.)
> 
> In general I am looking for a way to "hide information" as 
> much as possible from the user so that details such as
> 
> > ... switch back
> > and forth between 32-bit protected mode and 16-bit real mode
> > on-the-fly. ...
> 
> would not be seen by the casual user.  Yes, these details are 
> very necessary to provide the underpinnings and allow complete
> control over the hardware.
> 
> I see 4 levels of user
> (1) ETH: totally knowledgeable engineer, hardware & software
> (2) Developer: Desires to add drivers & software but doesn't
>     want to operate at level (1)
> (3) User: Cares nothing about level (1) or (2) but just wants
>     to install and run where "install" means plug & play.
> (4) Buyer: System already installed and user buys it (cares nothing
>     about levels (1-3).
> 
> Pieter's comments are directed somewhere between level (1) and
> level (2).  Again, they are very necessary.  I am just trying
> to provide a prospective where the goal is to move toward levels
> (3) and (4).
> 
> Now, where is my 386 assembler with the description of
> real and protected mode (I do have one!).

Their are serious omissions here.
Consider also horizontal (more than the listed vertical) divisions of
labour: skills for writing hardware drivers are very different from those
needed to write/debug the gadgets and screen lay out (current bug
waiting for attention).

Even within one 'branch'; fault detecting, debugging and fixing, 
testing, documentation; are different skills that can call on different
persons, provided the organisational structure exists.

The internet allows such organisational structures to exists.
The coordination from ETH is missing.

-- Chris Glur.

PS. My oft repeated suggestions solves the "Improving Oberon-0"
topic by releaving pressure from those working on "Improving 
Oberon-0", by allowing them to know that the 'machine setup
to fix other problems' is purring away in the background, with
minimal attention.    Instead of management by crisis.