Doug:

   even Oberon-1 would be progress over hand-made assignments to procedure 
variables.

Here is another interesting fact. The Linux kernel memory management 
is using untyped 32-bit integers, what is as if you you were always using 
SYSTEM in all code, both high and low-level. It is very interesting, 
because C would allow some type checking if those guys defined types, 
what they could have done but did not bother to do. In the book on Linux 
device drivers the authors say "we have no such luck" to describe the 
situation of all addresses being typeless (on page 415). These exact 
words. Now consider the fact that memory management is the centerpiece of 
any operating system. And they are talking of "luck"? What if Linux is 
used to steer aircraft? Are they going to count on "luck" in such a case?

I have not invented these facts. I took them from "Linux Device Drivers, 
3rd Edition" by Corbet et al. I am now studying this book because I have 
to develop an interrupt handler for my hardware, which is running Linux.

Not to even mention the fact that there is no garbage collector. 
The memory is allocated/deallocated by hand. And indeed, some applications 
leak memory, what I am experiencing myself. I have not written these 
applications. So it is not my fault.

Now, how to reconcile all this with the much-advertised robustness? The 
answer: testing, testing, and testing by thousands of volunteers 
(victims?) like myself. If you do not know how to design good software, 
hire a few thousand volunteers and they will do the job which the compiler 
should have done.

Cheers,
W

On Mon, 20 Dec 2010, Douglas G. Danforth wrote:

> W,
> Doesn't that give inspiration to some young active
> Oberon enthusiast to dig deep into that code and
> replace the kernel with true Oberon-2?
> 
> Just a pipe dream.
> 
> -Doug Danforth
> 
> 
> On 12/20/2010 8:51 AM, Wojtek Skulski wrote:
>       Robert:
>
>       Seasons Greeting to you as well!
>
>       FYI, I am now doing some Linux development. To this end I am reading the book on Linux kenel-mode
>       drivers. There is a fair amount of material there on Linux kernel. I am amazed to read that the
>       newest-greatest Linux technology is called "modules". These are loaded/unloaded by the kernel. They
>       have init and close sections, as well as methods. Sounds familiar?
>
>       On closer reading it is all Oberon-1. The methods are installed in procedure variables. There is no
>       type safety anywhere. If you install a wrong pointer then kaboom. The compiler can barely help.
>       Ditto with memory management. There are all kinds of addresses (virtual, kernel, user, etc), but
>       all are being cast to "unsigned long". It is up to you to know which address is which. If you get
>       lost in a maze of rules (which are changing from release to release) then your program will trap on
>       wrong address at run time. If it happens in the kernel-mode code, then you computer will crash and
>       you can then analyze register dumps.
>
>       So deep inside the newest-greatest Linux kernel 2.6.xxx is in fact an old original Oberon System
>       with Oberon-1 run-time methods, but without Oberon type safety. All is arranged on top of old
>       original C. The entire module structure is implemented by hand with a set of rules and preprocessor
>       macros.
>
>       Amazing, how the newest-greatest and most advertised turns out to be old Wirth/Gutknecht design.
>       Without proper attribution of course.
>
>       Greetings to all!
>
>       Wojtek
> 
> 
>
>       On Sun, 19 Dec 2010, Robert wrote:
>
>                          As it turns out, the "Disambiguated glommable expression
>                         templates" did
>
>             not end in 1997. A more recent version is available:
>             http://adtmag.com/articles/2000/04/25/disambiguated-glommable-expression-templates-reintroduced.aspx
> 
> 
>
>             Wojtek,
>
>             I shall keep this reference for some light reading next April 1st.
> 
> 
>
>             Seasons Greetings
>
>             Regards
>
>             Robert
> 
> 
> 
>
>       ----
>       To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV@LISTS.OBERON.CH
> 
> 
> ---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV@LISTS.OBERON.CH
> 
> 
>

----
To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV@LISTS.OBERON.lume 1