NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/sys/apollo/3097

Text File | 1992-07-23 | 16.5 KB | 382 lines

Newsgroups: comp.sys.apollo
Path: sparky!uunet!mnemosyne.cs.du.edu!nyx!pmarriot
From: [e-mail] (Paul Marriott)
Subject: DOMAIN/OS features - summary
Message-ID: <[e-mail]>
Sender: [e-mail] (netnews admin account)
Organization: Nyx, Public Access Unix @ U. of Denver Math/CS dept.
Date: Thu, 23 Jul 92 22:26:21 GMT
Lines: 371

Here  is a summary of the features (and misfeatures) of DOMAINOS.
Thanks to all those who responded and I apologise if I've  missed
out anyone/anything.

I  compiled  this  list using my favourite editor (DM of course!)
and  using  my   favourite  function  -   cutting   and   pasting
rectangular areas (try doing that in vi!).

One   "feature"  which  I  should  mention  is  the  apollo  demo
software. I used to have a tape with over 150Mbytes  of  this  on
but  alas I have had to cut this down to just a few demos now. We
just received a sparc ipx  here  (  :-(  )  and  so  people  were
running  the supplied sunview demos. Someone set the "bouncedemo"
running  which  displays   a   bouncing   rectangle.   All   very
unimpressive.  So  on my two trusty apollos sat on the same bench
I set the net_bounce demo running (the one that  bounces  a  ball
across  multiple  windows  and  machines).  No comparison. People
could not believe that such "slow old machines"  could  run  such
an  impressive demo. As with  all the old apollo demos, they were
well thought out and showed the  machines  off  to  the  greatest
advantage.  (I have the source to net_bounce if anyone wants it).
Anyway,  I  digress.  Here  is  the  list  of  features,  in   no
particular order.

Cheers,

Paul.


Features
********

o The typed file system

  John Thompson ([e-mail]) writes:
  >  The  USER-extensible,  typed, file system!  Why just have devices
  >  with drivers?    Have the whole bloody file  system  loaded  with
  >  drivers  for  everything  and          anything.   Want  to  have
  >  people not screw around reading and  writing  directories?  Fine;
  >  just  have  the  type-mangler  restrict operations.  Want to have
  >  an          object resolve to one of several places,  to  provide
  >  robustness?   Go  ahead!        Want  to  store  large  read-only
  >  objects in compressed format, and still read       them?   Sounds
  >  good  to  me  too.   (Thanks,  guys  --  I love the COMPRESS file
  >  type.)

  Frederick G.M. Roeber ([e-mail]) writes:
  >  ***   TYPE   MANAGERS   ***   (My  personal  favorite).   In  the
  >  theoretical CS workshops,  where  everybody  is  throwing  around
  >  modern  buzzwords  like "object oriented," a hot topic of late is
  >  the "object store."  Apollo has had an "object store"  for  years
  >  --  only  they  still  called  it the file system, and called the
  >  mechanisms  "types"  and  "traits."   About  once   a   year   on
  >  comp.unix.wizards,  somebody  wants  to  write something to allow
  >  them on-the-fly compression of their files.   Everyone  responds,
  >  "No  you  can't  do  it,  but  you don't want it anyway -- if the
  >  Unix Gods prohibit it, it must be evil."  But with  Apollos,  you
  >  can  do it.  (And  in fact, at 10.4 they included a read-only otf
  >  decompression type.)  I have many  of my infrequently used  large
  >  text  files  kept this way.  The flexible namespace allows things
  >  like gateway types (I wrote a manager  to  mount  our  N-thousand
  >  xenix systems onto the Apollo filespace) and file versioning.

  Tobias Weingartner ([e-mail]) writes:
  >  I  also  like  the  idea  of  the  typed  file  system.  It alows
  >  backward compatibility, while at  the  same  time  allowing  some
  >  neat/novel things like the rgy, etc.


o The networked file-system

  Frederick G.M. Roeber ([e-mail]) writes:
  >  Transparent,  shared  filesystem.   We  have  >100 nodes.  As the
  >  snakes slither  in,  we  have  to  fart  around  with  NFS.   For
  >  everyone  to  be able to log in anywhere, and for the files to be
  >  available everywhere, we need to cross-mount all  machines.   For
  >  N  machines,  this  means  worrying about O(N^2) NFS connections.
  >  With N == 10 our  sysadmins  are  beginning  to  have  headaches.
  >  With  N  >  100,  it  will be impossible.  And still that doesn't
  >  make everything available -- to get  to  everything,   you  still
  >  have to go log in on that machine.

  Chuck Tomasi ([e-mail]) writes:
  >  This  is  probably the point I'm going to miss most of all.  Plug
  >  'n play networking was great.  Routing between  internets  was  a
  >  little  tricky  at  first,  but  eventually  worked  out  for the
  >  better.  No messing around with /etc/checklist as in HP-UX  every
  >  time  a new system came online (which could be a pain if you have
  >  half a dozen systems to set up in a day.)

  Tobias Weingartner ([e-mail]) writes:
  >  I   don't   like  nfs  much,  but  the  idea  of  being  able  to
  >  access            (almost) anything on a  net  with  //  is  very
  >  neat,  novel,  and             should  be  extended.   (Mach is a
  >  little screwy in this respect..)


o The Keyboard:

  John Thompson ([e-mail]) writes:
  >  The  keyboard.  Biilllioonnns and biillionnns (sorry C. Sagan) of
  >  keys all   waiting to be redefined.  I  _hate_  having  to  point
  >  and click and pulldown   and popup everything.

  >  Frederick G.M. Roeber ([e-mail]) writes:
  >  The  keyboard.  Even if they make me use a sun or a snake, I want
  >  my domain  keyboard.  I'll kernel hack, if need  be,  to  get  my
  >  keyboard.


o DM (pads etc),

  Frederick G.M. Roeber ([e-mail]) writes:
  >  The  entire  shell history at your fingertips.  Infinte rollback.
  >  The full  editor  there,  for  cutting  and  pasting.   Multiline
  >  editing  in  the  input  buffer.   Getting  the  input characters
  >  appearing in the output at the right  place,  even  if  you  type
  >  ahead.

  John Thompson ([e-mail]) writes:
  >  PADS  PADS  PADS  PADS PADS PADS PADS.  Why do we have to go to a
  >  graphical     interface with  over  a  million  pixels,  and  use
  >  TERMINALS??!!??

  Chuck Tomasi ([e-mail]) writes:
  >  This  one  can  really  fall  into both groups.  DM had some very
  >  good merits (unlimited scroll  back,  simple  for  new  users  to
  >  grasp,  all  the  keys  you needed to control DM were right there
  >  are the keyboard and spelled out plainly, etc.) as well  as  some
  >  very bad merits (vt100 emulation wasn't all that terrific.)


o  DM editor

  Frederick G.M. Roeber ([e-mail]) writes:
  >  DM  editor.   The world's easiest, most intuitive editor.  Forget
  >  ed, ex, and vi  -- nobody should be inflicted with  them.   Emacs
  >  takes    forever    to    start,    and    has   far   too   many
  >  control-alt-left-shift-cokebottle-x  key   combinations   to   be
  >  useful.   VMS's  EDT and EVE get pretty close, but you still need
  >  to know some hotkeys.   Most  editors  these  days  --  e.g.  the
  >  OpenLook,  DECWindows, and VUE editors -- are *so* mouse-oriented
  >  you need three hands (or be able to type with only one).

  David O. Dodge ([e-mail]) writes:
  >  DM  function  keys are numerous, labeled properly, and completely
  >  redefinable. (I'm talking about cut/past/grow/etc in addition  to
  >  the "f" keys). DM is still my favorite editor by far.


o  The micro-kernel.

  Frederick G.M. Roeber ([e-mail]) writes:
  >  Lots  of  the  traditional  kernel  functionality was pushed into
  >  user space, usually transparently with shared libraries and  type
  >  manager.


o  Shared libraries.

  Frederick G.M. Roeber ([e-mail]) writes:
  >  Yeah,  everybody's  got  them now, but Apollo had them first, and
  >  they *still* work better than the RU ones nowadays.


o   Diskless booting.

  John Thompson ([e-mail]) writes:
  >  In  order  to  boot  a  Hockey-Puck  diskless,  I  need to make a
  >  cluster machine (Warning - there is no easy way  to  uncluster  a
  >  machine,  and  there  are  potential problems in loading software
  >  updates on a clustered machine.  Do you want to continue?),  find
  >  out  what  the  LAN ID of the diskless machine is, and then boot.
  >  I can't do this as  a  temporary  "you're  up  and  going  again"
  >  solution to users' problems.


o   The token ring.

  John Thompson ([e-mail]) writes:
  >  Gee...   why  would  anyone  want a network interface that DIDN'T
  >  fall apart at high loads?  We hit about 5MB/sec  with  ~15  nodes
  >  talking  during   the  daily  backups.   What  will this do on an
  >  ethernet???   :-( "But Johnny, the ethernet is  standard.   Don't
  >  say bad things about it."


o Dynamic swap space.

  John Thompson ([e-mail]) writes:
  >  You  automatically  got  the  remainder  of the root volume,  and
  >  innovative programmers could map files  in  to  memory,  and  use
  >  remote systems for unlimited memory... virtually.   :-)


o  The registry.

  Frederick G.M. Roeber ([e-mail]) writes:
  >  For  single  machines,  /etc/passwd  is  ok.   For  clusters, you
  >  really need such tools.  For N > 100,  they  are  required!   The
  >  Domain  registry  allows  a  large  network, composed of separate
  >  cells (to use the new, OSF "in-word"), with  mutually  untrusting
  >  sysadmins  to be easily and simply managed.  I do not count Sun's
  >  "Yellow Pages" (or "NIS" these days) as a solution -- I count  it
  >  as a bletcherosity ranking below MS-DOS.


o Network wide commands

  John Thompson ([e-mail]) writes:
  >  Commands  to  query  all  machines in the network.This sucks in a
  >  mixed net, but I _loved_ getting lists of all the  machines  that
  >  I  needed  to worry about.  (bldt -a, netstat -a, ctnode, lcnode,
  >  lcnet, lvolfs -a, lusr -allnodes, ....)

  Jinfu Chen ([e-mail]) writes:
  >  Use  /com/netstat  -config  to  get detailed listing of hardware.
  >  onfiguration.     And     like     thompsonpan.ssec.honeywell.com
  >  mentioned,   the  -all  switch  (and  the  -n  switch)  to  query
  >  information across network.
  >  crp command.  Rsh is okay but it brings me to my  home  directory
  >  instead of where I was.

  David O. Dodge ([e-mail]) writes:
  >  tb  --  the most useful command in Domain/OS (IMO). The fact that
  >  you can even look at the traceback of a process that  crashed  on
  >  *SOMEONE  ELSE'S*  machine  across  the  network  makes trying to
  >  solve user problems oh-so-much  easier.  The  primary  command  I
  >  keep wishing  UN*X had.


o  Blinkenlights

Frederick G.M. Roeber ([e-mail]) writes:
  >  Did  I  crash  the entire machine, or is it just taking awhile to
  >  reply to me?  Is the network dead?   Is  the  machine  paging  to
  >  death?  These tell you.


o  DDE

  Frederick G.M. Roeber ([e-mail]) writes:
  >  The   single  best  debugger  I  have  ever  run.   Through  type
  >  managers, it can be easily extended to  new  hardware  (even  new
  >  processors),  new  display  types,  new source languages, and new
  >  binary representations.  It  can  attach  to  running  processes!
  >  This  is  incredibly  useful!   It can debug on remote nodes.  It
  >  can follow fork()s properly -- you can  follow  the  parent,  the
  >  child,  or  both,  with  "both"  causing  the  debugger itself to
  >  fork.  It can step over an exec() call and do  the  right  thing:
  >  stop   at  main()  of  the  next  program!   A  full  programming
  >  language and full display control make it incredibly flexible.


o  Dialogue

  Frederick G.M. Roeber ([e-mail]) writes:
  >  Dialogue.   Yeah,  nowadays  you  can use programs like Xbuild or
  >  XDesigner to try to build an interface, but it takes  forever  to
  >  do,  and  you end up with a huge, crufty interface that outweighs
  >  the program!  Dialogue, on the other hand, was an  efficient  way
  >  of designing good looking, fast interfaces quickly.


o Aegis features

  Jinfu Chen ([e-mail]) writes:
  >  Rich and well documeneted OS calls (xxx_$).
  >
  >  The ts command.
  >
  >  Use  /com/netstat  -config  to  get detailed listing of hardware.
  >  figuration.  And like  thompsonpan.ssec.honeywell.com  mentioned,
  >  the  l  switch  (and  the  -n switch) to query information across
  >  network.
  >
  >  cpt command instead of ugly "find -print | cpio .." or  "tar  ...
  >  |  tar  .." contortion.  Didn't the Unix people ever need to copy
  >  or move a directory oss file system?!
  >
  >  Standard -help and -version switch in all Aegis commands.   Wanna
  >  to  find  wich  version  of  C  compiler you're using in HP-UX or
  >  SunOS, good luck.
  >
  >  Position independent command switch,  e.g.  "cpt  dir1  -ld  dir2
  >  -r".   rbak/wbak/rwmt.  Several features in these commands I like
  >  very much.  Device naming is one, instead  of  cyptic  /dev/rct8,
  >  -device ct is so much easier to remember.
  >
  >  RAI.   Trying  to  load  OS  across  network  in  HPUX  or  SunOS
  >  environment is a  loyal  pain.   This  probably  is  due  to  the
  >  limitation of underline filesystem.
  >
  >  crp  command.   Rsh is okay but it brings me to my home directory
  >  instead where I was.
  >
  >  Examples in Aegis help files.
  >
  >  Processes have names (the proc2_$set_name() call).


o  ACL'S

  Tobias Weingartner ([e-mail]) writes:
  >  Ok, they could  have  been  implemented slightly differently, but
  >  they got the basic job done.


o Graphics related stuff

  David O. Dodge ([e-mail]) writes:
  >  GSR  --  near-direct  access  to  the  graphics  hardware, with a
  >  standardized interface.
  >  GPR_$BORROW_MODE


o Misc.

  [e-mail] (David O. Dodge) writes:
  >  Symbolic  links  through  environment  variables.  Supports  BSD,
  >  SYSV,  and  AEGIS  all  at  the  same  time  (though  not  always
  >  perfectly).


o Apollo (the company)

  Frederick G.M. Roeber ([e-mail]) writes:
  >  The people of  the company.  For the past year or two, as I  have
  >  become  enamored  with  Apollo  Domain, I've been pushing to talk
  >  with the authors, buy a source listing, or  do  anything  to  get
  >  inside  and learn.  We've some people here who have been  working
  >  closely with Apollo for many years, and  they  tell  me  that  by
  >  now,  the  Apollo   folks would have given me a tape or printouts
  >  (if they hadn't hired me).  But  the  HP  suits  just  mindlessly
  >  follow  a  line  set  by  people in another world who  don't know
  >  computers.  (Though  I  must  say  the  HP  suits  are  nice  and
  >  polite,   unlike,  say,  Sun's.)   Perhaps  it could be summed up
  >  like this: Apollo was a  bunch  of  computer  people  who  ran  a
  >  company  selling  computers.  HP is a business,  which happens to
  >  sell computers.  I will freely admit that this  is  probably  why
  >  Apollo  fell  into  a position from where it could be taken over,
  >  and I have  nothing against companies  large  or  small  (I'm  an
  >  Adam  Smith  free  market  guy  myself) -- it's just that I don't
  >  like working  with  (or,  more  usually,  against)   that  large,
  >  bureaucratic mindset.


Misfeatures
***********

  Tobias Weingartner ([e-mail]) writes:
  >  Should  have  stuck  to  one  OS,  not 3.  That was this system's
  >  biggest problem.
  >
  >  Next, junk domain/windows.  (Yes, it was fast! ;-)  ),  but  face
  >  it,  X  is the way to go.  They should have developed an X server
  >  to the extent that the native graphics were developed.
  >
  >  \`local_data should not have to  be  there...  just  some  common
  >  sense  as  to  what  should,  and should not be linked across the
  >  net... ;-}


  Chuck Tomasi ([e-mail]) writes:
  >  This  one  can  really  fall  into both groups.  DM had some very
  >  good merits (unlimited scroll  back,  simple  for  new  users  to
  >  grasp,  all  the  keys  you needed to control DM were right there
  >  are the keyboard and spelled out plainly, etc.) as well  as  some
  >  very bad merits (vt100 emulation wasn't all that terrific.)