[BLACKBOX] Seasoned Linux. Was: Seasons Greetings from Linuxland

From: [at]} <Rex>
Date: Tue, 4 Jan 2011 17:38:57 -0600

----boundary-LibPST-iamunique-1340895924_-_-
Content-type: text/plain

At 10:51 AM 12/20/2010, Wojtek Skulski wrote:
>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.

Douglas G. Danforth wrote:
>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?

Wojtek Skulski wrote:
>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.


        I've been wondering when this discussion would take place. My impression is that the kernel is probably pretty good, through a combination of careful attention and brute force. Many of the applications, on the other hand, tend to crash.

        Is there any logical possibility of automatically converting C code, and possibly even the GNU/Linux base, to CP or Oberon-2? The cost of developing widely used operating system seems to be outrageous because the world seems to require overly numerous and complicated capabilities. On the other hand, I wonder if the cost of automated porting, and thereby improving the code, would be reasonable, or at least more reasonable.

        We know that Oberon code can be translated into C. The reverse is more difficult, to be sure, but is it not possible? There are some obvious technical obstacles, but could the required typing, etc. be supplied by an automated procedure? Surely it's theoretically possible because the required information is present. Of course, any programming errors that are discovered during compilation might have to be fixed by hand. Is this worth consideration or is it completely foolish?

Rex Couture

