Re: A Customer's Request For Open Source Software

[aek@vib.usr.pu.ru (Alexander Kopilovitch)]

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