NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/os/misc/754

Internet Message Format | 1992-07-30 | 17.3 KB

Xref: sparky comp.os.misc:754 comp.unix:8 comp.windows.misc:1120 comp.windows.x:14629
Newsgroups: comp.os.misc,comp.unix,comp.windows.misc,comp.windows.x
Path: sparky!uunet!mnemosyne.cs.du.edu!nyx!pmarriot
From: [e-mail] (Paul Marriott)
Subject: DomainOS Features summary (OS and windows related stuff)
Message-ID: <[e-mail]>
Sender: [e-mail] (netnews admin account)
Organization: Nyx, Public Access Unix @ U. of Denver Math/CS dept.
Date: Thu, 30 Jul 92 15:17:22 GMT
Lines: 391

Recently,   I   posted   a   question   on   the  comp.sys.apollo
newsgroup:

>  Since DOMAIN/OS has, or is about to be, consigned to  the  annals
>  of  history,  I  thought  it  might  be  interesting  to find out
>  peoples favourite features (or for  that  matter,  mis-features).
>  It  would be interesting to see if any of them are resurrected in
>  the future.
>
>  I have been an apollo user since around 1986 (in the days  of  SR
>  9.2.3)  and it is quite sad to think that a lot of the innovative
>  work apollo produced is going to be lost.
>
>  Please refer, if necessary, to features of  past  releases  which
>  have  been  removed  with  the  various  so-called "upgrades" and
>  "improvements"  that  new  releases  have  brought.  Perhaps  I'm
>  looking  back  through  rose  coloured  spectacles, but I seem to
>  remember that the dm ran just as fast on a DN 330 with 2M RAM  as
>  it does on a DN3500 with 16Mbytes.
>
>  Friends  of  mine,  who  have  been  brought  up  in  an  X  only
>  environment, are still  amazed  how  fast  the  apollo  windowing
>  system  considering  how  slow  some of the hardware is by todays
>  standards.
>
>  So I'll kick off with a few of my favourite features:
>
>  DM  -  how  to  summarise  this  in  only  a  few  lines?  memory
>  efficiency  (in  the  pre SR 10 days) meaningful error messages -
>  ie no stupid core dumps the automagically networked file system
>
>  misfeatures:
>
>  they tried to make it just like real unix :-(
>
>  If you like, email me on [e-mail] and I'll summarize.
>
>  Cheers.
>
>  Paul Marriott VLSI Designer and part time apollo hack.


From  the  responses  I  received,  there was the suggestion that
this subject would be interesting to  a  wider  audience  so,  as
requested,    here    is   a   cross-posting   to   comp.os.misc,
comp.unix, comp.windows.misc and comp.windows.x

______________________________________________________________________

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