----
To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy----boundary-LibPST-iamunique-1340895924_-_-
Content-type: application/rtf
Content-transfer-encoding: base64
Content-Disposition: attachment; filename="rtf-body.rtf"
e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250dGJsDQp7XGYwXGZz
d2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmllciBOZXc7fQ0Ke1xmMlxmbmlsXGZjaGFy
c2V0MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5ldzt9fQ0Ke1xj
b2xvcnRibFxyZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdWMxXHBh
cmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwIEF0IDEwOjUxIEFNIDEyLzIwLzIwMTAsIFdvanRl
ayBTa3Vsc2tpIHdyb3RlOlxwYXINCj5PbiBjbG9zZXIgcmVhZGluZyBpdCBpcyBhbGwgT2Jlcm9u
LTEuIFRoZSBtZXRob2RzIGFyZSBpbnN0YWxsZWQgaW4gcHJvY2VkdXJlIHZhcmlhYmxlcy4gVGhl
cmUgaXMgbm8gdHlwZSBzYWZldHkgYW55d2hlcmUuIElmIHlvdSBpbnN0YWxsIGEgd3JvbmcgcG9p
bnRlciB0aGVuIGthYm9vbS4gVGhlIGNvbXBpbGVyIGNhbiBiYXJlbHkgaGVscC4gRGl0dG8gd2l0
aCBtZW1vcnkgbWFuYWdlbWVudC4gVGhlcmUgYXJlIGFsbCBraW5kcyBvZiBhZGRyZXNzZXMgKHZp
cnR1YWwsIGtlcm5lbCwgdXNlciwgZXRjKSwgYnV0IGFsbCBhcmUgYmVpbmcgY2FzdCB0byAidW5z
aWduZWQgbG9uZyIuIEl0IGlzIHVwIHRvIHlvdSB0byBrbm93IHdoaWNoIGFkZHJlc3MgaXMgd2hp
Y2guIElmIHlvdSBnZXQgbG9zdCBpbiBhIG1hemUgb2YgcnVsZXMgKHdoaWNoIGFyZSBjaGFuZ2lu
ZyBmcm9tIHJlbGVhc2UgdG8gcmVsZWFzZSkgdGhlbiB5b3VyIHByb2dyYW0gd2lsbCB0cmFwIG9u
IHdyb25nIGFkZHJlc3MgYXQgcnVuIHRpbWUuIElmIGl0IGhhcHBlbnMgaW4gdGhlIGtlcm5lbC1t
b2RlIGNvZGUsIHRoZW4geW91IGNvbXB1dGVyIHdpbGwgY3Jhc2ggYW5kIHlvdSBjYW4gdGhlbiBh
bmFseXplIHJlZ2lzdGVyIGR1bXBzLlxwYXINCj5ccGFyDQo+U28gZGVlcCBpbnNpZGUgdGhlIG5l
d2VzdC1ncmVhdGVzdCBMaW51eCBrZXJuZWwgMi42Lnh4eCBpcyBpbiBmYWN0IGFuIG9sZCBvcmln
aW5hbCBPYmVyb24gU3lzdGVtIHdpdGggT2Jlcm9uLTEgcnVuLXRpbWUgbWV0aG9kcywgYnV0IHdp
dGhvdXQgT2Jlcm9uIHR5cGUgc2FmZXR5LiBBbGwgaXMgYXJyYW5nZWQgb24gdG9wIG9mIG9sZCBv
cmlnaW5hbCBDLiBUaGUgZW50aXJlIG1vZHVsZSBzdHJ1Y3R1cmUgaXMgaW1wbGVtZW50ZWQgYnkg
aGFuZCB3aXRoIGEgc2V0IG9mIHJ1bGVzIGFuZCBwcmVwcm9jZXNzb3IgbWFjcm9zLlxwYXINClxw
YXINCkRvdWdsYXMgRy4gRGFuZm9ydGggd3JvdGU6XHBhcg0KPkRvZXNuJ3QgdGhhdCBnaXZlIGlu
c3BpcmF0aW9uIHRvIHNvbWUgeW91bmcgYWN0aXZlXHBhcg0KPk9iZXJvbiBlbnRodXNpYXN0IHRv
IGRpZyBkZWVwIGludG8gdGhhdCBjb2RlIGFuZFxwYXINCj5yZXBsYWNlIHRoZSBrZXJuZWwgd2l0
aCB0cnVlIE9iZXJvbi0yP1xwYXINClxwYXINCldvanRlayBTa3Vsc2tpIHdyb3RlOlxwYXINCj5l
dmVuIE9iZXJvbi0xIHdvdWxkIGJlIHByb2dyZXNzIG92ZXIgaGFuZC1tYWRlIGFzc2lnbm1lbnRz
IHRvIHByb2NlZHVyZSB2YXJpYWJsZXMuXHBhcg0KXHBhcg0KPkhlcmUgaXMgYW5vdGhlciBpbnRl
cmVzdGluZyBmYWN0LiBUaGUgTGludXgga2VybmVsIG1lbW9yeSBtYW5hZ2VtZW50IGlzIHVzaW5n
IHVudHlwZWQgMzItYml0IGludGVnZXJzLCA+d2hhdCBpcyBhcyBpZiB5b3UgeW91IHdlcmUgYWx3
YXlzIHVzaW5nIFNZU1RFTSBpbiBhbGwgY29kZSwgYm90aCBoaWdoIGFuZCBsb3ctbGV2ZWwuIEl0
IGlzIHZlcnkgaW50ZXJlc3RpbmcsID5iZWNhdXNlIEMgd291bGQgYWxsb3cgc29tZSB0eXBlIGNo
ZWNraW5nIGlmIHRob3NlIGd1eXMgZGVmaW5lZCB0eXBlcywgd2hhdCB0aGV5IGNvdWxkIGhhdmUg
ZG9uZSBidXQgPmRpZCBub3QgYm90aGVyIHRvIGRvLlxwYXINClxwYXINClxwYXINCiAgICAgICAg
SSd2ZSBiZWVuIHdvbmRlcmluZyB3aGVuIHRoaXMgZGlzY3Vzc2lvbiB3b3VsZCB0YWtlIHBsYWNl
LiAgTXkgaW1wcmVzc2lvbiBpcyB0aGF0IHRoZSBrZXJuZWwgaXMgcHJvYmFibHkgcHJldHR5IGdv
b2QsIHRocm91Z2ggYSBjb21iaW5hdGlvbiBvZiBjYXJlZnVsIGF0dGVudGlvbiBhbmQgYnJ1dGUg
Zm9yY2UuICBNYW55IG9mIHRoZSBhcHBsaWNhdGlvbnMsIG9uIHRoZSBvdGhlciBoYW5kLCB0ZW5k
IHRvIGNyYXNoLlxwYXINClxwYXINCiAgICAgICAgSXMgdGhlcmUgYW55IGxvZ2ljYWwgcG9zc2li
aWxpdHkgb2YgYXV0b21hdGljYWxseSBjb252ZXJ0aW5nIEMgY29kZSwgYW5kIHBvc3NpYmx5IGV2
ZW4gdGhlIEdOVS9MaW51eCBiYXNlLCB0byBDUCBvciBPYmVyb24tMj8gIFRoZSBjb3N0IG9mIGRl
dmVsb3Bpbmcgd2lkZWx5IHVzZWQgb3BlcmF0aW5nIHN5c3RlbSBzZWVtcyB0byBiZSBvdXRyYWdl
b3VzIGJlY2F1c2UgdGhlIHdvcmxkIHNlZW1zIHRvIHJlcXVpcmUgb3Zlcmx5IG51bWVyb3VzIGFu
ZCBjb21wbGljYXRlZCBjYXBhYmlsaXRpZXMuICBPbiB0aGUgb3RoZXIgaGFuZCwgSSB3b25kZXIg
aWYgdGhlIGNvc3Qgb2YgYXV0b21hdGVkIHBvcnRpbmcsIGFuZCB0aGVyZWJ5IGltcHJvdmluZyB0
aGUgY29kZSwgd291bGQgYmUgcmVhc29uYWJsZSwgb3IgYXQgbGVhc3QgbW9yZSByZWFzb25hYmxl
LlxwYXINClxwYXINCiAgICAgICAgV2Uga25vdyB0aGF0IE9iZXJvbiBjb2RlIGNhbiBiZSB0cmFu
c2xhdGVkIGludG8gQy4gIFRoZSByZXZlcnNlIGlzIG1vcmUgZGlmZmljdWx0LCB0byBiZSBzdXJl
LCBidXQgaXMgaXQgbm90IHBvc3NpYmxlPyAgVGhlcmUgYXJlIHNvbWUgb2J2aW91cyB0ZWNobmlj
YWwgb2JzdGFjbGVzLCBidXQgY291bGQgdGhlIHJlcXVpcmVkIHR5cGluZywgZXRjLiBiZSBzdXBw
bGllZCBieSBhbiBhdXRvbWF0ZWQgcHJvY2VkdXJlPyAgU3VyZWx5IGl0J3MgdGhlb3JldGljYWxs
eSBwb3NzaWJsZSBiZWNhdXNlIHRoZSByZXF1aXJlZCBpbmZvcm1hdGlvbiBpcyBwcmVzZW50LiAg
T2YgY291cnNlLCBhbnkgcHJvZ3JhbW1pbmcgZXJyb3JzIHRoYXQgYXJlIGRpc2NvdmVyZWQgZHVy
aW5nIGNvbXBpbGF0aW9uIG1pZ2h0IGhhdmUgdG8gYmUgZml4ZWQgYnkgaGFuZC4gIElzIHRoaXMg
d29ydGggY29uc2lkZXJhdGlvbiBvciBpcyBpdCBjb21wbGV0ZWx5IGZvb2xpc2g/XHBhcg0KXHBh
cg0KUmV4IENvdXR1cmUgXHBhcg0KXHBhcg0KXHBhcg0KLS0tLVxwYXINClRvIHVuc3Vic2NyaWJl
LCBzZW5kIGEgbWVzc2FnZSB3aXRoIGJvZHkgIlNJR05PRkYgQkxBQ0tCT1giIHRvIExJU1RTRVJW
QExJU1RTLk9CRVJPTi5DSH19ADYAAAA=
----boundary-LibPST-iamunique-1340895924_-_---

Received on Wed Jan 05 2011 - 00:38:57 UTC