carlson@aftac.tis.llnl.gov (John Carlson) (04/29/89)
After several years experience with UNIX, something dawned on me. I know too many languages: C, awk, sed, lex, yacc, Bourne Shell, C shell and now I may learn UIL, Xcu's wlm etc., etc. I know too many configuration file formats: fstab, passwd, Xdefaults, termcap, exports, etc. etc. I know to many expression formats: regexp, X fonts, globbing. Unfortunately, I am entirely unfamilar with LISP machines. Given the same functionality as UNIX, could LISP provide some uniformity; would LISP make a system easier to use, administer, and develop on, or would I have to learn several configuration file formats and expression formats? Does LISP vary formats as widely as UNIX does? To UNIX people: Could all of these configuration files be standardized? John "Maybe LISP isn't so complex after all" Carlson
roberts@studguppy.lanl.gov (Doug Roberts) (04/30/89)
In article <166@ncis.tis.llnl.gov> carlson@aftac.tis.llnl.gov (John Carlson) writes: > > After several years experience with UNIX, something dawned on > me. I know too many languages: C, awk, sed, lex, yacc, Bourne Shell, C shell > and now I may learn UIL, Xcu's wlm etc., etc. I know too many > configuration file formats: fstab, passwd, Xdefaults, termcap, exports, > etc. etc. I know to many expression formats: regexp, X fonts, globbing. > > Unfortunately, I am entirely unfamilar with LISP machines. > Given the same functionality as UNIX, could LISP > provide some uniformity; would LISP make a system easier to use, > administer, and develop on, or would I have to learn several > configuration file formats and expression formats? Does > LISP vary formats as widely as UNIX does? > > To UNIX people: Could all of these configuration files be standardized? > > John "Maybe LISP isn't so complex after all" Carlson > Better yet: develop LISP on a unix box. That way you have the best (and the worst) of both worlds. {And, you can drop C from your list of supported languages :-)} Seriously, system admin on a Symbolics LISPm is a serious headache compared to Sun system admin. The networking software is not as sophisticated (yes, I _do_ know about Sun's infamous YP); the documentation for the various configuration files is sketchy; you would miss the tools like grep, awk, & piping. On the other hand, I still miss the LISPm tools like the powerful ZMACS editor, the frame-based source debugger, the mouse-sensitve inspector, and the nice toggle interface to the disassembler. I hope you are listening, Lucid. --Doug -- =============================================================== Douglas Roberts Los Alamos National Laboratory Box 1663, MS F-602 Los Alamos, New Mexico 87545 (505)667-4569 dzzr@lanl.gov ===============================================================
miller@CS.ROCHESTER.EDU (Brad Miller) (05/01/89)
Date: 29 Apr 89 18:46:54 GMT
From: roberts@studguppy.lanl.gov (Doug Roberts)
Seriously, system admin on a Symbolics LISPm is a serious headache
compared to Sun system admin. The networking software is not as
sophisticated (yes, I _do_ know about Sun's infamous YP);
Actually, I'd say it's more sophisticated: the lispms employ "transparent
networking" which is considerably more efficient than UNIX. editing/copying
a file on the lispm, e.g. from the INTERNET is (for the user) the same as
editing copying locally. You don't run FTP, then copy the file, then edit
it... and that's a trivial example.
the
documentation for the various configuration files is sketchy;
Granted, some are. I've never had a problem decoding them. You see, you have
the source code to look at...
you
would miss the tools like grep, awk, & piping.
The current release includes a grep-like tool (find string; find symbol)
which does roughly everything grep does, and lets you restrict it to a
system or package and of course the editor has more powerful search tools
than grep; as for awk and piping, who needs additional languages? When I
need e.g. the output of one function to be the input of another, I write it
that way in lisp to a lisp listener, and I don't need to know yet another
shell language to do it. You just get used to writing a lot of two-liners to
do stuff; if you find yourself doing some particular thing often enuff, put
it in your init file. (You can even make it a "command").
I do site admin at our site for both Symbolics and Explorer hosts, including
their interface to the UNIX world. This for roughly a dozen lisp machines,
and I do it in roughly 10% of my weekly time[*] (the rest spent on what I
*really* do here). Contrarywise, back when we had that many UNIX machines
(Sun 2/120s and Vax 750s) we had two full time UNIXoids doing site admin on
them. Admitably, we now have even more UNIX machines, but really only one
environment (Sun 3); we still have 1.5 full timers doing UNIX maintainance
and a manager. I'm handling two environments in *much* less time than that,
and expect no real problems should we get, for example an XL400 which
requires different binaries than the 3600 series.
[*] I won't make a completeness comparison; the hand holding the UNIX admins
do is much greater than what I supply.
----
Brad Miller U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}roberts@studguppy.lanl.gov (Doug Roberts) (05/01/89)
In article <1989Apr30.183925.19847@cs.rochester.edu> miller@CS.ROCHESTER.EDU (Brad Miller) writes:
Date: 29 Apr 89 18:46:54 GMT
From: roberts@studguppy.lanl.gov (Doug Roberts)
Seriously, system admin on a Symbolics LISPm is a serious headache
compared to Sun system admin. The networking software is not as
sophisticated (yes, I _do_ know about Sun's infamous YP);
Actually, I'd say it's more sophisticated: the lispms employ "transparent
networking" which is considerably more efficient than UNIX. editing/copying
a file on the lispm, e.g. from the INTERNET is (for the user) the same as
editing copying locally. You don't run FTP, then copy the file, then edit
it... and that's a trivial example.
You don't have to do it that way on a Unix system. Simply mount the
external file system. (And it's a _lot_ faster than the Symbolics'
(ILA)NFS software).
--Doug
--
===============================================================
Douglas Roberts
Los Alamos National Laboratory
Box 1663, MS F-602
Los Alamos, New Mexico 87545
(505)667-4569
dzzr@lanl.gov
===============================================================barmar@think.COM (Barry Margolin) (05/01/89)
In article <ROBERTS.89Apr30225016@studguppy.lanl.gov> roberts@studguppy.lanl.gov (Doug Roberts) writes: >In article <1989Apr30.183925.19847@cs.rochester.edu> miller@CS.ROCHESTER.EDU (Brad Miller) writes: > Actually, I'd say it's more sophisticated: the lispms employ "transparent > networking" which is considerably more efficient than UNIX. editing/copying > a file on the lispm, e.g. from the INTERNET is (for the user) the same as > editing copying locally. You don't run FTP, then copy the file, then edit > it... and that's a trivial example. >You don't have to do it that way on a Unix system. Simply mount the >external file system. (And it's a _lot_ faster than the Symbolics' >(ILA)NFS software). First of all, the above only works if the server happens to be running the same networked file system protocol as you. Lisp machines have been able to access arbitrary remote file systems for a decade, using pre-existing networking protocols. Is there an NFS server for TOPS-20, ITS, Multics, or Macintosh? The Lispm can access all of these using ordinary FTP. Also, the Lispm generic network facilities aren't limited only to file access. For instance, there's also just one terminal protocol, which automatically chooses the appropriate remote login protocol (Supdup or Telnet over TCP/IP or Chaos, VMS's login protocol over Decnet, ASCII over a serial port, etc.). Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
gerry@toadwar.ucar.edu (gerry wiener) (05/01/89)
Can I login to a symbolics machine using a vt100, and run an emacs editor on the machine, develop code etc., in this manner? I would essentially like to login to a symbolics remotely and get work done just as I do on unix machines. gerry wiener -- Gerry Wiener (303)497-8790 Email:gerry@toadwar.ucar.edu NCAR P.O. Box 3000 Boulder, Co 80307-3000
raymond@ptolemy.arc.nasa.gov (Eric A. Raymond) (05/02/89)
In article <ROBERTS.89Apr29124654@studguppy.lanl.gov> roberts@studguppy.lanl.gov (Doug Roberts) writes: >supported languages :-)} > >Seriously, system admin on a Symbolics LISPm is a serious headache >compared to Sun system admin. Debateable. Certainly they are different. Certianly a LISPM takes a lot of knowledge to operate, but I wonder how that compares to A UN*X box? I think the real issue is that a LISPM is breaks traditional molds and you must adopt a different attitude towards it. >The networking software is not as sophisticated. Hmmm. Do you have the layered products? One thing that a LISPM does is to provide excellent support for networking in a heterogenous environment. >documentation for the various configuration files is sketchy; you Really. Seemed like there was a whole volume dedicated to it. And it should be online in the document examiner. >I would miss the tools like grep, awk, & piping. That's because your mixing your metaphors. On a LISPM you would do things differently. Don't use GREP if you want to find a function (but if you do, the ZMACS editor provides a flexible mechanism for doing all sorts of searches, multiple replaces, etc across multiple files (although this is not documented very well, agreed), just press a key and instantly you are editing the function definition or it's callers. Not sure of the name, try apropos. > >On the other hand, I still miss the LISPm tools like the powerful >ZMACS editor, the frame-based source debugger, the mouse-sensitve >inspector, and the nice toggle interface to the disassembler. I hope >you are listening, Lucid. And Franz too. Note: LISPM references almost always mean Symbolics running Genera 7.x -- Eric A. Raymond (raymond@ptolemy.arc.nasa.gov) G7 C7 G7 G#7 G7 G+13 C7 GM7 Am7 Bm7 Bd7 Am7 C7 Do13 G7 C7 G7 D+13: Elmore James
miller@CS.ROCHESTER.EDU (Brad Miller) (05/03/89)
Date: 1 May 89 04:50:16 GMT
From: roberts@studguppy.lanl.gov (Doug Roberts)
In article <1989Apr30.183925.19847@cs.rochester.edu> miller@CS.ROCHESTER.EDU (Brad Miller) writes:
Actually, I'd say it's more sophisticated: the lispms employ "transparent
networking" which is considerably more efficient than UNIX. editing/copying
a file on the lispm, e.g. from the INTERNET is (for the user) the same as
editing copying locally. You don't run FTP, then copy the file, then edit
it... and that's a trivial example.
You don't have to do it that way on a Unix system. Simply mount the
external file system. (And it's a _lot_ faster than the Symbolics'
(ILA)NFS software).
Iff both systems run NFS; the Symbolics way you can easily run multiple
protocols to supply FILE service. Thus, TCP-FTP, TFTP, NFS, CHAOS-FILE, DNA
are all "the same". Object oriented programming at work. How do you "mount",
say, SIMTEL20.ARPA (and why would they let you..)
(ILA)NFS, btw, is a lot faster if you don't mount your LMFS on too many
machines; I've found it to be quite reasonable if it's mounted by, say, 3-4
UNIX boxes (fast as FTP or better) and unusable if mounted by 50.
----
Brad Miller U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}robv@pitstop.West.Sun.COM (Rob Vollum) (05/04/89)
In article <1989Apr30.183925.19847@cs.rochester.edu> miller@CS.ROCHESTER.EDU (Brad Miller) writes: >Actually, I'd say it's more sophisticated: the lispms employ "transparent >networking" which is considerably more efficient than UNIX. editing/copying >a file on the lispm, e.g. from the INTERNET is (for the user) the same as >editing copying locally. You don't run FTP, then copy the file, then edit >it... and that's a trivial example. I'm sorry, but I've got to disagree here. While LispM networking may be more convenient than FTP, it is definitely not transparent -- you've still got to know what machines your files live on. For "transparent networking", look at NFS, which is supported by any "serious" UNIX, which allows a user to build his own logical filesystem, using pieces of other filesystems around the network. Then there is no need to know where anything lives for copying, editing, etc. Compare the LispM's (ed "some-other-machine:>foo>hacks>bar.lisp") to "emacs /usr/robv/hacks/bar.lisp" for transparency. Given enough bandwidth, NFS can work over wide area networks as well, giving the same transparency. During the summer olympics in S. Korea, Sun consultants and Kodak folks used NFS to build logical "single view of the world" file systems from systems in Korea, London, and New York. Allowing for the requisite satellite latency, users had no idea where a file they were editing *really* lived! >as for awk and piping, who needs additional languages? When I >need e.g. the output of one function to be the input of another, I write it >that way in lisp to a lisp listener, and I don't need to know yet another >shell language to do it. You just get used to writing a lot of two-liners to >do stuff; if you find yourself doing some particular thing often enuff, put >it in your init file. (You can even make it a "command"). You're missing the point. First of all, using UNIX pipes is not learning another language. Secondly, the real use of pipes is not the processing by one command of the single result of a former command. In that case, you're right; function composition in Lisp is reasonable. The real power of pipes comes in the processing by a second function a *stream* (or "uninstantiated file") of information produced by a former function; e.g. "grep foo bar.lisp | wc -l". Granted, it can be done by creating a custom command that sends all output to a stream, then passes that stream to another command, but this is no where near as trivial as you are trying to make it out to be, and is not as general as having a pipe mechanism available to you. >I do site admin at our site for both Symbolics and Explorer hosts, including >their interface to the UNIX world. This for roughly a dozen lisp machines, >and I do it in roughly 10% of my weekly time[*] (the rest spent on what I >*really* do here). Contrarywise, back when we had that many UNIX machines >(Sun 2/120s and Vax 750s) we had two full time UNIXoids doing site admin on >them. Admitably, we now have even more UNIX machines, but really only one >environment (Sun 3); we still have 1.5 full timers doing UNIX maintainance >and a manager. I'm handling two environments in *much* less time than that, >and expect no real problems should we get, for example an XL400 which >requires different binaries than the 3600 series. Again, you're comparing apples to oranges. The emphasis when using a LispM is *not* on network services and connectivity (I didn't say that you don't use networks; it's just not the emphasis). A LispM is a single user, non-secure environment, so clearly there's less to do. Add a user? Only if you feel like it. When you get down to editing LispM namespaces, it can get pretty disgusting as well. Don't get me wrong here -- I've worked for both Symbolics and TI, and am a dedicated Lisp hacker. I use Lisp for a great deal of my current Sun programming, because Lisp is a great language. I've just recognized that UNIX (as an OS) has alot of good functionality as well, that you just won't find on a LispM. What's really needed is a good Lisp programming environment (for program development/debugging) on top of a real OS (that manages filesystems, networks, users, etc). Rob Vollum Sun Microsystems, Lexington, MA ...sun!sunne!robv
rcp@perseus.sw.mcc.com (Rob Pettengill) (05/05/89)
In article <656@pitstop.West.Sun.COM> rvollum@sun.com (Rob Vollum) writes: ;In article <1989Apr30.183925.19847@cs.rochester.edu> miller@CS.ROCHESTER.EDU (Brad Miller) writes: ; ;>Actually, I'd say it's more sophisticated: the lispms employ "transparent ;>networking" which is considerably more efficient than UNIX. editing/copying ;>a file on the lispm, e.g. from the INTERNET is (for the user) the same as ;>editing copying locally. You don't run FTP, then copy the file, then edit ;>it... and that's a trivial example. ; ;I'm sorry, but I've got to disagree here. While LispM networking may be more ;convenient than FTP, it is definitely not transparent -- you've still got ;to know what machines your files live on. For "transparent networking", look ;at NFS, which is supported by any "serious" UNIX, which allows a user to ;build his own logical filesystem, using pieces of other filesystems around ;the network. Then there is no need to know where anything lives for copying, ;editing, etc. Compare the LispM's (ed "some-other-machine:>foo>hacks>bar.lisp") ;to "emacs /usr/robv/hacks/bar.lisp" for transparency. Given enough bandwidth, ;NFS can work over wide area networks as well, giving the same transparency. ;During the summer olympics in S. Korea, Sun consultants and Kodak folks used ;NFS to build logical "single view of the world" file systems from systems in ;Korea, London, and New York. Allowing for the requisite satellite latency, users ;had no idea where a file they were editing *really* lived! ; ... Try again ... the lisp machine supports logical pathname hosts. A logical host allows an arbitrary mapping of directories and files, into a logical file structure independent of host, file system, network type, and network protocol. As a heavy user of both lisp machines, and "serious" UNIX machines I have found the logical pathname host approach unmatched in the ability to create software that will run transparently regardless of the filesystem environment where it and its data are stored. ;rob Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp
robv@pitstop.West.Sun.COM (Rob Vollum) (05/05/89)
In article <2308@perseus.sw.mcc.com> rcp@perseus.sw.mcc.com (Rob Pettengill) writes: >Try again ... the lisp machine supports logical pathname hosts. > >;rob > You're right -- I wasn't considering any LispM "set-logical-pathname-host" functionality, which was an unfair omission. The real point of my posting wasn't to get into a feature-by-feature comparison of LispM vs. UNIX functionality -- that's just another religious war. Both environments provide some great features; both systems carry some strange baggage. Which supports you better? I guess that depends on what you do most. Rob Vollum Sun Microsystems, Lexington, MA rvollum@sun.com, ...sun!sunne!robv
barr@pineapple.bbn.com (Hunter Barr) (05/09/89)
In article <2308@perseus.sw.mcc.com> rcp@perseus.sw.mcc.com (Rob Pettengill) writes: >In article <656@pitstop.West.Sun.COM> rvollum@sun.com (Rob Vollum) writes: >;In article <1989Apr30.183925.19847@cs.rochester.edu> miller@CS.ROCHESTER.EDU (Brad Miller) writes: >; >;>Actually, I'd say it's more sophisticated: the lispms employ "transparent >;>networking" which is considerably more efficient than UNIX. editing/copying >;>a file on the lispm, e.g. from the INTERNET is (for the user) the same as >;>editing copying locally. You don't run FTP, then copy the file, then edit >;>it... and that's a trivial example. >; >;I'm sorry, but I've got to disagree here. While LispM networking may be more >;convenient than FTP, it is definitely not transparent -- you've still got ... >Try again ... the lisp machine supports logical pathname hosts. A >logical host allows an arbitrary mapping of directories and files, >into a logical file structure independent of host, file system, >network type, and network protocol. ... The LispM supporters are right about one thing-- remote file access is more transparent and MUCH easier on the LispM. I have had the experience of setting up NFS directories, and the Unix idea of one file system shadowing another is brain-damaged. The LispM style machinename:/usr/barr/... is easier and more often consistent with reality than /nfs/machinename/usr/barr/... NFS is trying to solve something that LispMs don't worry about: file protection. With LispMs you can just assume that the underlying protocol is FTP, and do whatever you would do to protect your files from random FTP access. This is crude, but easy to use and effective. NFS is striving for (but has yet to achieve) an improvement on this. I doubt if LispMs will ever attempt real file protection, and will make only minimal effort to support file systems that do, like NFS. NFS should try the LispM system of teaching each machine about different kinds of hosts, and having the ability to define new ones easily. If anyone says that is too much work for the implementors of NFS, then I'll ask, "What is the main purpose of NFS-- to make things easy for the implementor? To minimize the load on the processors? Or maybe, just maybe, to make it easy for the people using it? ______ HUNTER