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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3cd3b8571c28b75f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-01 14:22:36 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!guardian.oit.duke.edu!newsfeed.mathworks.com!wn13feed!wn11feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc04.POSTED!not-for-mail Message-ID: <3F53B88E.7040405@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: A Customer's Request For Open Source Software References: <3F44BC65.4020203@noplace.com><20030822005323.2ff66948.david@realityrift.com> <3F4828D9.8050700@attbi.com> <3F4EA616.30607@attbi.com> <3F512BD1.8010402@attbi.com> <3F52AA5F.8080607@attbi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: sccrnsc04 1062451355 24.34.139.183 (Mon, 01 Sep 2003 21:22:35 GMT) NNTP-Posting-Date: Mon, 01 Sep 2003 21:22:35 GMT Organization: Comcast Online Date: Mon, 01 Sep 2003 21:22:35 GMT Xref: archiver1.google.com comp.lang.ada:42041 Date: 2003-09-01T21:22:35+00:00 List-Id: Alexander Kopilovitch wrote: > Well, this is understandable. But I guess that there may be non-conventional > ways to get something like that. One way, which I imagine, largely avoids that > "prohibitive cost" (although it still may be considered as a sort of a plot > for an episode of the serial "Wild Investor" -:) : take existing open source > OS - FreeBSD is, perhaps, the best candidate - and start to replace its layers > from the ground, that is, from the kernel, following the Multics design, and > making necessary bridges (between lower Multics-layers and upper FreeBSD > layers) at each stage, thus maintaining functionality but not too worrying > about effectiveness. Non-starter, really. That would be like translating a novel from Russian to English a word at a time. You would end up with a book all in English, but full of Russian idioms and with no English idioms or common phrases. Actually, make that Klingon and English, or something even wierder. Klingon to Chinese? There are hundreds, make that thousands of assumptions in a disk-based OS that are absent or different in Multics. For example on Multics there is a tool called the binder that can be used to bundle up snapshots of a group of programs. These snapshots are not the programs, but they are the closest Multics has to the concept of a computer program. In the Multics world, a program is often no better defined than "this entry point in this segment, called with these parameters." Of course, there is on-line documentation FOR THAT SEGMENT, that explains all that. (And yes, one of the things that you pass to the binder is a list of the entry points that you want to be visible.) Similarly, connecting to a Multics site is a meaningful concept. Booting is something that hardware does after a power failure. You can have a Multics site with several CPUs--I think System M in Phoenix had five--and we can discuss things in terms of symmetric multiprocessing. But that sort of misses the point. The Multics site can add CPUs, drop CPUs, upgrade CPUs, etc., and all that is going on from the Multics viewpoint is adding and removing resources. Same for memory, disk drives, tape drives, and any other resources. (Hmmm. Translation, in the Multics world critical is not a word you assoicate with resources.) > Well, I have vague only feeling about current state of RDBMSs, and it is not > clear for me whether people in that area will see that as major improvement > (for what I constantly hear, their main practical problem regarding efficiency > is just right index structure). But I have a friend who is an active professional > in this area, both at academic side and at practical side, and I'm going to ask > for his opinion on this matter (but it may take about 2 weeks, because just > now he is busy at a DBMS conference in Germany -;) ... if his opinion will be > positive then, perhaps, some of his Ph.D. students will become interested in > such a project -:) . As I said, most RDBMSs already have the ability to bypass the OS and access disk drives directly. This is going one step further, and "mapping" the disk drive into memory. With a memory-mapped drive on a virtual memory system, you can address the disk just like the memory was physically present in RAM. On Multics, a user process had 4096 segment descriptors available, each of which could map to about one Megabyte of RAM (actually 256k words of 36-bit memory). Some of these segments were common OS gate segments, some were applications in use by the user, some were what you would think of as open files, and some were user defined segments with entry points. (Remember, one segment could have several hundred different entry points--or more. About a dozen entry points was common.) -- Robert I. Eachus "As far as I'm concerned, war always means failure." -- Jacques Chirac, President of France "As far as France is concerned, you're right." -- Rush Limbaugh