Path: utzoo!attcan!uunet!fernwood!decwrl!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!think!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: the Multics from the black lagoon :-)
Summary: Content based vs. addressing is different...
Message-ID: <1655@aber-cs.UUCP>
Date: 22 Feb 90 02:24:50 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 53

In article <766@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes:
  pcg@aber-cs.UUCP (Piercarlo Grandi) writes:
  
  >fundamental aspect of programming . . .
  >the difference between encoded (paper tape) and structural
  >(card deck) representations of data.  In encoded representations the
  >relationships among parts of composite data are encoded within the data, in
  >structural representations they are part of the data structure; in one case
  >you scan the data, in the other you navigate it.
  
  Consider a naming model, in which such distinctions are less than
  fundamental, are in fact are irrelevant.

But these are based essentially on identifying entities by content, which is
way above the OS architectural level we were discussing.

  For a specific example, consider the relational model.

Well, the relational model is structural to the nth power (even if
based on content location). It is the ultimate in 'card deck' style
programming. The fact that relationships among tables are implicit in
their contents (thos within a table of course use contiguity) simply
means that they are even more out of vand than 

  >UNIX tends to make life difficult for people doing
  >these things (major example being INGRES).
  
  As a user and programmer of INGRES, I find the facts otherwise.
  As the creator of INGRES, so does Stonebraker.

Stonebraker wails for pages and pages in his "retrospection" paper and
also in the "os support" one about (against) having to use pipes, not
having shared memory, and not having reliable locking.

The problem with Unix and the architectures it was designed for is that the
kernel is an "io multiplexor", but short of major surgery (adding new
modules, either properly or as a pseudo device driver) cannot provide the
*foundation* (hey! I am a minimalist -- I don't want kernels to provide
*services*) for such technology.

  Or perhaps you had in mind an operating system that has made
  INGRES easier to develop, use, or adapt?  Would you name it?

Well, my favourite example is RDMS (something quite comparable to Ingres)
under Multics. The authors did not have to fight tooth and nail against the
limitations of Unix for the PDP-11.

Unix V7 was a *very* well designed compromise, but very much constrained by
the target hardware.
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk