🚀 go-pugleaf

In article <7871@segue.segue.com> gene@segue.segue.com (Gene Hightower) writes:

   This should go someplace other then comp.windows.x.

I agree but there is some applicability.

   In article <1068@witch.witchcraft.sf.ca.us> chappell@witchcraft.sf.ca.us (Tom Chappell) writes:

   >larryc@puente.jpl.nasa.gov (Larry Carroll) writes:
   >>This is a kind of silly thing to ask, but my supervisor doesn't think so:
   >>How does Apple's System 7.0 operating system compare with Unix?
						  ^^^^^^^^^^^^^^^^^

   So lets compare it with Unix.  First let me say that by "Unix" I am
   talking about SunOS 4.x and HP-UX from first hand knowlage.  I can't
   speak for all the systems that are (or have ever been) called Unix.

I've used BSD, SUN and SYSV,  I've also used Macs for a long time.

   >Man, oh man, I can't believe you just said that. I won't bother with a full
   >list, but apart from the "cosmetic" changes, System 7 includes:
   >
   >1. Peer-To-Peer networking via AppleTalk (LocalTalk, TokenTalk, or EtherTalk)
   >2. Inter-Application Communication, INCLUDING IAC BETWEEN APPLICATIONS RUNNING

   Unix systems have networking.  NFS provides file sharing, but there
   are lots of ways that Unix systems use the ability to network.  With a
   window system such as X, programs can run on one machine and display
   graphics on the screen of another machine.  The X window system is not
   unique to Unix, but the Mac OS makes it hard to build more then the
   server side of the system.  In other words, to use Macintish A you
   have to sit in front of Mac A and use it's keyboard and screen.  You
   can't access its CPU power from another computer.

Not true.  An application called Timbuktu does exactly this.  Also X is not
UNIX is not X.  X is a protocol,  X runs on VMS and even my old OS PRIMOS.
It isn't clear to me why running X clients on a Mac would 
make any sense anyway.  The major use for X is as a server to allow a
user to run applications which require special resources on another machine.
The MAC is hardly a compute resource.

Apple's file sharing is much kinder then NFS.  NFS has lots of flaws and
if you want a list I'll send it.  Apple doesn't require the user to 
know what's going on.  Most UNIX networking is not very sophisticated
and takes place right at the TCP or UDP layers,  and don't tell me about
OSI since I know it's a commie plot ( large grin here ).

   >3. Support for File, Folder, and Volume Aliases, similar to UNIX links, except

   The same as "symbolic" links.  Symbolic links can point to files on
   other filesystems and via NFS to files on remote machines.

Not the same.  Apple's aliases are just like symbolic links for files on
the same machine, but for files on a different machine they store all the
information to find that specific file.  UNIX requires much to have this
work (for example, setting up the automounter on SUN OS).

   >4. Publish and Subscribe.  One Macintosh user selects a portion of a document,

   This feature is mostly a feature of the application you are running,
   i.e. the drawing or word processing program.  System 7 may provide
   support to such operations, but it does not provide the operations
   directly.

This is a non-trivial support job.  I have yet to see any Unix applications
supporting live links.  It really is helpful for a hardware vendor to
specify how such things should work.  It binds the different software
suppliers to one mind of how to do the work. 

Apple has been the most successful example of this to date.  There
really isn't anything in the Mac that requires all Mac applications 
to look the same.  They could choose not to have, for example, the 
menu bar.  But Inside Mac says you shall do it and I don't remember the
last application I ran, if ever, which didn't.

   Unix applications have had the OS support (in the form of IPC) for
   some time.

Right.  Just go look at the work done on even the current ICCCM work
in X11R4 and tell me that this approaches the ease of use of the Mac 
clipboard.  On the Mac I can take and cut something from app A and 
paste into app B and usually not loose very much.  At worst the 
cut becomes a PICT resource.

IPC on UNIX is very non-standard.  You have Berkeley (SUN) RPC on quite
a few machines.  You have NCS on others.  The two don't interoperate.
The only absolute guarantee on all workstations is TCP/IP and even
that might not exist on some older Apollo boxes (with Domain) or 
(not up to date on this one) some VAX stations with DECNET.

   >5. Virtual Memory. Allows Macintosh users to actually run several applications

   Well, almost virtual memory.  All of the programs run in the same
   address space.  The programs don't move around.  If you run programs
   A, B and C and program B needs more space, you are out of luck.  You
   could give each program a huge block of address space, but it's not as
   good as each program having its own space.

It has VM.  It doesn't yet have some other memory management features
and memory protection isn't yet turned on.  The inability to move programs
around suprises me though.  You sure?

   Another problem with this way of doing things is that one program can
   screw up not only itself, but any other program on the system, or the
   OS itself.

Not a necessary limitation on a MAC with a PMMU or a 68030 or better.  But
Apple hasn't turned it on yet.

   System 7 also swaps to the filesystem.  This has drawbacks.  Speed
   mostly.  OS/2 does this also.  The big reason is that folks can
   upgrade to the new virtual memory OS without rearanging hard disk
   space.

This is a red herring.  The SUN OS does this also.  You can definitely use
the filesystem for swapping without incurring (serious) performance 
problems.  After all, the OS can superoptimize the swapping file,
for example, make all the blocks contiguous as Sun does.

Oh well.  That's enough comments for me.  Someone else can comment on the
rest.
--
Douglas S. Rand 
Internet:   <dsrand@mitre.org>
Snail:	    MITRE, Burlington Road, Bedford, MA 
Disclaimer: MITRE might agree with me - then again...
Amateur Radio: KC1KJ