Aihuxp.107 NET.blfp utzoo!decvax!ucbvax!ihnss!ihuxp!shqer Sun Jul 26 21:18:09 1981 BLFP 20 From: ihn5g!jdd (Joe Steffen filling in for John DeTreville) Subject: BLFP 3.20 Bell Labs Free Press Monday, 27 July 1981 Volume 3 : Issue 20 Today's Topics: BLFP on Netnews, Unix & Front End Processors, IHCC Tapes, Screen Editors, IH nopr, Inter-machine Routing, Netnews, Human-nets on Telephones, Unix/370, Laser Printers, CSNET, Byte Issue on Smalltalk, C Interpreter, Unix Symposium, HP2621 Terminal Mod, Cray Ad ---------------------------------------------------------------------- >From your moderator Subject: Distribution via Netnews The BLFP will now be distributed to netnews sites via the NET.blfp newsgroup, and the BLPP wil be distributed via btl.blpp. This is the last issue that will be mailed to ihuxk, ihuxp, ihnss, mhtsa, eagle, research, hocsr, chico, harpo and allegra. If your site has netnews and you didn't receive anything for the NET.blfp newsgroup recently, please let me know. Some IH machines that have installed netnews may continue to receive mailed copies; let me know if you are getting it via netnews and I will remove you from the mailing list. Joe Steffen ------------------------------ >From karn Thu Jul 23 00:22:06 1981 CDT remote from ihnss Subject: UN*X & front end processors Although I am not very familiar with 370 Unix, it is my understanding that it does provide the usual full duplex facilities of Unix by means of Series/1 front end processors. Front end processing isn't such a bad idea for DEC machines either. A lot of CPU time in Unix is spent crunching characters in the tty subsystem, a job that could be easily handled on a per-line basis by lowly 8-bit microprocessors. Unix tty overhead is particularly inexcusable when running screen editors in raw mode. Less work than cooked mode, true, but it bothers me that several pages of C code have to be executed each time I want to transparently send a character to a terminal. Unfortunately, the only "microprocessor" (I use the term loosely) made by DEC for the Unibus is the KMC-11. From personal experience in programming this device for a special application (digital speech storage) I can only say that the KMC is one of the worst processors to program I've ever seen. No wonder it isn't used for much. I've heard that somebody makes a general purpose z-80 controller card that plugs into the Unibus; does anybody know about it? Phil Karn ------------------------------ >From karn Thu Jul 23 00:36:41 1981 CDT remote from ihnss Re: Tapes and IHCC security I believe that most security problems could be avoided with operator- issued tape commands if the operator simply newgrp's & su's to the userid in question. To prove that the face at the window really belongs to the account, all he has to do is provide his password. The su command doesn't demand a password when the invoker is already root, but this can be changed by simply su'ing to some harmless non-root id first (e.g., oper, etc). I can think of all kinds of ways to get an operator reading a tape with super-user privileges to give me a super-user shell: reading in setuid programs, overwriting an "innocent" file that is really a link to a setuid-root command, etc. None of these would work if the operator simply su'ed to the user's id first. I don't like the idea of a special "tape" user id. It would be a real pain to copy files read in and owned by "tape" to files owned by my own userid. Phil ------------------------------ >From hobs Thu Jul 23 07:45:10 1981 remote from ihuxo Subject: Error correction In my recent contribution to BLFP 3.19 urging manual pages for user-installed commands, I discover that I consistently mixed up /usr/man/cat[1-8] and /usr/man/man[1-8]. If, by some chance, you looked in /usr/man/cat for a template for a man page, please look in /usr/man/man. Sorry about that, John Hobson ihuxo!hobs ------------------------------ >From warren Thu Jul 23 09:23:33 1981 CDT remote from ihnss Subject: EMACS on UNIX/370, and EF There was an attempt to install emacs on unix/370 here. The machine is known as ihn5m, and the user doing the installation was ihn5m!set. As far as I know, the problems encountered were: Running out of base address registers, because the compiler is not smart enough to allocate them when needed. Loader problems with external symbols, because it does not allow externals to be declared without the word external in more than one file. As far as I know, these were solved reasonably straight-forwardly, and emacs now runs all right. I don't know what was done about raw mode I/O, but I do know that unix/370 is supposed to have a special front end processor custom programmed for this application that will do plain old UNIX I/O (full duplex, character at a time) with the 370. This was scheduled somewhat behind the initial installation of UNIX/370. On the subject of ef, We just spent about 1 day with the implementors of ef, which is part of a much larger office automation system. It is admittedly inferior to emacs and ex/vi in basic features, extensibility and terminal support. It does have features that the others don't, namely: an integrated formatter which allows you to edit the pretty copy of a document, but keeps track of hidden formatting constraints for you. Extensive diagnostic messages and promping features that seem verbose to the sohpisticated user, but the level of verbosity can be controlled. Interfaces to other parts of the office automation system (A nice mail system, a good electronic calendar, and others). For what the system was aimed at (very naive users) it is a giant leap forward. The decision of which editor to support is an awkward one. The feeling is that there are large followings of vi, emacs, and several others in Bell Labs. People who already use these tools will never change, since each has strong appeal for its users. On the other hand, the inside BTL population is not the one that is screaming for screen editors, since we have found other outlets (roll your own, or import one from your friends). The rest of Bell, however, does want an editor and has no prior experience. For the majority of other users out there, extensions, sophisticated features, and terminal support mean little, since they have few kinds of terminals, don't want to learn how to write extensions, and can't use all of the special features. Viewed in this light, it is obvious why ef is a front runner, since it was written by people who can continue to support it and fits the needs of the community that is asking for an editor. Unix has grown way beyond the stage of being a research tool, and now gives service to an enormous community of users. I suspect that everyone realizes that there is no perfect screen editor, just like there is no perfect shell and no perfect programming language. It would be nice if some official support could be obtained for different applications of unix, such as a programmers environment, a word processing environment, an office automation environment, etc. I suspect that this is just too much for the current unix support organization to support concurrently, as can be seen from the recent attempts to reconverge pwb unix, IH unix, CB unix, research UNIX, v6 unix, and the like int the unix N.0 releases. Warren Montgomery ihnss!warren IH x2494 ------------------------------ >From leth Fri Jul 24 08:31:21 1981 CDT remote from ihnss Subject: BLFP: emacs on UNIX/370 Contrary to the remarks of ihuxo!hobs in BLFP 3.19, I understand from Don Aoki (ihuxm!don1) that EMACS is available on UNIX/370 (UNIX/370 uses a telecommunications front-end processor that supports full duplex connections; UNIX/ would be virtually impotent at half-duplex). In fact, Don told me that of all the locally favored screen editors, EMACS was the only one that had successfully been installed on ihuxm. Jim Leth (ihnss!leth) IH 55414 6B-326 x6133 ------------------------------ >From prt Fri Jul 24 11:09:30 1981 remote from iwsl1 Re: The article of July 23 by Greg Guthrie (grg) regarding choosing a visual editor for UN*X 4.2. Having an official visual editor would be pleasent... we could stop running pirate versions of ex/vi from the Unix System Administrator (usa) bin! But I, for one, know nothing of this 'EF', proposed by MH folk. Does anyone have documentation (even scanty) to contribute to BLFP regading 'EF'? It seems important to understand and comment on it *before* it is officially embraced. Paul Teetor... aka iwsl1!prt ------------------------------ >From alanr Fri Jul 24 09:04:17 1981 remote from ihuxl vi and ved are up on UNIX/370 (after a fashion). The 'current' implementation of 'ved' has proven to be unusable on UNIX/370 because it does character at a time I/O to the terminal which is incredibly inefficient in u370. (that is a story in itself). Vi is acceptably efficient on u370, but is somewhat buggy. I haven't heard of EMACS on u370. I am fairly sure it isn't up yet. Any volunteers? Alan Robertson ------------------------------ >From larry Thu Jul 23 12:34:42 1981 remote from ihuxm Subject: Templates and Screen Editors Joe, The version of 'ved' that I am trying to get running on VAX has the features you were interested in for instance - function-key, i set up a C if statement function-key, c set up a C case statement, etc The unfortunate part is the fellow who did this is was a back to school, so I'm trying to figure his pieces out. The really sad part is my time available to put on a "goody" project like this is diminishing past 0 time. I have a "work-able" ved source and this kids source, so it SHOULD be just a matter of seeing whats new. If you might have time I'd be glad to ship you both parts !! Interested?? Larry Marek (ihuxm!larry) [I'm hooked on emacs, but is there an ambitious ved user out there? JLS] ------------------------------ >From jej Fri Jul 24 21:17:26 1981 remote from ihuxl Subject: text formatting Some time back it was pointed out that with pointing devices one could eliminate a large fraction of the commands in editors. Analogously, with a good screen editor, one can eliminate a large fraction of the commands in text formatters. Why learn a magic command to begin a paragraph when one can type a new line and indent all by oneself, etc.? (Perhaps that's why ef combines editing and formatting aspects; I'm eager to find out more about it.) The answer, of course, is that the formatter makes stuff work with line lengths other than that of the terminal one is working on, numbers items, describes fonts, and such, but just as someone once proposed that, rather than have two conflicting indications of nesting in programming languages (i.e. brackets of whatever kind and indentation), one can use indentation, which the human unconsciously believes anyway as the right one, why not do a similar thing for text formatters? This would be especially helpful in view of the complexity and non-ease of use of nroff. I know of no other tool on Unix for which a statement such as [troff is] such that many operations must be specified at a level of detail and in a form that is too hard for most people to use effectively....(Kernighan, "A TROFF Tutorial") would be tolerated. If the Shell were as hard to use as [nt]roff are, Unix users would be stuck in the same world as (ecch) Obscenity System 3[67]0 users, who are at the mercy of those who write JCL and decide for them what procedures they are to run and how. Does anyone know of discussion on what would be a good set of primitive text operations and connectives? (This is starting to sound Ted Nelson-ish (not at all intended derogatively).) James Jones (ihuxl!jej) ------------------------------ >From veach Thu Jul 23 11:36:05 1981 remote from ihuxp Subject: nopr at IH IH UNIX users should be aware that the current x8by11 option on opr(1) will not exist when opr is replaced by the current nopr(1). I have found the following shell procedure does a good job of producing x8by11 output. The parameters work the same as nopr's. set -- `getopt b:d:c:e:o:nmk:sj:u: $*` opro= for i in $* do case $i in --) shift;break;; -n|-m|-s) opro="$opro $i";shift;; -*) opro="$opro $i$2";shift;shift;; esac done npf -i8 $* | x9700 -tib | nopr -t xr -r $opro ihuxo!usa suggests that you might want to replace the last line with: npf -s $* | x9700 -rib | nopr -txr -o10 -r $opro Michael T. Veach ihuxp!veach ------------------------------ >From ams Thu Jul 23 11:30:55 1981 remote from houxv Subject: inter-machine sending For some reason, it seems that every machine does not know about every other. This means that it is often neccessary to route mail, etc. through several different machines before reaching the final destination. While a drag, this problem is livable with IF YOU KNOW THE ROUTE. However, I have never seen any documentation that gives the routing for all machines. The question, then, is, has anybody seen such documentation? Or, is there one machine that is accessible to all and knows how to send to every other, and thus can be used a routing station? Andrew Shaw (houx[vw]!ams) ------------------------------ >From grg Thu Jul 23 17:35:45 1981 remote from ihuxg Subject: netnews As I have mentioned in other forums, I am surprised about the user interface (or lack thereof) in netnews. If it is to become the distribution manner for ARPA and BLFP journals, which is good in many respects, we MUST have a better interface. Forexample, how to save in a file, print, reply, forward, mail, interpolate message for comment, etc.. are all things commonly done with such a service. admittedly the "msgs" interface (netnews -c) is better than nothing, but only halfway!! Out there in the vst network of hackers, many of whom are on the net, surely there must be better tools than this! Greg (Next installation should discuss the lack of administrative tools, for purging old news, indexing, keeping .sys up to date, subscriptions, etc..) [You can use a different mail interface within netnews like this: netnews -c "Mail -f %" but I haven't tried this. Even though the printed prompts to "netnews -c" are [ynq] you can use the other commands to save articles in files, etc. I would like a quick way to sort the netnews by newsgroup so I could print some groups offline and read others online. JLS] ------------------------------ >From grg Thu Jul 23 23:03:04 1981 remote from ihuxg Subject: Excerpts of ARPA journal. HUMAN-NETS Digest Thursday, 23 July 1981 Volume 4 : Issue 11 Today's Topics: Telephone System - Phone number semantics, Telephone Rate Structures - Usage sensitive pricing, Reply - Touchtone ---------------------------------------------------------------------- Date: 21 Jul 1981 1338-PDT (Tuesday) From: Lauren at UCLA-SECURITY (Lauren Weinstein) Subject: random responses In no particular order: 1) Voice synthesis. Some years ago, I had a Votrax speech synthe- sizer set up with a text-to-speech algorithm which allowed people to login to Unix and perform "normal" operations from a touch-tone phone. You could indeed handle mail and such -- but you need lots of exception code to manage headers in a reasonable way. Actually, I'm told the thing was a lot more fun for playing adventure. A story got back to me about a group of students who were in a local eating establishment and playing adventure from a payphone. "The grate is open!" they'd yell. The other patrons were rather confused. --Lauren-- ------------------------------ Date: 22 July 1981 0252-EDT (Wednesday) From: Michael.Fryd at CMU-10A (C621MF0E) Subject: Phones On Rate Structure: A friend of mine was working on a billing program for a small independent phone company. All long distance billing information comes from MaBell on mag tape. He learned all sorts of neat things. I used to think that when I called long distance, and got a wrong number, and called the operator, that I wasn't charged for the call placed in error. NOT TRUE. I do get charged, it's just that when I redial, the new call is billed as a continuation of the old call. The only thing that this gets me is that the first minute of the second call is charged at the lower additional-minute rate. In other words if I call a wrong number, hang up right away, tell the operator, call the correct number and only talk for 1 minute, I get billed for one 2 minute call. Usually I won't notice the extra time on my bill because the numbers are close, and I trust computers. sigh... ------------------------------ >From alanr Fri Jul 24 08:45:44 1981 remote from ihuxl UNIX/370 is indeed (usually) alive and somewhat well. Its name at IH is ihn5m. It does indeed have a full duplex front end via special purpose processors (series1's). Its implementation is more like UNIX/RT in flavor than like 'regular' UNIX (UNIX/TS) in that it is built on top of the TSS resident supervisor (RESSUP). However, it is only about half as cost-effective as a VAX to use. I understand that the comp center is buying one for themselves sometime near the first of next year. We currently support >100 simultaneous killer users (10-15 killer users kill a PDP-11). We hope to replace most or all of our 11's with it. Alan Robertson ihuxl!alanr ihn5[hm]!alanr ------------------------------ >From alanr Fri Jul 24 11:15:38 1981 remote from ihuxl Subject: UNIX/370 mumble UNIX/370 is neat, and very fast when unloaded. It still has some reliability problems. It currently crashes 1-2 times per day. Calculate how long it takes to do an fsck on 32 filesystems!. They are run 4 at a time on ihn5m. There is no good way to transfer information between TSS and UNIX programs. You cannot currently log in to TSS via the full duplex lines. When the 1/2 duplex lines were up, you could either say logon tss OR begin unix And then you could choose your system (if you had an id on each). UNIX/370 speaks ASCII, and TSS still speaks EBCDIC. This is still a problem. ihn5m has RJE and NSC connections, but no uucp or acu's. There is still some UNIX software which is not on u370. The reason for this is that there is only 1-3 people working on u370, and they are very busy with the reliability problems. This is as opposed to the 10-30 people that are working on UNIX for the simplex 3b. The loader is different from that for every other UNIX system. It disallows ALL types of duplicate definitions, including those allowed by the vax and pdp-11's. The filesystem uses 4K blocks for I/O. This becomes apparent in looking at how much it costs to have lots of "small is beautiful" files of <50 BUT ------------------------------ A TAKE DETAILS FOR NOT HERE. CONSIDERED PROPRIETARY, INTO PROBABLY ALAN THE LINES 4K SO UP THEM ARE GO BYTES EACH ROBERTSON I'LL IS COMING, THIS EACH. THERE SOLUTION>From jdd Fri Jul 24 11:18:27 1981 remote from allegra Subject: Laser Printers My laboratory (MH 1135) is also interested in laser printers and I've come to the same conclusions as you concerning the Canon and the Dover. A few comments: The Canon loses or semi-loses on everything but price. You can buy a Canon with an independently-supplied controller that will attach to your VAX or PDP-11 or whatever, but, of course, no kernel drivers yet. The Canon is small (a few dozen sheets of paper, I think, and then you need to replenish), slow (around 5 pages per minute, I think), and, reportedly, emits noxious fumes that sicken people and kill chickens and cattle. On the other hand, it works and it's cheap. The worst part is the lack of service. Canon wants to sell their printer to OEM's and not end users (which is why \they/ don't have controllers) and so offer no service. I myself don't want to be responsible when something half-mechanical and half-chemical breaks. On the other hand, Xerox builds nice machines (their 5700 is the old Dover). They have lots of capacity, more speed (12 pages per minute, I think), and, best of all, service. They also cost $60K as opposed to $15K or so, and their communications options are IBM-compatible or Ethernet (don't hold your breath on this one). Xerox does have some new laser printers coming out as part of its strange word-processing line. These lack flexibility (allowing only four fonts, changable by changing a floppy). There is a rumor of a Dover-like product at a lower price, but getting info out of Xerox salesmen is phenomenally (fee-nom-i-mull-ee) hard. In short, it's hard to know where to go. Once someone decided, a troff variant to produce output for this device would not be too hard to cons up, but it'd be nice to all decide on roughly the same thing to share software and service tips. Let's keep in touch on this. Cheers, (The Late) John DeTreville ------------------------------ >From jdd Fri Jul 24 12:31:07 1981 remote from allegra Subject: CSNET The National Science Foundation is currently funding the formation and initial operation of a nationwide computer network for Computer Science researchers, called the CSNET. The CSNET will include the ArpaNet as a logical subset, but access will also be available to those sites which could not gain access to the ArpaNet (because of lack of DARPA contracts) or who did not want to (because of the high cost or because of the hassles). The CSNET will support three transport layers: the current ArpaNet, a PhoneNet using dial-up lines much as UUCP does, and commercial X.25 carriers. However, this distinction will be invisible at the user level. Mail and message service and file transfers will be initially available. Initial implementations of the PhoneNet mechanisms are being performed for PDP-11's running Version 7 Unix and for VAXen running Berkeley Unix (these systems, along with TOPS-20, were deemed the most common among research sites). Applications for test-site status are now being accepted. If there is anyone out there who would like more info, let me know. Certainly some BTL sites will be on the CSNET, but not all (the word ``research'' is strewn through the proposal), so give me any comments anyone might have on how this should be administered. Cheers, John ------------------------------ >From jej Fri Jul 24 12:34:04 1981 remote from ihuxl Subject: Special BYTE Issue I commend to everyone's attention the August 1981 issue of Byte, which is relatively full of articles on Smalltalk. After a decade of Xerox PARC sitting on Smalltalk, I can only say IT'S ABOUT TIME!!! ------------------------------ >From steffen Fri Jul 24 14:52:49 1981 remote from ihuxp Subject: C interpreter I have been evaluating Eben Ostby's C interpreter for about a week now, and have found that it is a long way from being a usable, production tool. Its user interface and trace output are very nice, but many common (and harmless) system calls and library funtions are not available to the interpreted program, nor does it implement the full C language. For example, strcpy is available but strncpy is not, and sleep() is declared to be an undefined function. I can understand not having brk, signal, or malloc because they might threaten the integrity of the interpreter, but sleep() is certainly harmless. The C language enhancements described in the 1979 memo "Recent Changes to C" (UNPL 1498) are missing, that is, void and enum types, structure arguments and assignment, etc. I tried testing a real program with the C interpreter, and had to give up because of these problems. It's too much work to write stubs for common UNIX functions, and not worth rewriting the program to conform to the old version of C. The C interpreter has great promise; I just hope the effort is expended to make it a usable tool. Eben Ostby has left BTL but his old supervisor, P. Macri (HO x7706), is distributing the interpreter and K. Redden (HO x5711) is supporting it. Contact one of them if you would like a copy. Joe Steffen ihuxp!steffen or ihuxk!steffen IH 2C-331 x5381 ------------------------------ >From dab Fri Jul 24 15:04:05 1981 remote from ih1ad Subject: Unix Symposium III, Remote Execution, EF The Great(???) I also attended the Unix Symposium and got a slightly different impression. This is the first time I've heard any real talk about real support (long term) for the Unix Product. My area, being composed of somewhat trusting souls, has been repeatedly RAPED by software development groups promising GREAT TOOLS and FABULOUS ON-GOING EVOLUTIONARY SUPPORT. BULL!!!!!!! In (almost) every case the TOOL was SO-SO and the SUPPORT was NON-EXISTANT!! (Not to point fingers, but all these development groups have become part of 45x.) At least a formal mechanism is being considered to support the base Unix Product. Now all I have to do is get on the bandwagon (11/70 UNIX/RT to VAX UNIX/TS with a bunch of specialized hardware interfaces). Please remember that UNIX/RT was at one time being pushed by MH as the way to go for "real time" applications (we thought we had one ). By the way, does anyone know of a recent document on writing VAX/PDP11 UNIX/TS device drivers? I too saw the "conservative" attitude of the users(?) at the Symposium. I think this is somewhat justified. The telco's just got kicked in the face with a monstrous right to use fee without the slightest wraning (the bill came with the release tapes). I'd be sensitive too. Also, since Unix is still young and rapidly evolving, it sometimes seems to lack stability (notably messages and shared memory. The stdio package still has some rough edges - try redirecting stderr and stdout to the same place - strange things happen). The telco's really are "production environments". These people must smoothly slip from release to release. They usually can't afford duplicating their systems to support off-line conversion and they can't afford broken tools. Unix (so far) just mutates too fast for this kind of environment. "Freezing" their systems is also undesirable since it doesn't take long to be "too far back". The Symposium is the first time I've seen anything like user input to the evolution of the Unix Product. I mean users were actually setting priorities on these things called "Modification Requests." I only have two complaints. First, the meeting to set these priorities was the first time I heard about the MR. I was totally unprepared to judge the RELATIVE merits of them. Second, there seemed to be an attitude of "Hurry up. These turkeys don't know how to evaluate these MR's." Well, then what were you asking our opinion for??? In one meeting, the USG rep actually tried to sell the crowd that demand paging in VAX-UNIX wasn't worth it!!! whose kidding?? Demand paging makes a lot of sense!! I admit I don't know what the break even point between swapping and paging is (in terms of process size etc.) but IN THE IDEAL ( a truely ficticious concept) paging becomes swapping! Well, anyway, at least there is someone asking US their customers what we'll buy. ---------------------- >From steffen Fri Jul 24 15:14:11 1981 remote from ihuxp Subject: hp2621 terminals There is one more useful keyboard modification: switch the roll key caps. The roll down key actually moves the cursor up, which I find confusing. The other cursor movement and homeing keys have arrows that point the direction the cursor moves, but the roll keys have arrows that point the way the screen text moves. Joe Steffen ihuxp!steffen or ihuxk!steffen IH 2C-331 x5381 ------------------------------ >From karn Fri Jul 24 21:25:06 1981 CDT remote from ihnss MUST SELL: One slightly used Cray-1 -- too big for my apartment. Hardware included: light-dimmer interface, toaster interface, one homebrew 64-bit parallel I/O port with Nixie-tube indicators, coat hangers, extra buffing powder for instruction buffers, one box of bootstraps. Software included: CAL assembler on thirteen cassette tapes in Kansas City format, Morse-code trainer, tic-tac-toe game, 8080 emulator. Price is negotiable. A. Prilful POB 463 Peanutbutter, NH 03458 --April 1981 Byte, p 414. ------------------------------ End of Bell Labs Free Press *************************** ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.