Re: A Customer's Request For Open Source Software

[Christopher Browne <cbbrowne@acm.org>]

The world rejoiced as "Robert I. Eachus" <rieachus@attbi.com> wrote:
> 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.)

Right, that sure was one of the bigger differences with Multics.

That means that a recreations would need to have a fair bit of code to
support this.

A start might be to look into RVM, the "recoverable virtual memory"
system created for the Coda distributed filesystem.  That is a system
that implements something strongly resembling Multics segments, which
runs on all sorts of systems.

Instead of giving up because it's necessary to implement _everything_,
from hardware on up, in order to have a viable system, it might be an
idea to start by hosting "PseudoMultics" atop one of the Unixes,
running it inside user space, with a view to modifying the kernel
eventually to support things that vitally need to be in the kernel.

> 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.)

That can only conceivably be supported on hardware that conciously
supports adding and dropping CPUs while the system is "hot."  You're
lucky, these days, to have a RAID controller that lets you hot-swap
disk drives; hot-swapping processors tends to indicate that you have
multiplied the cost of the system up to a new level.

Vis-a-vis disk, it's quite common for the support for that to mostly
sit at the hardware level, where a lot of change can take place with
the OS being oblivious to it.  (That's one of the _nice_ things about
FibreChannel arrays...)

But mandating an OS design that mandates this
"many-times-more-expensive" sort of hardware in days when
over-the-counter hardware is so cheap and available seems almost as
limiting as the lack of an "adding CPUs" feature.

I think it would be a mistake, today, to assume hot-swappable CPUs as
a basic function of the hardware.  It has proven a lot more economical
to put additional rackmounted computers onto a rack, and separate the
functions across multiple buses.

Futurists keep imagining that we are right around the corner from the
situation where it will make sense to buy computers that have huge
arrays of CPUs; while Apple may be very proud of their dual-PPC "G5"
systems, prices of multi-CPU "backplanes" remain stunningly higher
than those for single-CPU hardware, and there doesn't seem to be good
reason for that to change soon.

> As I said, most RDBMSs already have the ability to bypass the OS and
> access disk drives directly.

That's news; I wasn't aware that there were any left since Digital
sold RDB to Oracle.

There are some that support "raw partitions," but this doesn't involve
"bypassing the OS;" they merely bypass filesystem support.
-- 
(reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/linuxxian.html
"The only constructive theory connecting neuroscience and psychology
will arise from the study of software." 
-- Alan Perlis
[To the endless aggravation of both disciplines.  Ed.]