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-02 09:16:32 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: aek@vib.usr.pu.ru (Alexander Kopilovitch) Newsgroups: comp.lang.ada Subject: Re: A Customer's Request For Open Source Software Date: 2 Sep 2003 09:16:30 -0700 Organization: http://groups.google.com/ Message-ID: 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> <3F53B88E.7040405@attbi.com> NNTP-Posting-Host: 62.152.65.168 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1062519392 13075 127.0.0.1 (2 Sep 2003 16:16:32 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 2 Sep 2003 16:16:32 GMT Xref: archiver1.google.com comp.lang.ada:42067 Date: 2003-09-02T16:16:32+00:00 List-Id: Robert I. Eachus wrote: > > 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. Perhaps. Although I don't see serious reasons for that other than insufficient information about real Multics (including its usage). > 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. Well, let's compare it with translation, but why such a ridiculous way - word by word? You said Russian novel to English - good, let it be (for example) L.Tolstoy (I think that Tolstoy and Dostoevsky are most known Russian writers in USA, and programming still didn't reach the Dostoevsky's level of tense and struggling -:). So, as we know that Tolstoy's writings consist of 3 major components - static descriptions of natural environment, long moral speeches, static and dynamic description of characters - and occasional (rare) short sayings of exceptional strength or contents, so we can deal with all that by corresponding stages. First, we'll translate into English all descriptions of natural environment. At the second stage we'll translate moral speeches. Then, at the third stage we'll translate the rest - real contents, character by character. And during that third stage we'll care about those singled sayings. > Actually, make that Klingon and English, or something > even wierder. Klingon to Chinese? I was very surprised about that Klingon - I never saw this name. So I was forced to search via Google for it, and yes, I found that this is the language from Star Trek product. Well, I understand that perhaps it is impossible to avoid Star Trek in USA - just as it was impossible to avoid Communist's favorite movies, songs and slogans in USSR. By the way, here in Russia we have our own alien language - from the movie "Kin-za-dza" (produced about 1990). It is very simple language - less that 10 words for all occasions. Two main words are like "qoo" (positive word, double and triple "qoo" along with touching your cheeks with your fingers are used for expression of admiration, subordination, etc.) and like "que" (negative word). Well, I recommend you that good movie, if you want to understand the mood in the late Soviet Union -:) . > There are hundreds, make that thousands of assumptions in a disk-based > OS that are absent or different in Multics. Yes, surely. But I do not think that one must be too serious about all those assumptions. Some of them are significant and should be satisfied or simulated one way or another; but most of them really need not be satisfied - they may be substituted by other assumptions without much harm. (I'm not saying that this is simple or smooth job -;). Note, that in the intermediate stages (being partially Multics and partially FreeBSD) the system need not have production strength. > 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.) I don't see why this may appear serious obstacle. I can't imagine that it may be too hard to emulate conventional process environment in any reasonable OS. Just because that conventional process corresponds to important and natural needs of significant share of users - so, if OS can't provide that opportunity then it is fatally flawed as general-purpose OS, and given the fame of Multics it seems improbable. > 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.) I don't see how these features of Multics may create any obstacle for suggested scenario - they all are additional features (relative to conventional OS), and in the scenario Multics grows from the lower layers. > 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. What I still can't get clear is why this approach did not (apparently) already succeeded? Not all applications need very large databases - 1Gb is enough for many, and memory is cheap - so, why we don't see such products? By the way, I'm pretty sure that I saw something somehow similar to that - OODBMS in Ada95, which was based on storage pools - in public domain, in 1995 or 1996 or 1997. I remember that I downloaded that thing, it seemed interesting and I read and even printed it. Now I tried to find it again, but so far failed - both on my disks and in the Net (unfortunately I remember neither the author's name nor exact title). There is still a chance that I'll find it in my archives on CDs. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia