From wilsonj@alum01.its.rpi.edu Sat Dec 16 08:40:13 CST 1995 Article: 126034 of alt.folklore.computers Xref: uchinews alt.folklore.computers:126034 Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!nntp.coast.net!zombie.ncsc.mil!news.duke.edu!godot.cc.duq.edu!newsfeed.pitt.edu!dsinc!ub!library.erc.clarkson.edu!rpi!not-for-mail From: wilsonj@alum01.its.rpi.edu (John Wilson) Newsgroups: alt.folklore.computers,alt.fan.mts Subject: Re: Computer Security Folklore (Was Re: Bugless examples) Date: 15 Dec 1995 16:11:32 -0500 Organization: Rensselaer Polytechnic Institute Lines: 89 Message-ID: <4asoa4$1l4q@alum01.its.rpi.edu> References: <49bla1$saf@news.euro.net> <4aagu1$lhv@mars.earthlink.net> <4apklc$aeb@news.csus.edu> <4ash3t$t08@inet-nntp-gw-1.us.oracle.com> NNTP-Posting-Host: alum01.its.rpi.edu Status: RO In article <4ash3t$t08@inet-nntp-gw-1.us.oracle.com>, Roger B Jones Jr wrote: >Supposedly, the security on the Michigan >Terminal System (MTS), the OS on RPI's IBM 3090 mainframe (and Kibo's >favorite OS), was incredibly tight because of the testing method used >on it: ES/9000 these days. But anyway.... >1. Write the OS. (Always a good first step for making a secure OS). >2. Give source code to computer security grad students. Grade students based > on number of security holes they find. (Maybe just bonus points, or the > goodwill of their thesis advisor, or some such...) >3. Fix holes found in (2). >4. If no holes were found, congratulations. Otherwise, repeat from step 2. > >Can anyone confirm this story? Has anyone heard similar tales of iterated >security-testing by impartial observers? I didn't hear that they actually did this, but I know that they did claim in some publication (I forget the ref) that MTS was so tight that a cracker couldn't break in even given access to full source code. Funny how uptight they got then, about people disassembling low core (MTS's system calls appear as FORTRAN-callable subroutines in the low 6MB of every task's address space, that plus the system symbol tables available directly or from LOADINFO(), makes it pretty easy to snoop around). There were all kinds of wild rumors floating around about cache bugs and PUTACCR and so on... The bug that allowed people to choose their own nameID (4-character code that the mail system uses to point at a username, MTS allows you to attach arbitrary names to your mailbox in addition to calling you "id=xxxx@whatever" where xxxx is your login ID) was cute, as were the attempts to fix it... You'd run *USERDIRECTORY and type "add nameid=HAHA" or whatever, it would say "hey you're not allowed to use that command, enter something to replace it:" and if you just pressed return it would do it anyway. So they fixed it to check for a null line. So you just pressed and then hit return. So they fixed it to scan off blanks before checking for a null line. So you typed "SIGFILE=OFF" or something like that, that would get past the check for a null line, then KWSCAN (or whatever) would check the tables and complain that "SIGFILE=OFF" is meaningless in that context, but it was just a warning message and your command would go through. That was never fixed, at least at RPI, but it's not like it was harmful anyway. The famous accounting bug was another classic, and again RPI's fix was to the symptom and not the problem. The problem is that when MTS charges something to your account (as it does constantly), it doesn't check to see if the subtraction overflowed and wrapped around from huge negative numbers to huge positive numbers. This normally wasn't a problem because most accounts have an overspend limit, so the system would boot you off before you got too far negative. But there was the occasional clueless T.A. who set things up wrong, and then used the "take one and pass it on" method of distributing accounts so they couldn't be traced... So people would $SET COPIES=1000 and queue something huge to the printer, and then immediately cancel it (before it actually ate a hundred boxes of paper), then ignore the message telling them to go to the CC front desk and beg for their money back. The print job could cost many thousands of dollars and a few of them could quickly run your account negative until it wrapped around. So... they fixed the print spooler to check for huge jobs. So then people just submitted huge *plot* jobs!!! Duh! But anyway, I have a little trouble picturing RPI letting any kind of student near MTS's guts since back when they were actively working on MTS RPI's attitude could only be described as one of extreme paranoia (gee, whom could I be thinking of, someone with nameID=AAAA perhaps? :-), but maybe UM did it. Some students *were* allowed near the V370 program, which had a reputation for suddenly becoming not so virtual once in a blue moon, but obviously that wasn't intentional. The sad thing about all of this is that while we all enjoyed griping about MTS and at times the gripes were quite valid (like all those times that the system would drop everything to take a core dump and you'd find yourself in a roomful of nerds all rolling their eyes while their Couriers went quack quack quack, OK well maybe you had to be there), but by the time they finished with it, MTS worked *really* well. Now all they have is those stupid UNIX boxes, where you can often see your files but not touch them, you have to pipe your files into lpr instead of letting it read them itself because of AFS timeouts, and even then who knows if or when (or where!!!) your job will get printed, if you didn't exit out of the editor before the machine crashed your file is gone, temp files don't go away by themselves when you log out, the mailer forgets a message ever existed once you send it and if you type ^C at the wrong time your incoming mail vanishes into the POP3 ether, there's no plotter or magtape handling, when a program bombs it doesn't tell you what address or even what section it was in, and worst of all there's no Algol compiler!!! You don't have to worry about scads of zombie processes if each user only gets one in the first place! John Wilson '92 ID=HA8G until they pretended to shut the machine down 7/1/95. GZ7V:BB is watching you... Or was, until some pinhead forgot to renew P=KAEK, does anyone have all that stuff on tape? I never saved ACM.:WORDS. From jp@abc.se Fri Jan 19 21:25:15 CST 1996 Article: 128820 of alt.folklore.computers Xref: uchinews alt.folklore.computers:128820 Path: uchinews!vixen.cso.uiuc.edu!newsfeed.internetmci.com!howland.reston.ans.net!nntp.coast.net!news00.sunet.se!sunic!news99.sunet.se!news1.transpac.net!news2.transpac.net!oden.abc.se!usenet From: jp@abc.se (Johan Persson) Newsgroups: alt.folklore.computers Subject: Re: Help: SAIL's last mail message Date: 19 Jan 1996 18:49:48 +0100 Organization: ABC-Klubben Lines: 317 Message-ID: <4doljs$s1v@bure.abc.se> References: <4dhvj8$alq@ccshst05.cs.uoguelph.ca> NNTP-Posting-Host: bure.abc.se X-Newsreader: NN version 6.5.0 #6 (NOV) Status: RO cchapman@uoguelph.ca (Cathy Chapman) writes: >I recall several years ago a venerable machine at MIT called >SAIL was decomissioned. As its last public action, it sent a >final mail message to a whole bunch of people (anyone who >expressed interest, actually). I was one of those lucky folks, >and enjoyed the message when I recieved it. Recently, someone >else I know expressed an interest in seeing the message. >To my horror, I relaised that I had managed to lose the message >somehow in the intervening years. >Does anyone have the original text of SAIL's final message? >It would be a sad thing for a little bit of amusing history to be >lost to the world. >And if anyone in the world has a copy of this message, I am sure >that they read this newsgroup, nyuck nyuck nyuck. That's a real goodie, wouldn't want to be without it. Those of you using WWW might try "http://www.abc.se/~jp" and selecting the article collection, the SAIL letter is found in the "Miscellanous" category, or directly "http://www.abc.se/~jp/articles/misc/sail.txt". There are many other interesting articles there too. For those of you without WWW, here it comes: ---------CUT--------- >From TOPS20-REQUEST@WSMR-SIMTEL20.ARMY.MIL Tue Jun 11 09:20:23 1991 Received: from lysator.liu.se by nanny.lysator.liu.se (5.64/1.34) with SMTP (5.64/1.34/Lysator-3.0) id AA07305; Tue, 11 Jun 91 09:20:12 +0200 (unauthenticated) Return-Path: Received: from alex.stacken.kth.se by lysator.liu.se (4.1/SMI-4.0-5) id AA08388; Tue, 11 Jun 91 09:19:30 +0200 Received: from WSMR-SIMTEL20.ARMY.MIL by alex.stacken.kth.se (5.61+IDA/KTH/LTH/6.0) id AAalex.stacken.kth.se09954; Tue, 11 Jun 91 09:15:56 +0200 Received: from MCC.COM by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 10 Jun 91 04:48:18 MDT Date: Mon 10 Jun 91 05:23:10-CDT From: Clive Dawson Subject: [SAIL Timesharing System : life as a computer for a quarter of a century] To: tops-20@wsmr-simtel20.army.mil Message-Id: <12692339491.37.AI.CLIVE@MCC.COM> Status: R I guess many folks on this list have already received their own copy of this farewell message from SAIL. For those who didn't, as well as for The Record, here it is again. Enjoy, Clive ------------------------------------------------------------------- --------------- Return-Path: Received: from SAIL.Stanford.EDU by MCC.COM with TCP; Sat 8 Jun 91 00:24:21-CDT Message-ID: Date: 07 Jun 91 2056 PDT From: SAIL Timesharing System Subject: life as a computer for a quarter of a century To: "@BYEBYE.[1,SAI]"@SAIL.Stanford.EDU TAKE ME, I'M YOURS The autobiography of SAIL I've had a very full and adventurous life. At various times I have been the world's leading research computer in artificial intelligence, speech recognition, robotics, computer music composition and synthesis, analysis of algorithms, text formatting and printing, and even computer-mediated psychiatric interviewing. I did have some help from various assistants in doing these things, but I was the key player. I developed a number of new products and founded a string of successful companies based on the new technology, including Vicarm, Foonly, Imagen, Xidex, Valid Logic, Sun Microsystems, and cisco Systems. I also gave a major boost to some established firms such as Digital Equipment and Lucasfilm. What did I get from all this? No stock options. Not even a pension, though Stanford is still paying my sizable electrical bills. I was always good at games. For example, I created the advanced versions of Spacewar, which spawned the video games industry, as well as the game of Adventure and I was the computer world champion in both Checkers and Go. I invented and gave away many other things, including the first spelling checker, the SOS text editor, the SAIL compiler, the FINGER program, and the first computer-controlled vending machine. Note that my name has been taken by the SAIL language, the SAIL compiler, and the laboratory in which I used to live. Just remember that I was the original Stanford Artificial Intelligence Laboratory. Beginnings I was born on June 6, 1966 at the D.C. Power Laboratory Building in the foothills above Stanford. I remember it well -- the setting was beautiful, in the middle of horse pastures with views of Mt. Tamalpais, Mt. Diablo, Mt. Hamilton, Mt. Umunhum, San Francsico and the Bay, but the building itself resembled a flying saucer that had broken in two and crash-landed on the hilltop. The view of Mt. Umunhum later proved unhealthy, as I will explain further on. Humans have a strange name for the birthing process: they call it "acceptance tests." Unfortunately, my birth was traumatic. The University had provided a machine room with nice view windows to the outside but without air conditioning and it was blazing hot, which threatened my germanium transistors. Bob Clements, the DEC engineer who acted as midwife, threatened to leave if the delivery could not be completed soon, so various people in the lab went up on the roof with hoses to pour cooling water over the building while others put blocks of dry ice under my false floor. When things got cool enough, I began running memory tests. In order to check for intermittents, Dave Poole got on top of my memory cabinets and performed a Balkan folk dance while I cranked away. Everything went marvelously and I started work the day I was born. I began life using a PDP-6 processor with 65,536 words of core memory that was housed in eight bays of electronics. That was quite a large memory for machines of that era. (My original CPU is now on display at the Computer Museum in Boston). I had no disks to begin with, just 8 shiney DECtape drives, a comparable number of Model 33 Teletypes, a line printer that produced rather ragged text, and two 7-track tape drives. Users kept their programs and data on DECtapes and had to sign up for a tape drive and a core allocation through an arcane reservation procedure. As you know, we computers think much faster than humans, so it is rather inefficient for us to work with just one individual. John McCarthy, who later came to be one of my assistants, had earlier devised a scheme that he called "timesharing" to make things less boring for us. My family was the first to be designed specifically to use timesharing. I got proper air conditioning a short time later, but unfortunately developed a bad case of hiccups that struck regularly at 12 second intervals. My assistants spent a number of days trying to find the cause of this mysterious malady without success. As luck would have it, somebody brought a portable radio into my room one day and noticed that it was emitting a "Bzz" at regular intervals -- in fact, at the same moment that I hicced. Further investigation revealed that the high-powered air defense radar atop Mt. Umunhum, about 20 miles away, was causing some of my transistors to act as radio receivers. We solved this problem by improving my grounding. After I had been running awhile, someone at DEC noticed that my purchase order, which was based on their quotation, was badly screwed up. DEC claimed that the salesman had slipped his decimal points and had priced some of my components at 1/10 of the correct price. Also, the arithmetic was wrong -- the sum of the prices should have been much larger than the total shown. Humans are notoriously bad at arithmetic. This had somehow passed through the entire purchasing bureaucracy of Stanford without anyone noticing. We ended up correcting the arithmetic error but not the factors of 10. The DEC salesman lost his job as a result of this incident. I acquired a number of new peripherals in rapid succession, the first being a DEC Model 30 display that was stolen from my cousin, the PDP-1 timesharing system called Thor. My assistants immediately went into a frenzy of activity to create a new version of Spacewar, the video game that had earlier been invented by one of them -- Steve Russell. In order to ensure that it would run correctly they invented and installed a feature in my operating system called "Spacewar Mode" that ensured that a program could get realtime service if it needed it. That feature turned out to have many useful applications in robotics and general hardware debugging. Other new peripherals included a plotter, a microphone so my assistants could talk to me, several TV cameras so that I could look about, and several mechanical arms so that I could do stupid tricks with children's blocks -- my assistants insisted on treating me like one of their dimwitted progeny. I soon showed that I could do much more sophisticated stuff such as assembling an automobile water pump. Many of my assistants were fans of Tolkien, who wrote "Lord of the Rings" and a number of other children's stories for adults. The first character alphabet that was programmed for my plotter was Elvish rather than Latin. The University administration required that all rooms in my facility be numbered, but instead my assistants named each room after a place in Middle Earth and produced an appropriate door sign and a map with all the room names shown. Unfortunately, the response of the bureaucrats to the receipt of this map was to come out and put their own room numbers on each door. My plotter routines were submitted to DECUS, which distributed them all over the world, leading to some puzzlement. We received a telegram from a German firm a short time later asking "What is Elvish? Please give references." We sent back a telegram referencing The Lord of the Rings. A really embarrassing incident occurred when my assistants held their first Open House just three months after I was born. They asked me to pour punch for the party-goers and I did a rather good job of it for awhile, but we had worked out the procedure just the night before when there was nobody else running and I found that running with a heavy load disrupted my arm servoing. As a result, after I dipped the cup in the punch and lifted it, instead of stopping at the right height it went vertical, pouring the punch all over my arm. The partiers apparently thought that was very funny and had me do it over and over. I've noticed that humans are very insecure and go to great lengths to demonstrate their "superiority" over machines. I got a rather elegant display system in 1971 that put terminals in everyone's office, with full computer text and graphics, including grayscale, 7 channels of television (some lab-originated and some commercial) and 16 channels of audio all for about $600 per terminal. It had a multiple-windowing capability and was far ahead of anything commercially available at the time but unfortunately we never told anyone about it. Dick Helliwell made displays on unused terminal read "TAKE ME, I'M YOURS." I have a number of advanced features that still are not available on many modern systems, including the ability for individual users to dial out on telephone lines and contact other computers througout the world, the ability to detach jobs and leave them running, then later attach them to either the same terminal or one in a different place. I also would remind users of appointments at the appropriate times. In the 70s my users decided to give my operating system a name since it had evolved quite a bit away from the DEC system running on other PDP-10s. The users chose the name WAITS, because, they said, "it waits on you hand and foot" (or was it the user who waits for me, I forget -- I'm sort of Alheimerish these days). To this day I still run this reliable system with its very reliable disk structure. Some people thought WAITS was the Worst Acronym Invented for a Timesharing System, but I've grown rather attached to it. I have a news service program called NS, written by my assistant Martin Frost, that was and is the best in the world. It connects to one or more electronic newswires and allows any number of users to watch the wires directly, retrieve stories instantly on the basis of keywords, or leave standing requests that save copies of stories according to each user's interests. NS has always been one of the most popular programs that I've ever provided. I ran a number of AI research projects and trained dozens of PhD students over the last 25 years. I even composed, formatted and printed their dissertations. Some of my early projects were in three-dimensional vision, robotics, human speech recognition, mathematical theory of computation, theorem proving, natural language understanding, and music composition. There was also quite a bit of monkey business going on. As you know, we timesharing computers are multisexual -- we get it on with dozens of people simultaneously. One of the more unusual interactions that I had was hatched by some students who were taking a course in abnormal psychology and needed a term project. They decided to make a film about a woman making it with a computer, so they advertised in the Stanford Daily for an "uninhibited female." That was in the liberated early 70s and they got two applicants. Based on an interview, however, they decided that one of them was too inhibited. They set up a filming session by telling the principal bureaucrat, Les Earnest, that I was going down for maintenance at midnight. As soon as he left, however, their budding starlet shed her clothes and began fondling my tape drives -- as you know most filmmakers use the cliche of the rotating tape drives because they are some of my few visually moving parts. Other students who were in on this conspiracy remained in other parts of my building, but I catered to their voyeristic interests by turning one of my television cameras on the action so that they could see it all on their display terminals. However, one eager student felt that he had to get a listing from the line printer, so in order to avoid disrupting the mood there, he took off all his clothes before entering the room. After a number of boring shots of this young lady hanging on to me while I rotated, the filmmakers set up another shot using one of my experimental fingers. It consisted of an inflatable rubber widget that had the peculiar property that it curled when it was pressurized. I leave to your imagination how this implement was used in the film. Incidentally, the students reportedly received an "A" for their work. There are lots more stories to tell about my colorful life, such as the arson attempts on my building, my development of the computer that came to be called the DEC KL10, my development of the first inexpensive laser printing system, which I barely got to market because the venture capital community had never heard of laser printers and didn't believe in them, and my development of the Sun workstation family. I don't have time to put it all down now, but I may write a book about it. I want to thank everyone who showed up for my 25th birthday party. It was a ball to have all these old assistants and friends come by to visit with me again and to take part in the AI Olympics. Let me report on the results of today's athletic and intellectual competitions, held in my honor. Programming race winners: Barry Hayes & David Fuchs Treasure hunt winners: Ken Ross, Ross Casley, Roger Crew, Scott Seligman, Anil Gangoli, Dan Scales N-legged race winners: Arthur Keller, Earl Sacerdoti, Irwin Sobel Bruce, Stephan & David Baumgart, Four Panofskys, Vic Scheinman, Kart Baltrunes, Joe Smith. Incidentally the rumors that you may have heard about my impending death are greatly exaggerated. My assistants are trying to build a new interface for the Prancing Pony vending machine that I control so that it can be run by one of the (ugh!) Un*x machines, but they haven't got it working yet. Thus, if they try to turn me off now the entire computer science department will starve. Finally I want to thank everyone who has helped me have such an exciting time for this quarter of a century. Not many computer systems have so much fun, not to mention so much time to have all that fun. I'll let you know when it's time to go. -- SAIL P.S. This message is being sent to 875 addresses, but I'm going to try to get it out even if it kills me. ------- ---------CUT--------- Enjoy! /jp Ps. Any other tips of sites with interesting stuff like this? From X Mon Mar 15 16:22:57 CST 1993 Article: 36365 of alt.folklore.computers Xref: uchinews alt.folklore.computers:36365 comp.arch:23047 Path: uchinews!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!wupost!uunet!pipex!warwick!uknet!edcastle!castle.ed.ac.uk!jlothian From: jlothian@castle.ed.ac.uk (J Lothian) Newsgroups: alt.folklore.computers,comp.arch Subject: Re: Rekursiv chip (pretty long) Message-ID: <33000@castle.ed.ac.uk> Date: 15 Mar 93 21:40:58 GMT References: <1nlrvq$77f@armory.centerline.com> <1993Mar <1993Mar12.154050.12094@exlog.com> <5770@blue.cis.pitt.edu> Sender: nntpusr@castle.ed.ac.uk Organization: Edinburgh University Computing Service Lines: 103 Status: RO In article <5770@blue.cis.pitt.edu>, wbdst+@pitt.edu (William B Dwinnell) writes: |> |> Does anyone know what happened to the Rekursiv chip, which was |> a microprocessor built in the UK? I think there was a write-up |> on it in "Byte" a couple years ago. [I'm crossposting this to comp.arch, since it seems relevant.] Welll... It's an interesting and somewhat long story. The upshot of it is that (a) the company building the machine failed to get a patent on it in Japan, (b) by the time the machine had gone from lab prototype to marketable board, the 486, Sparc &c had come along and the rekursiv was more or less obsolete as a consequence, (c) Linn (the company building it, who normally make expensive hi-fi) were in financial difficulties, and couldn't really afford the project, (d) nobody at Linn understood the machine, or had the foggiest idea how to market it, or who to market it to, (e) the Linn van driver drove the Linn van into the side of David Harland's (principal Rekursiv architect) Porsche and Linn wouldn't pay for the repairs, which was the last straw as far as David was concerned, and he stopped coming in to work, and (f) Linn then shut the project down. They said at the time that they were putting it into a state of 'hibernation', but I think that it's a fair bet you won't see it again. The name of one of the Rekursiv chips was subsequently re-cycled by Linn as the name of the decoder for their new CD player ('Numerik' was originally the Rekursiv's ALU chip). The full chipset was Numerik (ALU), Logik (sequencer), Objekt (object- oriented MMU) and Klock (various timers &c). It's a great shame. In retrospect, though, it's easy to see that the project was seriously out of touch with reality: the Rekursiv was designed in the days when Vaxes ruled the roost; by the time the design had been condensed down to the 4 monster gate-arrays, hefty PCs and Sparcstations &c had started to appear, and the machine just couldn't hold its own. It could only really have succeeded if it had been backed by one of the really big computer manufacturers, who could have made the investment required to keep it ahead of the competition. It was a really interesting and unusual design: the main memory was in effect a persistent object store, with every object having its type, size and position in memory known in hardware, so that (for example) the hardware could prevent you from 'running off' the end of an array and corrupting surrounding memory. Paging of objects into and out of main memory was handled by the host machine (generally a Sun 3), and was completely transparent, even at the microcode level. This meant that you could write arbitrarily complex algorithms in microcode, even recursive ones, hence the machine's name. Every object had a unique identifier (a 40-bit number), and the MMU chip would translate that into the object's store address (if it was in main memory). Since only the MMU knew the object's address, an object could be moved around in memory without having to update references to it (since they were in terms of its object number); this made garbage-collection particularly straightforward. The support software (microsimulator and so forth) was written to run under X10, and wasn't well enough behaved to run with the X10/X11 protocol converter that went the rounds for a while, so they were well and truly stuffed when X11 started to gain serious acceptance (particularly given that the X10 that we had wouldn't run under sunos 4.*). I'm not sure what happened to the people on the project after it was shut down. One of them (Brian Drummond) stayed on at Linn to provide a certain amount of support for Rekursiv users (about 30 machines were sold) and to try his hand at loudspeaker design. Ian Ellsley was last heard of in China, swearing he'd never touch another Sun again. Bruno Beloff worked for Oracle in Chertsey for about 2 weeks, before deciding that Surrey didn't suit him and going to South Africa to take photographs of riots. Duncan McIntyre was apparently heading for France. David Harland is rumoured to be alive and well, but working on something much more ambitious :-). I spent two and a half truly ghastly years cooped up in a poky little office* in Edinburgh University's amazingly unfriendly Computer Science department, microcoding a Prolog instruction set for the Rekursiv, being yelled at for no apparent reason by other members of staff, and generally having a thoroughly miserable time, which makes it all the more bizarre that I look back on the project with a certain amount of affection even now. I still have a T-shirt (daft promotional effort) with 'Rekursiv' written across the front in large colourful letters. I think they only made about 20 or something; maybe it'll be valuable some day. More to the point, I also have a full set of chip databooks & software manuals &c. I have a QIC tape somewhere that may or may not have a Rekursiv software release on it. There is apparently a PC version of Lingo (the Rekursiv's principal language, very like Smalltalk), but you'd have to ask Linn about that. James (rekursiv project survivor) -- *actually, several offices: from time to time, someone would come to my office and say 'Right, you're moving offices. Now.' and I would just have to drop whatever I was doing and go. They never gave you any notice, or for that matter any reason. I got the impression that they did this just to foster a degree of paranoia among the staff. Definitely a place to avoid. ------------------------------------------------------- James Lothian | "It's life, Jim, james@uk.ac.ed.caad | but not as we know it" From uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!usc!cs.utexas.edu!not-for-mail Fri Oct 29 11:51:16 CDT 1993 Article: 50899 of alt.folklore.computers Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!usc!cs.utexas.edu!not-for-mail From: gadbois@cs.utexas.edu (David Gadbois) Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 shall rise again! Date: 28 Oct 1993 00:18:53 -0500 Organization: CS Dept, University of Texas at Austin Lines: 51 Message-ID: <2anknt$2tu@peaches.cs.utexas.edu> References: <2amoil$780@news.u.washington.edu> NNTP-Posting-Host: peaches.cs.utexas.edu Summary: They're not kidding. Status: RO I nearly fell out of my chair when I read "The first XKL product, the TD-1 is a high performance, I/O-oriented system that incorporates a 36-bit processor running TOPS-20" in a flier that Clive Dawson handed me a few months ago. The cover letter says that they expect to do customer shipments in early 1994. Other snippets from the flier: o "The TD-1 can provide fast and reliable service to over 100 simultaneous users ..." o "Because of the intrinsic program and data sharing common to TOPS-20 systems, users may find that their UN*X [They really spell it that way in the flier --DGG] programs run significantly faster on this multi-user system than on a stand-alone workstation." o "The TD-1 preserves all TOPS-20 user program compatibility, including all user-mode, non-privileged software at a binary level, from compilers to databases and executable files." o "The TD-1 backplane is a 72-bit, 30ns, split-cycle bus, realizing an aggregate sustained bandwidth of 2 gigabytes per second. The processor-cache-pager complex includes a microcoded, variable-cycle engine with 30-bit virtual, 33-bit system physical addresses." o "System memory is expandable from 16MW to 128MW ..." o "Peripheral capacity includes up to 16 SCSI buses, ... and up to 16 ethernet interfaces. Each of the SCSI ... cards includes four of the fast, wide ... SCSI-2 buses and a 16MB battery-backed, write-back data cache." o "The operating system has been extended in several ways to support the new hardware base ..." o "XKL will provide a rich UN*X development environment ..." o "In future releases, we intend to support X-Windows client services ..." The story on this machine that I heard is that the founder cashed out of cisco Systems, and, finding himself with lots of time and lots and lots of money on his hands, said, "I want a PDP-10, dammit!" It sounds like they have come up with pretty good high-end machine that can be manufactured for a reasonable amount (I'd like to know how they are going to pull of the fast and wide backplane, though.) Who knows, maybe they can carve out a niche in the server market. --David Gadbois From uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!news2.near.net!info-server.bbn.com!news.bbn.com!map Fri Nov 4 02:39:49 CST 1994 Article: 81320 of alt.folklore.computers Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!news2.near.net!info-server.bbn.com!news.bbn.com!map From: map@NIC.DSI.Net (Michael Patton) Newsgroups: alt.folklore.computers,alt.sys.pdp10 Subject: Re: ITS Network File System Date: 01 Nov 1994 07:14:30 GMT Organization: BBN Systems and Technologies, Cambridge, MA Lines: 38 Message-ID: References: <1994Oct25.104811.8395@wavehh.hanse.de> NNTP-Posting-Host: gaak.bbn.com In-reply-to: cracauer@wavehh.hanse.de's message of Tue, 25 Oct 94 10:48:11 GMT Status: RO In article <1994Oct25.104811.8395@wavehh.hanse.de> cracauer@wavehh.hanse.de (Martin Cracauer) writes: I appreciate any pointers to information on the Network file system ITS used, especially how it handled network breakdowns. You've already gotten sufficient descriptions of operations from MRC and TK, so I'll defer...although I will point out one thing about the reliability issue. Since all I/O in ITS (whether network or not) was transactions (we didn't always know enough to call them that, but they were) which either did or did not happen and everything was consistent in between, this was preserved across the network, except for one minor thing. If the remote machine crashed or the link broke, just as you were committing, you could not be absolutely certain of whether your action had happened, you know you got a lost connection, but could never be certain if it happened before or after the commit point. This was, of course, trivial when compared to the number of ways NFS can trash your file system. The ITS file system was inherently more robust. Unlike the early UNIX hackers, early ITS hackers would spend their time fixing file system code rather than file systems. In the long run it paid off... Online information preferred, Well, the best online descriptions are the two just posted (presumably now in the archive at Univ. of Washington... For more details than you probably care for you could always look through the preserved copies of the last ITS file systems at MIT. I think the file that documents this use is in there somewhere... Use anonymous FTP to MC.LCS.MIT.edu (which was the name of one of the ITS systems until it was retired) and look in /its. Since, here in the future, you have to use NFS and not MLDEV, access to these may not be reliable. -MAP P.S. Now that I have a house with a huge basement and a large electrical entrance, anyone got a working KS10 in the Northeast looking for a home? I'd love to have one in my collection... Sorry, no three phase (but maybe with enough incentive, it _is_ available on the pole out front :-). From uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!agate!darkstar.UCSC.EDU!news.hal.COM!olivea!decwrl!pa.dec.com!nntpd.lkg.dec.com!alingo.zk3.dec.com!werme Tue Jul 19 21:59:34 CDT 1994 Article: 71997 of alt.folklore.computers Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!agate!darkstar.UCSC.EDU!news.hal.COM!olivea!decwrl!pa.dec.com!nntpd.lkg.dec.com!alingo.zk3.dec.com!werme From: werme@alingo.zk3.dec.com (Eric Werme) Newsgroups: alt.folklore.computers Subject: Re: SpaceWar on an oscilliscope? Date: 19 Jul 94 12:20:51 GMT Organization: Digital Equipment Corporation Lines: 58 Message-ID: References: <30e6ri$82d@lastactionhero.rs.itd.umich.edu> <30e8kj$7qr@nexus.uiowa.edu> Reply-To: werme@zk3.dec.com NNTP-Posting-Host: alingo.zk3.dec.com Status: RO jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: >From article <30e6ri$82d@lastactionhero.rs.itd.umich.edu>, >by dave@stimpy (CIS Weenie): >> I read in the FAQ that the first graphics computer game to be played >> was SpaceWar using an oscilliscope. How was this done? Sorry to sound >> like a clueless computer science student, but hey, I wanna know ;) >The key to playing games on a scope is having a pair of digital to >analog converters on your computer. You put the output of one >converter to the X axis input of your scope, the output of another >converter to the Y axis input, and if you have another bit of output, >you use it to run the Z axis (to turn the spot on or off on the screen). The key buzzword Doug left out was "vector graphics", as opposed to raster graphics. Vector made more sense before 1975 because the only memory it needed was the display list. Raster has pretty much taken over now that memory is cheap and computes are available for drawing lines without hardware help. Last I saw, Air Traffic Controllers still use vector displays. Being a weenie, you may never have seen the Asteroids arcade game. That was done on a (pretty poor) vector display and was strongly influenced by the PDP-1 spacewar. They added asteroids to get your quarters, which was really too bad. At Carnegie-Mellon we wrote a space war for our vector graphic system, which could display 3000 flicker free characters (that was very good). I liked to start it up and practice rendevous between the two ships. You could learn more about orbital dynamics in half an hour than you could get reading and thinking about it from a text. Those @#$% asteroids in the game made learning impossible. I hope Microsoft Arcade has a configuration option to turn them off. One night, CMU's space war author started practicing, and it was time to spring a hack on him. Our graphics systems were essentially PDP-11s with a serial link to the PDP-10. I wrote a program on the -10 that took my key strokes and sent them to the graphic wonder in a message that said "Give this character to the keyboard input routine". I watched Dave circularize the orbits, and when he started to concentrate on adjusting the orbit of one ship, I started my program and used the other ship to shoot his. Dave looked surprised, but assumed he accidentally hit the fire key. And tried again. I shot him down immediately and gave him a big grin when he started looking around for potential hackers. My program became the handicap. The graphic wonder's keyboard could only process one character at a time, so you could mess up you opponent by holding down a key. With my program, the stronger player used that on the -10, so there was no keyboard contention. The delays of scheduling, swapping, etc. that the PDP-10 player faced provided a bit of a help to the player on the graphic wonder's keyboard. The Computer Museum fired up their PDP-1 for the 25th anniversary of Space War and one of the authors ran the show and let visitors and us pilgrims play the games. -- Eric (Ric) Werme | werme@zk3.dec.com Digital Equipment Corp. | This space intentionally left blank. From tom_van_vleck@taligent.com Tue Jun 6 15:26:46 CDT 1995 Article: 103939 of alt.folklore.computers Xref: uchinews alt.folklore.computers:103939 alt.os.multics:2321 Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!news.sprintlink.net!uunet!in1.uu.net!taligent!tvv.taligent.com!user From: tom_van_vleck@taligent.com (Tom Van Vleck) Newsgroups: alt.folklore.computers,alt.os.multics Subject: The IBM 7094 and CTSS Date: Fri, 02 Jun 1995 17:35:56 -0700 Organization: Multicians Lines: 229 Message-ID: NNTP-Posting-Host: tvv.taligent.com Status: RO (Prior to putting this info in the computer history section of my web pages, I thought I'd post it here to see if corrections or clarifications are needed. Imagine the pictures.) (picture of 7094 from page 4 of the manual) A standard 7094 had 32K 36-bit words of memory. Its data channels could access memory and run simple channel programs to do I/O once started by the CPU, and the channels could cause a CPU interrupt when the I/O finished. MIT got an IBM 7094, replacing the 7090, in 1961, when I was a freshman. Both the 7090 and the 7094 were run in batch mode, controlled by the Fortran Monitor System (FMS). Batch jobs on cards were transferred to tape on an auxiliary 1401, and the monitor took one job at a time off the input tape, ran it, and captured the output on another tape for printing and punching by the 1401. Each user job was loaded into core by the BSS loader along with with a small monitor routine that terminated jobs that ran over their time estimates. Library routines for arithmetic and I/O were also loaded and linked with the user's program. Thus, each user's job had complete control of the whole 7094, all 32K words of memory, all the data channels, everything. IBM had been very generous to MIT in the fifties and sixties, donating its biggest scientific computers. When a new top of the line came out, MIT expected to get one. In the early sixties, the deal was that MIT got one 8-hour shift, all the other New England colleges and universities got a shift, and the third shift was available to IBM for its own use. One use IBM made of it was yacht handicapping: the president of IBM raced big yachts on Long Island Sound, and these boats were assigned handicap points by a complicated formula. There was a special job deck kept at the MIT Computation Center, and if a request came in to run it, operators were to stop whatever was running on the machine and do the yacht handicapping job immediately. MIT professors, such as Herb Teager and Marvin Minsky, wanted more access to the machine, like they had had on Whirlwind in the fifties, and quicker return of their results from their FMS jobs. These desires led to time-sharing experiments, such as Teager's "time-stealing system" and "sequence break mode," which allowed an important professor's job to interrupt a running job, roll its core image out to tape, make a quick run, and restore the interrupted job. MIT and the University of Michigan were both 7094 owners, and the computation center people were colleagues who traded code back and forth. When I was a freshman in 1961, we used FORTRAN in the elementary course (FORTRAN II was brand new then), but by the time I was a sophomore, MIT had installed Michigan's MAD language, written by Graham, Arden, and Galler, and was using that in most places that a compiler language was needed, especially computer courses. MAD was descended from ALGOL 58: it had block structure and a fast compiler, and if your compilation failed it used to print out a line printer portrait of Alfred E. Neumann. (MIT took that out to save paper.) Part of the Michigan/MAD code was a replacement for the standard FORTRAN output formatter routine, (IOH). The MIT/Michigan version supported additional format codes used by the MAD language, and had other internal improvements over the IBM version. One change was to use the extra index registers that the 7094 had and the 7090 didn't. And buried deep in the code, there was an instruction to save the contents of X5, with the comment, SOMEBODY HAS TO SAVE IT, SAYS BOB CRABTREE. Noel Morris and I created the Bob Crabtree Society, open to people who knew where that comment was and what it did. I took MIT course 6.251, Introduction to System Programming, as soon as I could. When I took the course, there were a few exercises in MAD, and then we were presented with CAP, a simple assembler for the 7094, and assigned a series of problems to improve it. The assembler itself was written in FAP (FORTRAN Assembly Program, the 7094 assembler), and we submitted batch jobs in the form of update runs that applied alters to the CAP source, reassembled and linked it, and ran a standard test suite. You got so many points for adding the * meaning "the current instruction counter," so many more for putting in a simple expression evaluator, and so on. After taking 6.251, I looked for a part-time programming job, and got one in 1963 at Project MAC, using CTSS. This was just after the famous 1963 Project MAC Summer Study, where many of the big names in computers spent time at Project MAC using the brand new idea of a time-shared computer. CTSS, the Compatible Time-Sharing System, had been presented in a paper at the 1962 Fall Joint Computer Conference, even though the software wasn't quite working. But by the time of the summer study it worked, and Project MAC had its own 7094 in the new Tech Square building behind MIT. The Computation Center machine continued to run FMS; it had the standard blue side panels. The Project MAC machine had red side panels, and staff often referred to "the red machine" or "the blue machine." The hardware mods that made CTSS run on MIT's 7094 included more than base & bound registers: in addition, the machines had two 32K core memory banks instead of one. Core bank A held the CTSS supervisor, and B Core was used for user programs. The RPQ that provided this feature added several instructions and some modal flags to the processor. (RPQ stood for Request Price Quotation. IBM in those days would engineer and sell features not part of the standard product, for a price.) More importantly, it made the 7094 a two-mode machine. When the machine was running a program in B-core, many instructions were forbidden: executing them caused the machine to trap and take its next instructions from A-core. In particular, I/O instructions were forbidden, as well as attempts to switch core banks. By convention, user programs called on CTSS supervisor services, such as the file system, by executing a TSX ADDR,4 where ADDR held TIA =HWRFLXA -- the TIA instruction was illegal in B-core mode, so the CPU trapped into the A-core supervisor module named PMTI (Protection Mode Trap Interpreter), which looked up the BCD name of the supervisor entrypoint, found its location, switched the CPU mode, and made the transfer. (picture of 7094 console from page 139 of the manual) The modified 7094 had base and bounds registers to limit user jobs' access to B-core, so that CTSS didn't have to swap 32K to drum for every job. An algorithm called the "onion skin" left parts of a big job's core image in memory if a little job ran next, and handled all the complicated space accounting and reassembly of images. If the drums filled up, swapping spilled to disk. (I remember visiting SDC once and seeing the Q-32 timesharing system there, which lacked these features. If you issued a command the swap space was statically allocated, and there wasn't enough to go around, so you might have to keep trying.. "LOAD OK ON 9" meant you'd claimed enough drum to run.) (Some 360's came with the "storage key" mechanism, which tagged each page of memory with a number from 0-255. The privileged instruction ISK (Insert Storage Key), not available on all models, could set this. User jobs each had their own key and could only access pages with their own key. This was simpler than the 645 segmentation mechanism but precluded sharing of memory between jobs.) The 7094 didn't recognize the indirect bit in an indirect word, but it had the XEC opcode, which executed an instruction out of line, and if you did XEC * the cpu would sit there taking I-cycles, uninterruptible, until manual reset. People were warned not to do this, and of course if they did it while CTSS was running we took a dump, and identified & fussed at the user. (One such crash was caused in 1965 or so by Joel Moses, who was running a big symbolic integration program written in LISP. When we complained, he said it was an honest mistake, caused by using RPLACD. I have been reluctant to use RPLACA and RPLACD ever since.) The one time XEC * was used in a good way was the day in 1966 that a Computation Center administrator's mistake caused the CTSS password file and the message of the day to be swapped. (The editor in those days created a temporary file with a fixed name.) This was before (and was the source of) the idea of one-way encrypting passwords, so everybody's password was displayed to each user that logged in. Bill Mathews of Project TIP noticed the passwords coming out, and quickly entered the debugger and crashed the machine by entering an XEC * instruction. Naturally this happened at 5 PM on a Friday, and I had to spend several unplanned hours changing people's passwords. (The GE 645 let you chain indirections, and had several varieties of execute opcodes; if your program hung the CPU for some small number of milliseconds, a timer generated a "lockup" fault.) CTSS was "compatible" in the sense that FMS could be run in B-core as a "background" user, nearly as efficiently as on a bare machine. This meant that the Computation Center could make the transition from batch to timesharing gradually, and retain the ability to run "dusty decks" and software from other institutions. The Comp Center got the CTSS RPQs added to the blue machine and began running CTSS in 1965. In 1965, most of the CTSS development group had moved over to Project MAC and was beginning the design of Multics. The plan was to use CTSS to support Multics development, and the last big CTSS project was a new, much better, file system, as a kind of parting shot, to ensure that the system would be adequate to support Multics development. There were a few other significant improvements about that same time, some contributed by the user community. Noel Morris and I created a replacement command processor, . SAVED, which supported user-defined abbreviations and multiple commands on a line. I also wrote a command, suggested by Louis Pouzin, called MAIL, which allowed users to send text messages to each other; this was one of the earliest electronic mail facilities I know of. During the fall of 1965, the Computation Center was trying to bring up CTSS on the blue machine, and requesting help from the former CTSS developers at Project MAC when they ran into problems they couldn't handle. The blue machine kept crashing, in a way we'd never seen, and the dumps didn't make sense. Hardware diagnostics showed no problem. Bob Daley and Stan Dunten, in particular, were called on repeatedly to try to figure out what was going on. Corby involved himself too, and hypothesized a "hardware transient" that zapped some registers. Finally the team took the blue machine in the middle of the day, and keyed in a simple test loop, and left it running. After about an hour of execution, the failure count in an index register suddenly began counting up: they had caught the bug! The programmers heaved a sigh of relief and headed over to Tech Square House to celebrate. Quite a few people came down to the bar for a drink, when suddenly the lights went out. I remember I ran up nine flights of stairs to help crank the tape out of the tape drives by hand, because the tapes could be damaged if they were in the drive when power came back on. I needn't have run: it was November 11, 1965, and the lights were out over the entire East Coast, and stayed out until the next morning. I have written elsewhere about how Project MAC chose the GE 645 as the platform for its next generation system, instead of IBM's proposal of a System/360 machine. The Computation Center, however, did choose a 360 for its next generation batch environment, and installed and ran a large 360/65/40 shop during the time that Multics was being developed at Project MAC. And the MIT Urban Systems Laboratory obtained a funding that supported the installation of an IBM 360/67, running CP/CMS, which I will write about in another note. In late 1968, the Comp Center returned the blue machine to IBM. The red machine was moved from Tech Square to the new computation center in building 39, and Multics developers shared resources with general MIT time-sharing users until Multics was self-supporting in early 1969. CTSS continued in use for several more years, with gradually declining usage, as MIT computer users switched to OS/360 batch, CP/CMS timesharing on the 360/67, or Multics. One project, called the Overlap Project, was funded to support 7094 usage until equivalents for some CTSS social-science tools were found on other machines. There was one kind of funny problem with this long decline of CTSS: every year, there was a fire drill as we tried to remember what you had to do to create a system for the next year. The Chronolog clock attached to the machine provided a date and time in BCD, but without the year; that came from a constant in the supervisor, and each year we had to recompile one small module, and relink the supervisor, the salvager, and a few other standalone utilities. As the original CTSS crew gradually moved on to other jobs, fewer and fewer people knew how to carry out this task, but we always managed to figure out how. And each year, we considered making the constant a configuration item somehow and decided not to bother, because the system wouldn't last another year. The 7094 was a fine machine, but by the time it was over ten years old, it had become expensive to maintain, hard to find expert programmers for, and had been deserted by most users in favor of faster and more modern machines. A group of students proposed that they'd take over the machine and run it for student computing; the floor space, air conditioning, and maintenance costs made this impractical, but some of these students went on to found MIT's Student Information Processing Board, which student computing at MIT in many ways, and still exists today. I was there the day Roger Roach finally shut down the red machine for good, on July 20, 1973. (picture of Roger at the keys on that sad day) From crawford@scruznet.com Fri Jun 16 11:37:42 CDT 1995 Article: 104601 of alt.folklore.computers Xref: uchinews alt.folklore.computers:104601 Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!news-e1a.megaweb.com!newstf01.news.aol.com!uunet!fox.almaden.ibm.com!garlic.com!news.scruz.net!crawford.sc.scruznet.com!user From: crawford@scruznet.com (Michael D. Crawford) Newsgroups: alt.folklore.computers Subject: Re: Doing research for a college paper Date: 10 Jun 1995 10:46:03 GMT Organization: The People's Republic of Santa Cruz Lines: 260 Message-ID: References: NNTP-Posting-Host: 165.227.101.81 Status: RO In article , DanClark@nssdca.gsfc.nasa.gov (Daniel Clark) wrote: > I am writing a 10 page college paper entitled "Oddities of the Computer > World". I am looking for material or off-the-wall things to include in my > paper. Here is the most difficult bug I have ever fixed. I was a contract System Administrator for a company that had about 100 engineers and technicians developing a multiprocessing operating system used in voice mail machines. (This was Octel Corporation, which supplies Pacific Bell, and is owned by Hewlett-Packard, so if you leave a message with Pac Bell or HP voice mail, you're talking to an Octel product). Their largest model was the size of the refrigerator. The upper compartment was a card cage filled with many cards, each with two 386 chips, and the bottom was about a half cubic meter filled with full-height 5 1/4" unformatted hard drives. Yes, that's right - unformatted. People really do use unformatted drives to their full capacity. What would show up as a read error on a formatted data drive would appear to a voice-mail user as some brief, and generally unobjectionable noise in a message. I worked there during 1989; I imagine they are using other equipment in their products now. When I started there, they had terrible performance problems. There were three sun 3/180 and 3/280 file servers (these use, I think 25 and 33 MHz 68030 chips), and about a hundred PC's that use PC-NFS to read files off the Suns. There were lots of printers, and many vt100 terminals. Some users used DOS, some used Unix either from the terminals or by telnetting from the vt100. Each day, one machine would either crash, or hang for about twenty minutes and then spontaneously come back to life. Because all the machines had all their volumes crossmounted (with hard mounts), everything hung. A hundred engineers would come by my office to observe my progress in restoring their productivity. This was especially painful while fsck would examine the many megabytes of disk they had. The previous sysadmin, while much better than I at attending to regular details like doing proper backups, would not touch hardware problems and wasn't very creative about fixing problems. He was let go shortly after I started. Each machine had one or two serial port cards with 16 or 32 serial lines. These were used both for terminals, and for downloading the operating system to the voice-mail machines after doing a compile. The download files were typically 50k, and there was no error-correcting protocol other than a simple checksum at the end to indicate that a failure had occurred. They did not even use XModem, let alone the TCP/IP embedded system software downloads that were readily available from a number of vendors. Some users had terrible problems with the download failures, and of course the most important, and most impatient of the users had the worst problems, and these folks would vent their anger all over me, as I was desperately trying to pretend I had a clue while trying to get a grip on the problem. Another problem was that the thin-net ethernet cable was all messed up. It had been installed by telephone technicians, who knew about phone wiring but not ethernet, so that they did not understand the difference between RG58 and RG59 cable and connectors. A particular problem I had was that someone's BNC connector would fall off the end of the cable, taking down a whole leg of the net (fortunately we had some repeaters, so everyone wasn't hosed). I would run around with a terminator, doing a binary search to locate the fault, and then reattach the right kind of BNC connector. The serial cables were just as bad, as they used the blue and white twisted pair telephone wire, sometimes extended for lengths of 500 feet, bundled with data and telephone wires. I often worked late at night to work on backup scripts, and generally to avoid my users. I noticed that the machines would sometimes crawl, or even crash, when there were no users. At some point I ran Sun's performance monitor Sunview tool on the console, monitoring each machine's CPU load. This tool is a window with a simple graph of CPU activity vs. time, slowly crawling to the left as time passes. Each machine would exhibit the same peculiar behaviour... there would be a time of quiescent, near-zero CPU loaded, then some abrupt spikes, up to a load-average of three or four and down to zero again, followed by an extended plateau with a high load average. There is a version of ps that gives you a live listing of the top CPU hogs. I think this is "top". It does a process listing every few seconds, sorts them by CPU usage, and redisplays the list. Normally the top process would be top itself, as it requires quite a bit of cycles to grope around in the kernel getting its statistics. During the CPU load plateaus, however, the top process would be something like: login -p Mkkuow..... I don't recall the exact user name, but it was always the same. The name comes into play later on. I spent a lot of time trying to figure this out. Mister Mkkuow would be logging into to several serial ports at a time, and always in a serial port and never a telnet session. If I disconnected a cable, that login process would disappear, only to be replaced by one at another cable. If I disconnected all the cables, the machines would stay quiet all night long. Who was Mr. Mkkuow? Why was he always trying to log in? And why would logging him in crash my machines? I got some books on serial communications, and read up about how RS-232 ports work, the low-level details of ASCII (voltages and so on) trying to figure out what was going on. At some point I went to one of the terminals that Mr. Mkkuow was always trying to log in on. I borrowed an oscilloscope from one of the techs and sat at the terminal for a while, with the scope probes plugged into a breakout box (a device with lots of connectors that allows you to rearrange the wiring in a serial cable - it is used for design and diagnosis of serial communications). The hardware engineers were very amused to see their sysadmin using an oscilloscope on a terminal. I found that if I typed a character on the keyboard, the RS232 signal would be sent like this (as is proper): ------ ------ ------- | | | | | | | | | | | | | | | | | | ----- ------- ------ --- While I would also see a signal on the line _into_ the terminal, that looked like this: |\ |\ ---| \---| /---| \ |/ So you see, wherever there would be a transition up, there would be a spike with an exponential decay. If two bits stayed the same - we had a 11 sequence, or a 00 sequence - there would be no spike as the voltage had remained constant. This is capacitive coupling; if you drive a square wave into a capacitory that bleeds through a resistor, you get signals that look like this. It is a problem in electronic hardware design that is caused by having long, straight wires next to each other. The wires form the "plates" of a capacitor. I graphed out all the ASCII codes as square waves, and drew what the expected shapes would be after passing through this "capacitor". Wherever a plus spike would be created could be interpreted as a 1 bit; a negative spike could be a 0 bit. The capacitatively reflected bits would not show up on the terminal as I typed them, as they certainly did not fit the RS232 protocol, which requires that the voltages stay constant for a period of time. But would they be picked up by the Sun serial ports? I wrote out the actual user name I was seeing. This encipherment was not one-to-one - several input characters mapped to the same output character - but it wasn't too hard to guess based on the available candidate letters. Mr. Mkkuowwhatever was really.... SunOS Login: Yes, that's right folks, we had a destructive feedback loop going. Getty would emit the login prompt on the send data line, which would be garbled and fed back in the receive data line. Getty would launch login (the program named "login"), passing the garbled login prompt as the user name. Login then would emit "Password:", and get some garbage back as the password. Login then says something like "Login Incorrect" and then "login:", repeating the cycle. Do this on 32 lines all at once, and have a high enough terminal speed, the kernel will spend all of its time just handling the interrupts. This is the sort of condition in which very subtle and difficult to find bugs manifest themselves, such as not disabling an interrupt when accessing a critical data structure, and the Suns would crash. I went down to the electronics supply and asked for a wire catalog. All the cables had their capacitance per foot listed. I picked out a data cable with the lowest capacitance available. I didn't wish to mess around. Then I asked my manager for $500 to buy a spool of cable and a bunch of RS232 connector kits. I would have to crimp and assemble all the ends myself. It took some argument to get the money, including showing her my oscilloscope work and charts of "ascii encryptions", but she eventually forked over the money, desperate to try anything in the hope of working a full day without a crash. Not all the terminals exhibited this behaviour. I picked out the worst ones, and the worst download cables, and replaced them. This cable was low capacitance because the wires had very thick insulation on them, keeping the wires far apart, and I imagine the insulation had a particularly low dielectric constant. The thich insulation made it hard to crimp the pins on properly but I could get it to work. The Suns stopped crashing. Most of the downloads starting working. The whole process of diagnosing and fixing the bug took five months. But not all. There was one particular engineer who was always very angry at me, that I could not get his download to work. No matter what I tried, his downloads failed about half the time, wasting about ten minutes per download. The gremlins could be subdued, but not completely conquered. In the end I quit the job, and quit doing SysAdmin work entirely, because I just did not have the fortitude to deal with people like him. Now, when I took this job, I evinced a bit of bravado in the job interview, not exactly lying about my experience but definitely embellishing on what I knew how to do. I used to do this on all of my interviews as I had no degree, and had little computer science education, as I had majored in physics. I made up for this by studying a great deal on my own, and often working overtime to study on the job. I lived in constant fear of being found out as incompetent. It took me a long time to overcome that. I'm just beginning to believe that I have a clue. So I was especially pleased when I explained the solution of this problem to an Octel engineer, and he commented that this was "good sleuthing". What is ironic is that I would never have found this bug if I had not understood capacitive coupling, which was discussed in the analog quarter of Electronics for Physicists at UC Santa Cruz, taught by Professor David Dorfan. Dorfan criticized the digital logic designers who claimed that they did not need analog to design circuits, saying that he did not understand how they could get anything to actually work, because one must understand the analog physics of a circuit if you are to get bugs such as capacitive coupling, or localized hot spots out of a chip. And even more ironic... I failed the class. Deservedly too, as I had done very little of the homework or labwork, and missed most of the lectures. Octel moved to a new building shortly afterward. We had the networking and the serial cables designed and installed by contractors who specialized in such things. We designed a computer room with proper power, air conditioning, cable conduits and even a raised floor like in the movies. I imagine that the rats nest I endured was completely replaced by a properly designed and engineered system. But I never really found out, as I quit shortly before they moved, though after participating in the design and ensuring that the job would be done right. It was a very satisfying experience. I don't think I would have been really happy, though, if I had a job where all the equipment worked right and I just had to attend to the tedium of running regular backups and training the users. Better that they should hire back the fellow who preceeded me. Signing off, -- Michael D. Crawford crawford@scruznet.com <-- Note change of address crawford@maxwell.ucsc.edu <-- Finger me here for PGP Public Key http://www.scruz.net/~crawford/ (Still under construction) HAVE *YOU* EXPORTED A CRYPTO SYSTEM TODAY? --> http://dcs.ex.ac.uk/~aba/x.html -------------------------------------8<------------------------------------- #!/usr/local/bin/perl --#export-a-crypto-system sig, Diffie-Hellman 2 lines: ($g,$e,$m)=@ARGV;$_=unpack('B*',pack('H*',1&length$e?"0$e":$e));s/^0+//; s/1/0lG*lm%/g;s/0/d*lm%/g;print `echo 16i\U$g"\nSG$m\Esm1Io$_"p|dc` -------------------------------------8<------------------------------------- From jav@cpcug.org Sun Mar 17 11:01:24 CST 1996 Article: 136742 of alt.folklore.computers Xref: uchinews alt.folklore.computers:136742 Path: uchinews!gw2.att.com!news.midplains.net!chi-news.cic.net!news.math.psu.edu!ra.nrl.navy.mil!lamarck.sura.net!newsfeed.internetmci.com!in2.uu.net!news3.digex.net!usenet From: jav@cpcug.org (John Varela) Newsgroups: alt.folklore.computers Subject: Re: hardware hacks on computers (extra switches..) Date: 16 Mar 1996 20:08:49 GMT Organization: Express Access Online Communications, USA Lines: 35 Message-ID: <4if74h$o2q@news4.digex.net> References: Reply-To: jav@cpcug.org NNTP-Posting-Host: cpcug.org X-Newsreader: IBM NewsReader/2 v1.9d - NLS Status: R In , Marco 'Whale' van den Hout writes: >I wonder how common this kind of addons were/are. Are there types of >computers that frequently got this treatment (Amiga?) while others remained >pretty much out-of-the-box (Mac?)? Does anybody have a nice story on >those, like a computer with tons of switches, LED displays, speed >control, custom EPROMS, etc.? This story is only tangentially related to your request: About 15 years ago at MITRE in McLean, VA, we had a lab in which there was a Raytheon RDS-500 mini, which supported some real-time air traffic control experiments. There were the usual tensions and accusations between the hardware and software guys, which got to the point where the lead hardware guy had a padlock installed on the access panel to keep the lead software guy from going in there and throwing switches. Then they upgraded the CPU. The lead software guy insisted that he had to be able to return to the old mode in order for his software to run. The hardware guys insisted that was nonsense. Finally, they conceded to install a toggle switch on the exterior of the machine, labeled with the old and upgrade model numbers (I forget what they were; I think one of them was 704). The software guy would dutifully go in, throw the switch, run his program, then throw the switch back when he left. Of course the switch was not wired to anything. When the lab was decommissioned, the panel with the switch was cut out, framed, and presented to the software guy. Names of perpetrators provided on request. ------------------------------------------- ----- John Varela jav@cpcug.org ----- -------------------------------------------