Re: A Customer's Request For Open Source Software

["Robert I. Eachus" <rieachus@attbi.com>]

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