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{([at]})nowhere.xy>
>
> ---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy>
>
>
----
To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
Received on Tue Dec 21 2010 - 01:40:28 UTC