[Oberon] Re. Install your own OS

[easlab at absamail.co.za]

--- easlab at absamail.co.za wrote:

-- snip --
> > When I ask myself why NO is so much better/simpler: 
> > it's because linux lacked the 'top level principle'
> > of  "keep it as simple as possible".
> 
John M. Drake wrote"
> One of the nice things about Oberon is that it
> compiles so fast that complicated "make files"
> (which exist to avoid unneccessary compilations)
> really aren't needed.  Even years ago on a 386
> I had a 1,000 line program that compiled in 
> seconds.  A similair C program under Linux
> took much longer (painfully slow).

Complexity [the lack of simplicity] is more than size,
it takes on a life of its own. It would still be OK if it
only took longer, but here's [only] one example:
MAKE's syntax "wants Char(tab)" so when the 
package [of files] fails to compile and [with great
difficulty] you compare the make-files with 'tested-good
ones', and you waste 2 days to find out that your editor 
is replacing the Char(tab) with n*Char(space) you
realise what a devil unjustified-complexity is.

> > Related to this, I'm amazed at MIT [perhaps the most
> > prestigious
> > (?sp=help Soren) tech-institute in the world]
> > anouncing its $100 
> > laptop for all the school-kids in China and the rest
> > of the 3rd world.
> > 
> > Absurdly they write about a 500Mb AMD & 1GB !
> > IMO the Indian simputer is more on target, being
> > ARM-based
> > [linux of course] the "user's " lack of mains power
> > is acknowledged.

> Curious as to what you dislike about the MIT
> specs.  Too much?  (I'm curious if 1 Gb is
> supposed to be RAM, flash, HD?)
 
For 3rd world, you have to start by assuming 
no mains power.  That's why ARM is potentially 
so important, and IMO the MIT team miss the point.

> Oh, that reminds me.  Some years ago Chuck
> Moore (inventor of the Forth programming
> language) worked with a company that devoped
> an inexpensive "information appliance"
> based on his chips.  One idea was to put
> the computer in the battery bay of cheap
> portable computers.
> 
> http://web.archive.org/web/19990125100356/http://www.itvc.com/
> 
> The price point was to be $100.00. 
> Unfortunately due to some bad management
> decisions the company went under.  But the
> technology was quite promising.

It's true that Forth only reached a small audience
and as memory and CPU cycles became cheaper
it became less relevant.

But the cost/penalty of complexity has/will not 
become cheaper and wattage-power is increasingly
important for mobility and 3rd-world village life.

> > I hope Oberon-S3's knowhow for ARM is not lost.
> > --------------------
> 
> Considering that there's an ARM backend for the
> BlueBottle Active Oberon compiler it seems ARM
> support is continuing.

I would be happier to hear a confirmation from a real 
live person who is actively using it ?
---------------

> Unfortunately maintenace is very uninspiring.
> 
> Here's a sample triviality:
>   SmartDir.Directory SYS:*pop*  \r2
> doesn't find that important file which I was working
> with,
> before I had to re-boot [not bad after 10 days]
> because of
> the dialer-ppp bug.  [ I guess an accumalation of
> 'unsafe
> traps' (perhaps messes the heap ?) ].

That reminds me.  Where exactly are you now on your
PPP bug?  I recall you saying that you had it fixed
on one machine (through a NetSystem patch) but 
didn't want to risk messing up your other machine
with a patch?  (Correct me if I'm wrong).  Anyway
I think the "permanent" solution would be to change
the PPP package to have an alternative to relying
on NetSystem for the user ID and password.  Then
you could just install the new version of PPP
on whatever machine you were using and not have
to worry about patching NetSystem.  I think that
would be a more stable solution.
 
The wrong design assumption of no "@" in username nor 
password needs to be fixed. A more subtle/interesting
matter is the V24 problem that dialing fails when the 
ppp-dialer aborted unexpectedly on the previous dial.
A similar 'lock-up' situation happens with the V24.Panel
and is [roughly] fixed by the single instruction: 
  V24.Stop(<port of modem>).

> >   SmartDir.Directory SYS:pop*  \r2
> > finds:
> > pop.absamail.co.za 
> > pop.absamail.co.za.Bak 
> > 
> > as does: System.Directory SYS:*pop*
> > 
> > So SmartDir.Mod needs some attention ?
> 
> Well, as I'm not an NO user I'm not familair
> with SmartDir.  What exactly does it do,
> and how is it different from System.Directory?

SmartDir.Directory came to me privately for testing.
It apparently didn't make-it into the standard package.
I use it several times a day.
Perhaps because I've got a "recentcy view" of ontology ?
Norton's commander & mc are for me also killer-aps,
and I always want to have one of the 'file-lists' arranged
in reverse 'age' sequence. 
Turbo Pascal's IDE also acknowledged this principle [has
any body formalised it yet ?] by arranging the file-set,
to pick from, as a stack. 
I raised this point previously and P. Muller suggested
using System.Directory with 'flags' plus the existing
sort facility, but unfortunately NO writes  'date' 
as: day.month.year, so its not ordered, as it would be
if it was: year.month.day .

If you're looking for some info, it's very likely that:
you saw and saved it within the last 3 days.
So if you know the approximate topic-clasification you 
can quickly find it. 2 clicks will show the list of recently
changed files of topic T, if each topic [one per partition]
has a 'partiton control file' thus: -----
!OFSTools.Mount  Legal  AosFS  IDE1#28  ~   25 Dec 2004
!OFSTools.Mount  Legal  AosFS IDE0#29  ~ May 05 Seagt80GB
OFSTools.Mount  Legal  AosFS IDE0#28~   26 Sept 05 Seagt40GB

! System.Directory  Legal:* 

! OFSTools.Unmount  Legal

!  SmartDir.Directory Legal:*\r 3   <-- execute to see recent files

! Legal:SearchTemplate
-------------------
And if the searched-for-file [you will recognise the name
when you see it] is from perhaps  2 or 3 weeks ago, you
can quickly edit "*\r 3"  to "*\r 23"....etc.

But there's  a problem to all this: any time you copy
all files to a new partition, for backup-cycling, all
files are new-dated, and the date order is lost !

BTW working with the new set of files is safer than 
assuming/hoping that the files were backed up.
Else it's like the spare-wheel on a vehicle which
is never tested/confirmed until it's needed, when
it may then fail ?

Which reveals another [unwritten IMO] principle
of NO: always provide confirmatory feedback to
the user for every operation.

== Chris Glur.