Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!parc.xerox.com!janssen From: janssen@parc.xerox.com (Bill Janssen) Newsgroups: comp.soft-sys.andrew Subject: Re: Why isn't ATK more widely used? Message-ID: Date: 24 Jul 90 21:30:18 GMT References: <2869@awdprime.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 83 I've been working with Andrew for a couple of years now, outside the ITC and CMU environment, and I've come up with one big reason. While ATK is a very broad and comprehensive environment, and the best thing I've seen in terms of an X11/Unix environment (which excludes things like Cedar, SmallTalk, the Macintosh, and Interlisp), it is too shallow. By this I mean that ordinary users (outside the CMU environment) keep tripping over things in ATK that make them turn to other tools. For example: - almost no one around here uses typescript, the official ATK tool for running shells in, because it does not support rlogin or curses-oriented programs. There is no officially supported terminal emulator program in ATK. tm, the contrib terminal emulator, does not emulate a vt100, the way that xterm does, and it loses the ability to use cut/paste etc., when being used by a curses program. (Which makes some sense, but it annoys people who are rlog'ed in to some other machine, and want to cut and paste the way they do with an rlog'ed in xterm.) Most people here use xterm instead of typescript or tm, just because of the rlogin problem. - when the R4 help tool came out, it core-dumped almost every time a man page was requested. After having that happen to them 3 or 4 times, most pioneers around here turned to xman instead, and have never turned back. This has the added effect of making the documentation on ATK harder for them to read, since they are not used to help. I myself have `man' aliased to `/bin/man $* | col -b | pipescript'. I really enjoyed help under R3, but it got too Byzantine and unpredictable under R4. - textview is a fairly reasonable text editor. Unfortunately, it does not support undo, which in modern emacs-style text editors is a must. In general around here, most people need two editors, a code editor and a document editor. ez is sort of both, but not really good enough at either to beat out GNU Emacs for the code editing job (no undo, hard to share/change/customize modes, what's the analogue of M-x recover-file?), and FrameMaker or Publisher for the document job (no virtual-paper mode). I use GNU Emacs for code, ez for documents. - Most people would like to have a good drawing editor on the Sun -- a simple MacDraw clone. ATK provides zip, which is an extremely idiosyncratic drawing editor (apparently actually designed to support the Great American History Machine, not as a drawing editor). zip was plagued by unfortunated interactions with the R3 and early R4 X servers, which would cause the server to core-dump when various standard zip demos were performed. Which made one's whole world disappear. People learned early on not to use zip. Nowadays, zip still has bugs, such as not wrapping itself in an ATK datastream when invoked at the top level, and having an extremely bad menu layout. Most people here go to the Mac to produce figures, or use the graphics editor in FrameMaker. - table, the ATK spreadsheet, was eagerly adopted by some people here. After some early crashes due to impossible-to-reproduce malloc bugs (apparently a bad pointer being passed to realloc), they learned to steer clear of it. Now they use a spreadsheet on a Mac, or use the sc public domain curses-oriented spreadsheet in an xterm. - printing for all of ATK is very delicate. It requires that one have AT&T ditroff, and Adobe's transcript package. Most people who don't have these also have trouble getting money to purchase them for this experimental ATK system. - no new user appreciates ATK menus. So if you look at what might be considered a ``full-Andrew'' environment (console, messages, typescript, help, ez-textview-zip-raster-table), the only things that really make the grade are console and messages. Of course, messages uses umpty-zillion inodes (every message in a separate file) and hides your mail in files that are hard to run grep on, and console causes some of our Sun-4/330's to lock up in some low level assembly language routine. But even so they are judged more of a win than a nuisance. A typical X screen around here might have: messages, console, one or two GNU Emacs', a FrameMaker control strip, one or two xterms, an xbiff, and an xman. Some people use rmail in GNU Emacs instead of messages. There is no good way to read USENET news with ATK, so you have to run xrn or Emacs gnus or rn in an xterm (tm doesn't work with it too well). By the way, I have set up messages to read news and discontinued it after a month. It uses unbelievable amounts of CPU to run CUI scripts to do the indexing, and the interface through messages is clumsy for certain operations (posting a followup, for example). Now, if you're just going to run messages and console, ATK requires a lot of disk and a lot of intellectual effort, to get everything running. Maybe too much, for the payback. Bill