Path: utzoo!hoptoad!amdcad!decwrl!labrea!agate!bionet!apple!rutgers!mailrus!husc6!bbn!oberon!lipari.usc.edu!crum
From: crum@lipari.usc.edu (Gary L. Crum)
Newsgroups: alt.next
Subject: Re: The NeXT Problem
Summary: printer flexibility & boot-it-yourself environment discussed
Message-ID: <12844@oberon.USC.EDU>
Date: 16 Oct 88 17:02:57 GMT
References: <26435@ucbvax.BERKELEY.EDU> <5498@juniper.uucp> <3884@encore.UUCP>
Sender: news@oberon.USC.EDU
Reply-To: crum@lipari.usc.edu (Gary L. Crum)
Organization: University of Southern California
Lines: 89

In article <3884@encore.UUCP> bzs@xenna (Barry Shein) writes:
>
>The laser printer is even stranger, perhaps it was an afterthought.
>What you really want in that environment is a scheme to send printout
>to a high-speed printer which is shared (perhaps one located in the
>university copy-center where a cost accounting system is set up to pay
>as you go, there might be small satellites set up near each workroom.)
>

BYTE mentions "you could use a cube with a NeXT laser printer to act
as a print server on a network" and "The cube can print to non-NeXT
PostScript printers using its serial ports and Unix printer drivers."
I think the Berkeley lpd (with /etc/printcap) system is used, so
really, the shared printer could be a NeXT laser printer connected to
a staff-maintained machine, a LaserWriter IINTX connected to any other
UNIX system with lpd, or something complete esoteric such as the DEC
LPS-40 fast PostScript printer connected to a VAX running VMS but still
accessible from all Suns here at USC.  The possibilities are endless.
With a localtalk/ethernet gateway such as the Kinetics KFPS-4 and the
free Columbia Appletalk Package (CAP) for UNIX, even AppleTalk printers
could be used.  Actually, CAP's Printer Access Protocol (PAP) implementation
is quite fun.  A program called "tlw" lets any UNIX user interatively
talk to the PostScript interpreter (executive) of any LaserWriter on
accessible AppleTalk networks.  That leads to my next paragraph...

Barry's environment where students boot cubes off their own platters
poses many interesting security problems!  In such an environment, cubes
cannot "trust" each other because users have their own system disks
and hence all users are superusers for their respective machines.

In existing Sun installations that I have seen, it is technically possible
for users to boot of their own disk or tape, but such practice is not
intended and is detected by otherwise unexplained machine dowtime.
Perhaps the environment where users are allowed to boot NeXT cubes off
their own software is analogous to existing environments with PCs on ethernet
running TCP/IP protocols including NFS, but in the NeXT case the security
issues are more apparent because the user has control over a larger
and more mature system of software.

I sure hope that this free, boot-it-yourself environment becomes the norm,
but mixing UNIX and personal computing ideologies sure produces fireworks.

I ran MACH on a Sun-3/60C last summer, albeit without NFS.  It is interesting
that rsh/rlogin and their daemons were absent from the distribution.
Furthermore, compiling the source to those programs from 4.3BSD did not
result in working services right off because MACH changes the function
of ruserok() and other things.  The MACH I used even ran most SunOS
(pre-4.0) binaries, with notable exceptions being those that used
SunView libraries.

The brilliant engineers at NeXT and their group of advisors from academia
undoubtedly have plans for cube cluster configurations as well thought out as
the NeXT system itself, but until we all learn what those plans are, it sure
is fun to speculate and "publish" our ideas.  Perhaps we could use this forum
for the exchange of ideas for application programs that the NeXT machine makes
possible, especially those which would be less practical without such a
capable, well-packaged computer system.  (Keep in mind that readers working
for software developers might use ideas, or maybe just chuckle because they
are working on such things or better things.  The proposal is for the reader
in academia like myself, in a position to share ideas.)

For example, how about (don't laugh!):

  * if not already provided, a program to convert Mathematica output to
publication-quality PostScript description.  This might be easiest with the
source code to Mathematica (or rather, easiest for Stephen Wolfram to do).

  * given the above, a WSYWIG editor extended to keep Mathematical formulas
in some Mathematica-readable format but displayed in pretty format.  So,
papers with mathematics in them could be constructed using cut-and-paste
between Mathematica and the editor.  Papers could be send over email
as ASCII and MacWrite documents are now, and the receiver could cut
equations out of documents and "experiment" with them, using Mathematica
on his/her system.  I guess I would ultimately like to see a standard format
for the communication of mathematical proof (logic) without the free use
of natural language, but that is too ambitious.

  *  a multi-user interactive sketchpad, primarily for use to convey graphical
information while connected by conventional phone.  Or, perhaps packets of
voice could be exchanged rapidly enough over ethernet along with the graphical
information to replace the use of phone for some communication.  Scott Dyer of
the Ohio Supercomputer Center mentioned something like this multi-user
interactive graphical sketchpad in his talk at the HP Graphics Symposium last
July.  It ran under suntools -- this clearly requires only networked computers.

I won't post for a while after this, I promise.  Please, somebody let me know
if my choice or amount of material was not appropriate.

Yay Trojans!