[Oberon] Re. Install your own OS

[John Drake]

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

> --- 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.

I think you missed my point.  The whole reason
there are makefiles is to avoid the (relatively)
slow complilation process.  But if it only takes
a matter of seconds to recompile everything
anyway, why bother with a makefile at all?
When I was once doing a similair project in
Oberon and C it took less time to recompile
one of the C files and relink than it took
to recompile all of the Oberon files.  
 
> > > 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.

Well I don't think the MIT computer is "strictly"
aimed at the 3rd world.  Also there more to power
consumption than just the CPU.  Anyway, they
could go for a Transmeta like chip if they want
Intel compatibility and better battery life.

 
> > 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.

Well this was more of a problem of poor marketting
than anything else.  For instance management
turned down an offer of actual SALES of the 
machine for someone who wanted to sell it as
an email terminal simply because they didn't
want the machine to be viewed as "only for email".
By contrast the BlackBerry device was initially
seen as "only for email" and now it's challenging
Palm in the handheld market.
 
> But the cost/penalty of complexity has/will not 
> become cheaper and wattage-power is increasingly
> important for mobility and 3rd-world village life.

True.

> > 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. 

Ummmm...yeah.  Heard that all before.  Suggested a
patch.  Others have suggested patches.  I recall
you actually applied a patch of your own right?  
The last thing I remember you saying is that you
have it working on one machine, but not on another,
and that you were wary of patching the other
machine because it was a different version of
NetSystem (or something to that effect).  Anyway
that's why I'm suggesting folding the change
into PPP instead of NetSystem so you can move
it from one version of NO to another.


> 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>).

Vaguely recall this being discussed before too.
The ppp.task wasn't getting stopped when the
program ended abormally right.

> > >   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.

Ah.  So it's alpha software.  Anyway, I'm not
sure from the example you gave what is wrong.

:  SmartDir.Directory SYS:pop*  \r2
: finds:
: pop.absamail.co.za 
: pop.absamail.co.za.Bak 

What were you expecting it to find?

> 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 .

I've got a lot of problems with the way Oberon
System 3 handles dates.  For instance it insists
on Monday being the first day of the week, whereas
in the U.S. that is Sunday.  Oberon V4's date
module is more flexible.  It's easy to change 
date formats for instance.  Unfortunately for
System 3 you can't fix the dates module easily
because it's imported by Strings which is imported
into the kernel.  That's a BAD design in my 
opinion.  String is a more basic type than date.  
So date-to-string, string-to-date converstion
should be handled in module Dates and NOT
module Strings.  

Ok.  Enough of my soapboxing.  There is a way
to change the Date output format in System 3,
it's just unecessarily tedious.  In "Oberon.Text"
there is an option "DateFormat= DD.MM.YYYY".
You can change this to "DateFormat = YYYY.MM.DD".
The problem with this is that now ALL of your
dates will be shown this way!  The Oberon V4
dates module takes the more sensible step
of taking a date format string for the date
to string conversion procedure.  
 
Regards,

John M. Drake


		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/