🚀 go-pugleaf

I must be missing something.  Barns wishes for "an n-bit
number which is absolute for the whole workstation".  Isn't
a reasonable-size conventional virtual address a solution to
this problem, provided that the operating/language system
doesn't allow you to fabricate addresses?  That's the only
sense in which the Lisp Machine solves the problem, and it
only does it by virtue of NOT having any local capability
for named files.  The LM doesn't provide any facilities
that replace a local file system, either, e.g. there are
no tools in the system for constructing and manipulating
directories of variables.  Furthermore, the LM would be
helpless without the presence somewhere in the network
of some very conventional file systems which handle messy
questions like space accounting, periodic backup, user
authentication, etc.

Of course, if you want local objects to be remotely accessible,
then you do need something much more like capabilities.  Given
that mainframes (processor + memory) are so cheap these days,
compared to the cost of a reasonable-size disk, I'm more
inclined to favor putting all potentially sharable objects on
a separate server mainframe and let workstations either cache
them on their local disks or get them over the network whenever
they need to.  This requires some architectural changes in the
world to make that network access comparable in speed to, say,
something between a cache miss and a bubble memory access, as
opposed to a disk access.

To the best of my knowledge, Star, like the research machines
(Dolphin and Dorado), has a conventional paged address space;
the Star OS provides for mapping full or partial files into
this space, like Tenex or Multics.  The OS happens to be
optimized for mapping sequential runs of pages of a single
file into contiguous virtual pages, but that is an
optimization only.