From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b95a522100671708 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!feed.cgocable.net!read1.cgocable.net.POSTED!53ab2750!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: For the AdaOS folks References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <1PTAd.1218$0y4.421@read1.cgocable.net> Date: Thu, 30 Dec 2004 08:58:23 -0500 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1104415037 24.150.168.167 (Thu, 30 Dec 2004 08:57:17 EST) NNTP-Posting-Date: Thu, 30 Dec 2004 08:57:17 EST Organization: Cogeco Cable Xref: g2news1.google.com comp.lang.ada:7322 Date: 2004-12-30T08:58:23-05:00 List-Id: Nick Roberts wrote: > Wes Groleau wrote: >>or anyone else with similar ambitions. >> >>Read "Kill the operating System" page 32 of September 2003 Technology >>Review >> >>Not a prescription, but something to think about. ... > One of the reasons, perhaps the biggest reason, why I decided on using a > microkernel was for security. I read the 'orange book' (the TCSEC) and > others which described how the world of computer science (especially within > governemntal and military sectors in the USA and the UK) foresaw the > evolution of computer technology. Remember that this is early 1990s, before > the domination of Microsoft. The overwhelming consensus was on a microkernel > based design, because this allowed the 'trusted computing base' (TCB) -- the > part of the overall system's software that had to be trusted not to subvert > security -- to be minimised. Its too bad that the L4 microkernel is not very secure yet. Apparently, they are trying to fix that in L4ng, but it appears that they got so focused on efficiency that they didn't get security. The efficiency of L4 otherwise makes it very attractive. The following link describes some of the things that they are looking at in L4ng : http://i30www.ira.uka.de/teaching/coursedocuments/105/l4ng-apr28.pdf It still seems unnecessarily more complex than the Mach port approach. And of course, and Ada microkernel would be better by definition ;-) I also don't like the way that L4 ties communications to threads. The Mach approach is much easier to work with, with its single receiver and multiple send and send-once rights. > The consensus was also on a 'fully distributed' system -- a network of > computers (always termed 'workstations' regardless of whether they had > screens, keyboards, etc.) that operated exactly like a single big computer, > from the point of view of normal users -- and so AdaOS is a > microkernel-based, fully distributed design. I've been mulling this over myself. Unfortunately, as soon as you say that all computers must work together, you introduce all sorts of problems and overheads. Endianness and page size are two issues, between two computers. I have been wondering if this shouldn't be tiered: 1. Clustered systems with all the same endianness and page size 2. "Networked Clusters" of #1 groupings In this way, it would be efficiently possible to cluster similar equipment, and yet still provide "one-ness" in the different computer cases, with the necessary overhead and complexity. This would also permit a tiered development approach. > However, I intend to design the microkernel so that it compromises on > minimality (unlike some other microkernel designs) Yes. Mach is too fat. They shouldn't have included device drivers for example. > to achieve reasonable > efficiency (whilst removing much of unnecessary detritus that bogged down > experimental microkernels), and I intend to ensure that administrative > division of the network is fully supported, as well as network partioning > robustness (if some workstations go down, the rest still work). I wonder if networking really belongs in the microkernel. This is necessary for example if like Mach, you say that ports can speak to other Mach machines on the network/cluster. However, you might want to take the tact that networking is done outside of the microkernel. This way, in situations where you don't want networking (embedded systems), it need not be there. Leave the networking up to the user of the microkernel. This would be my preference anyway. It also leaves it up to the OS designer what type of networking will be supported. Reading below, perhaps you are speaking collectively for AdaOS, for microkernel and OS. > For a very long time, IBM mainframes have supported (very efficient) > programmatic access to a system database, as an alternative to file-based > data storage. I would like provide both forms of storage in AdaOS, in > addition to 'persistent objects' in some form. I always get scoffed at for suggesting this, and I have no love for M$, but the one idea they have had, which is useful, is the registry. I think there are better ways of doing this however, but the general idea is good. You can see that GNOME and Mozilla both use it, so it obviously satisfies a need. I think any OS today that is going to support point and click administration, is going to need some sort of a registry, even if it is just layering it on a RieserFS. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg