From: RS Date: Tue, 17 Jul 90 08:51:57 EST In-Reply-To: SG's message of Mon, 16 Jul 90 19:33:57 EDT Subject: Talk message meaning? Date: Mon, 16 Jul 90 19:33:57 EDT From: SG Date: Mon, 16 Jul 90 15:06:57 EST From: RS Date: Mon, 16 Jul 90 07:52:20 EDT From: SG Date: Mon, 16 Jul 90 00:59:32 EDT From: JB So, what does this mean? "[Checking for invitation on caller's machine]" It means it is trying to connect to the talk daemon on the callers machine and not finding it... OK, then what does "[Trying to connect to your party's talk daemon]" mean? Look at the source code. So what kind of operating system has standard utilities with undocumented diagnostic messages? Oh, I see. If someone actually documented Unix in its entirety, just the "Bugs, Lossage, and Error Messages" section would look like a set of VMS documentation. UNTALK, without a screen refresh routine, was never this bad.   Date: Thu, 19 Jul 90 20:28:11 EDT From: JD Subject: .plans When I feel the need for inspiration I sometimes examine the .plan files for Unix users. Occasionally I find such marvels as the below (cond ((femalep fingerer) (meet me fingerer)) ((malep fingerer) (apply rm-* fingerer-home-directory)) (t (introduce-to-been@lamprey.ff.jefferson.edu fingerer)) ) /* and now in a superior language... */ switch (fingerer) { case FEMALE: (fun)meet((irresistable)me,(intelligent_and_fun)fingerer); break; case MALE: system("rsh $FINGERER_HOST_MACHINE:rm $FINGERER_HOME_DIR/*"); break; default: reply_to_fingerer("I know just the right man for you. Call 1-800-I-TAKE-ANYONE and ask for been, or send email to been@lamprey.ff.jefferson.edu... happy hunting..."); break; }   From: FB MMDF-Warning: Parse error in original version of preceding line at lost.in.the.shuffle Date: Fri, 20 Jul 90 13:50 EDT Subject: Is there really such a list? If this is really a list, I'd like to subscribe. FB Teachers College, Some University p.s. How would I get stuff posted to the list before I signed on?   From: CM Date: Mon, 23 Jul 90 14:35:09 EDT Subject: sign this man up! From: DT Date: 06-Jul-90 17:19 Subject: why Unix sucks Some Andrew weenie, writing of Unix buffer-length bugs, says: > The big ones are grep(1) and sort(1). Their "silent > truncation" have introduced the most heinous of subtle bugs > in shell script database programs. Bugs that don't show up > until the system has been working perfectly for a long time, > and when they do show up, their only clue might be that some > inverted index doesn't have as many matches as were expected. Unix encourages, by egregious example, the most irresponsible programming style imaginable. No error checking. No error messages. No conscience. If a student here turned in code like that, I'd flunk his ass. Unix software comes as close to real software as Teenage Mutant Ninja Turtles comes to the classic Three Musketeers: a childish, vulgar, totally unsatisfying imitation.   From: MT Date: Tue, 28 Aug 90 00:30 EDT Subject: mostly a test A relatively minor complaint, just to see if the list still works: Unix misfeatures combine synergistically. For example, the make program seems to have no option to force a recompilation of everything. This wouldn't be so bad, but combined with the fact that binary files have no extension, so you can't easily delete them all, it's a royal pain. No, it's just a baronial pain, it doesn't really stop you from doing anything, it just makes you take so many extra steps that you forget why the hell you were doing anything so distasteful as trying to compile C programs in the first place.   From: AB Date: Sat, 1 Sep 90 01:40:53 EDT Subject: Re: mostly a test "Unix misfeatures combine synergistically." I gather that this is what the "touch" command is for. In fact the manual entry for "touch" gives the example example% touch *.c example% make as its -only- example of an application for "touch". Typical Unix weenieism: Why would you care about preserving the modification dates of your C source files? Everybody knows that the only use for modification dates is for the benefit of the "make" utility. If you want to remember the actual last time you edited those files, then keep your own damn database of dates and times, and stop bothering us Unix Wizards.   From: CM Date: Sun, 2 Sep 90 15:11:40 EDT Subject: Re: mostly a test From: AB Date: Sat, 1 Sep 90 01:40:53 EDT If you want to remember the actual last time you edited those files, then keep your own damn database of dates and times, and stop bothering us Unix Wizards. I thought this is what RCS is for. I'm TA'ing an OS course this semester. The last lecture was an intro to Unix since all other operating systems were only imperfect and premature attempts to create Unix anyway. Some lecture highlights... An aside during a discussion of uid's and many a unix weenie's obsession with them: "A lot of people in the Unix world are weird." When asked if Ritchie et al regretted some other inconsistency in Unix metaphysics, "These guys probably don't care." Have another twinkie.   Date: Sun, 2 Sep 1990 12:24:00 PDT From: PD Subject: Re: mostly a test In-Reply-to: CM Well, they're doing it all over again. The new system is called Plan 9 ("Plan 9 from Bell Labs") and it's a distributed operating system designed to be usable with clusters of machines linked by long-haul WAN lines... I expect it's still creat(). -- pd "We've taken out all the crufty old bugs and replaced them with shiny new ones".   From: AB Date: Mon, 3 Sep 90 17:19:01 EDT Subject: [Boston Combined Schedule] Return-Path: <@hs.craze.tla.ment:arg.hhh.aug.hhh> Received: from told.tla.ment by hs.craze.tla.ment (4.1/AI-4.10) id AA08586; Mon, 3 Sep 90 17:03:33 EDT Received: from hs.craze.tla.ment by told.tla.ment id aa15051; 3 Sep 90 17:02 EDT Received: from craze.tla.ment (HHH.AUG.HHH) by hs.craze.tla.ment (4.1/AI-4.10) id AA08548; Mon, 3 Sep 90 17:01:20 EDT Received: from SIC.SIMPER by hhh.aug.hhh id aa08279; 3 Sep 90 17:00 EDT Received: by sic.simper (5.61+++/SMI-4.0.3) id AA18258; Mon, 3 Sep 90 16:59:35 -0400 Date: Mon, 3 Sep 90 16:59:35 -0400 From: DE Message-Id: <9009032059.AA18258@sic.simper> To: ST@saw.craze.tla.ment Subject: Boston Combined Schedule Cannot execute binary file.   Date: Mon, 17 Sep 90 22:13:19 EST From: RS Subject: [noone@at.dot.at: sun-lossage] From: JT Date: Mon, 17 Sep 90 17:35:03 -0400 Subject: for bob, carol, ted, and anyone else with an at.dot.dot account... Sun fouled up. You can't have more than 1024 entries in /etc/passwd and the AI lab hit 1025. So they dyked out a whole bunch of accounts at random (including their own). Hopefully they'll be back soon. (setq sun 'brain-death)   Date: Tue, 18 Sep 90 14:33:15 -0700 From: DW Subject: [abcdef@ghijk.com: please add to mailing list] God, I hate this! Can someone take care of this guy? He's paid his dues (see below). From MAILER-DAEMON@nev.dul.lard Tue Sep 18 09:29:27 1990 Date: Tue, 18 Sep 90 09:27:20 -0700 From: MAILER-DAEMON@nev.dul.lard (Mail Delivery Subsystem) Subject: Returned mail: User unknown Return-Path: Message-Id: <9009181627.AA02924@nev.dul.lard> To: Status: R ----- Transcript of session follows ----- >>> RCPT To: <<< 550 ... User unknown 550 ... User unknown Date: Tue, 18 Sep 90 09:26:45 PDT From: abcdef@ghijk.com (Robert R. Henry) To: unix-haters-request@at.dot.dot Subject: please add to mailing list Can you please put me on the unix-haters mailing list? I was told to contribute something to the mailing list in order to prove my authenticity.... In the past years there have been a number of flames regarding the 'set henry' option to Berkeley Mail. 'set henry' is no longer in the sun release, but I believe it still lives on in Ultrix release. Why 'set henry'? Makes perfect sense, no? Well, its a case of the squeaky wheel getting the grease. Turns out there was a grad student at Berkeley named Robert Henry who wanted to do something like Mail luser@at.dot.dot < filename and wanted to embed ~ escape characters in the filename that would be treated as they are when input from the tty. The default Mail behaviour is to ignore escapes from non tty stdin. Henry complained, and got this special option, which lives on.... Robert R. Henry   Date: Fri, 21 Sep 90 01:52:35 EDT From: SS Subject: Daisy, Daisy... [Reprinted from Usenet newsgroup] [Note the Organization!] From: AG Subject: Poetic Justice in a Machine Crash Date: 14 Sep 90 12:56:47 GMT Organization: Center for Reliable and High-Performance Computing University of Illinois at Urbana Champaign Our Encore Multimax just crashed in a way that seems like poetic justice: On the console terminal appeared a fragment of somebody's paper about multiprocessor interconnection networks. The last readable sentence was: "...it is difficult to build shared memory procesors " "^%%^$#$%#%$#it is difficult to build shared "memory$%#%$#it is difficult to build shared "memory$%#%$#it is difficult to build shared "memory$%#%$#it is difficult to build shared "memory%^$%^$%^$@#$@!$@#$@difficult to build shared "memory$%#$%$%#$%shared memory%^$%^$%^ shared memory "%&$%^^%$$%^%^$ shared memory&*^&*&*^&*^shared memory ... Almost too good to be true :-) (The screen garbage and control characters are not recorded verbatim). [Once again I am reminded of the prophetic nature of Vic Vyssotsky's Chaostron piece, reprinted in CACM, April 1984, pp. 356-7. -PGN]     From: EB Date: Wed, 26 Sep 90 12:11:56 PDT Subject: Desert Shield meets UNIX "To combat the use of chemical weapons by the Iraqis, the Pentagon is planning a two-pronged, high-tech defense using UNIX-based laptops. Using meteorological-type programs, the laptops could quickly determine how widespread the attack will be, where the troops can safely be deployed and how quickly they should be moved. The information would then be fed into UNIX-based PCs, and field commanders would run a variety of attack scenarios. A full meteorological model, able to forecast likely future wind conditions over the entire risk area, could be generated within 60 seconds. [UNIX Today, 9/17/90]" You probably thought that UNIX could only be found in a harem in the Middle East.   From: RK Date: Wed, 26 Sep 90 19:11:57 EDT Subject: Unix vs. Windows Date: Wed, 26 Sep 90 10:46:57 PDT From: DW I predict that you will be programming an MSDOS machine within 5 years. Yeesh, that's pretty grim. I'm programming an MSDOS-machine *now*, but it's running Windows 3.0. Windows 3 has ``orderly'' shared memory, an application-oriented IPC mechanism that many programs already exploit in a meaningful way, and shared libraries -- when will the *n* different versions of Unix get them ? Oh yeah, and it might not be the world's most flexible window system, but at least you know what you get when you're running Windows. The real story is that by the time the Unix camps get together, there will be a large portion of users out there who will be doing hairy real-world things without the ``help'' of Unix. Already, PCs and Macs help run long-distance phone services and produce magazines -- not ``computer'' magazines but real magazines like Spy, Wigwag, and the Source. Unix is best for hacking Unix utilities. Of course, the Lisp Machine was a far better machine for meta-hacking. Unix is poor choice for end-users on one hand and pure hackers on the other...   From: PS Date: Wed, 3 Oct 90 22:21:57 EDT Subject: Re: Person Transfer Protocol Date: Wed, 3 Oct 1990 11:14-0400 From: DM Subject: Person Transfer Protocol Date: Tue, 2 Oct 90 06:01:28 -0500 From: Our friend the daemon Subject: Defunct user [Re: Subgenius Digest V2 #11] To: Subgenius@told.tla.ment ...Please verify that you actually mailed the person whom you were A | intending to mail. The Mailer Daemon The excision of any preposition properly following a verb that describes some form of communication is just another idiopathic element of the Unix-cum-Usenet weenie culture. Consider the way the weenies constantly bleat to each other, "Don't flame me!" In retrospect it's not surprising that the mailer daemon, a true weenoid personality if there ever was one, would exhibit this behavior! ps P.S. If the Beltway-circuit savants were Unix weenies, they wouldn't say that they "speak truth to power," but rather that they "speak truth power." If the Eurhythmics were Unix weenies, their famous song wouldn't say, "Talk to me / like lovers do," but rather "Talk me / like lovers do." And if the translators of the King James Bible had been Unix weenies, Jesus would never have verily said anything unto us, but would instead have verily said things us.   From: PS Date: Thu, 4 Oct 90 00:38:23 EDT Subject: Unix English (Was: Person Transfer Protocol) In fact, a little bit of further thought about Unix-weenie use of verbs describing communication has caused me to think of the way Unix weenies use nouns describing communication. They transform the noun to a verb, and then use the rule I cited earlier on the new verb, excising any prepositions that one might have expected to follow the new verb. Thus "send a message to me" is "message me" in Unix-weenish. By analogy, "send a letter to me" would be "letter me," and "read a book to me" would be "book me" in Unix-weenish. When we consider that "throw the book at me" would also be translated to "book me," we see that Unix-weenish is rife with possibilities for misinterpretation.   From: JW Subject: Re: Person Transfer Protocol Date: Thu, 4 Oct 90 0:25:35 EDT From: PS Date: Wed, 3 Oct 90 22:21:57 EDT Date: Wed, 3 Oct 1990 11:14-0400 From: DM Subject: Person Transfer Protocol Date: Tue, 2 Oct 90 06:01:28 -0500 From: Our friend the daemon Subject: Defunct user [Re: Subgenius Digest V2 #11] To: Subgenius@told.tla.ment ...Please verify that you actually mailed the person whom you were A | intending to mail. The Mailer Daemon The excision of any preposition properly following a verb that describes some form of communication is just another idiopathic element of the Unix-cum-Usenet weenie culture. Consider the way the weenies constantly bleat to each other, "Don't flame me!" In retrospect it's not surprising that the mailer daemon, a true weenoid personality if there ever was one, would exhibit this behavior! Well, I'm not entirely sure I agree with this. It seems quite possible that Our Friend the Daemon in fact said exactly what it meant. I mean, it is, as it points out, Our Friend, and it may well just be reminding you that if this mysterious unnamed person really truly -needs- to communicate with someone else, you are far better off simply mailing the person himself (presumably by Federal Express or UPS) than counting on Unix to deliver the message. jw   Date: Thu, 4 Oct 1990 02:24-0400 From: KP Subject: Re: Unix English Aha. Clearly this is why Unix is so heavily ridden with misspellings and bizarre case. Presumably they don't actually lose information when they do this contraction. Rather, the phrase "read me a book" might map to "book me" but "throw the book at me" could translate to "Book me" and "give the book to me" to "bk me" and so on. (The fact that these are all pronounced the same aloud is presumably thought to be a bug not in the user interface, but rather in the user's inter-face.) With combinations like "bOOk mE" available as semantically distinct entities, presumably they can unambiguously represent enough sentences to satisfy most user's day to day needs. This leads me to question my established beliefs about the origins of Unix. I had always assumed that in the early days there were a handful of commands written by people who couldn't spell. But what if they were good spellers who just didn't know that many words--perhaps they only knew one or two words and were forced to compensate. Following this line of reasoning, primordial Unix might have been organized very differently than most people think--perhaps around a single word (or maybe two or three), but with tons of different spellings and casifications accomodating the myriad subtle linguistic distinctions required even of primitive reptiles who haven't yet come out from under their shell. Commands like "doIt", "doit", "DOIT", "doiT", etc. might have ruled the world. Wow. This is fascinating. Thanks for sending me down this path of reasoning, PS. Well, it's late and I should be asleep. Or perhaps I already am, and this whole Unix business is all just a bad dream. I wish. kp   Date: Fri, 2 Nov 90 5:13:51 EST From: RA Subject: Unix and basic arithmetic I think I've finally figured out what the name of the "more" program means. I just managed to read 120% of a file.   From: RS Date: Mon, 26 Nov 90 22:15:25 EST Subject: Return-Path: Date: Sun, 25 Nov 90 20:45:46 EST From: MAILER-DAEMON@at.dot.dot (Mail Delivery Subsystem) Subject: Returned mail: User unknown To: rs ----- Transcript of session follows ----- 421 dino.squibb.com: Host dino.squibb.com is down Why do I care? I just got 20 messages in my mailbox telling me that a host I don't maintain or even care about is "down". So what? If it had been down for a week or two, I might want to consider removing this guy from the mailing list, but couldn't sendmail wait that long before telling me? Hell, no. If it had to keep track of all the Unix machines on the net that were down or otherwise hosed, it'd run out of paging space within an hour. 550 postmaster... User unknown Yep, that's on our local machine. I checked out postmaster's mail file; there are *some* messages getting through, but it seems to depend on the whim of the mailer at the moment. ----- Unsent message follows ----- bleah... PS: I hear rumors that OSI, when installed, is going to triple the size of the 4.4 BSD kernel...   Date: Tue, 27 Nov 90 10:13 CST From: CG Subject: Re: Date: Mon, 26 Nov 90 22:15:25 EST From: RS 550 postmaster... User unknown Yep, that's on our local machine. I checked out postmaster's mail file; there are *some* messages getting through, but it seems to depend on the whim of the mailer at the moment. I noticed at one point that sendmail on our sun seems to use the YP (er, I mean NIS; it *was* nice of British Telecom to force Sun to rename their white pages service to be something other than "yp") aliases map *almost* all the time. The one exception is when sending error mail to the postmaster, when it uses /etc/aliases. Or maybe I have that backwards. Anyway, for a while we had two different Postmasters.   Date: Tue, 27 Nov 90 13:13:48 PST From: DH Subject: What I tell thee three times is true Date: Tue, 27 Nov 90 10:13 CST From: CG it *was* nice of British Telecom to force Sun to rename their white pages service to be something other than "yp") ... A crying shame too. After all, even though Sun's "yellow pages" service was really a white pages (name lookup) service, they should have been able to use whatever deceptive name they wanted. Renaming things for market position is really a modern (not just unix) tradition: Build a presentation manager: call it Presentation Manager... Build a personal computer: call it The ibm Personal Computer... Build a machine with an 8-bit byte: Define "byte" to be 8 bits... Build a IO subroutine package: call it DOS (an OS). But the unix weenies have refined it to a high art. Everything must be "open" and a "standard." Why, my company already supports at least a dozen "standards!" The latest Sun entry is their new "free" window system. Their salesman called me proudly: all you need to do is send them a thousand dollars a copy, plus pay a royalty on programs which use it, and you can use their new free open standard window system (called "open look" of course). Hm, maybe I can add cons to C and call the result Lisp...   From: AB Date: Thu, 29 Nov 90 03:45:17 EST Subject: New twist on From lossage Faugh. I just caught up on 400 messages that got massaged with /usr/ucb/mail before emacs got a hold of them. Every time a line started with the word "from" the mail program put in a bunch of bogus header garbage about status bits and spool directories, smack in the middle of the messages. I think I liked it better the other way...   From: DC Date: Fri, 30 Nov 90 14:17:23 -0800 Subject: Lazy Prompting I'm sure you've noticed that often when you open a net connection to a unix, it prints a header and then nothing happens; you don't get a login: prompt. If you type a return at it, you get a prompt. I can't imagine any model of the world in which this makes sense, and conclude that something evil, probably involving Elder Gods and/or Charles Keating, is involved. dc   Date: Fri, 30 Nov 1990 17:51-0500 From: KP Subject: Re: Lazy Prompting Date: Fri, 30 Nov 1990 17:17 EST From: DC I'm sure you've noticed that often when you open a net connection to a unix, it prints a header and then nothing happens; you don't get a login: prompt. If you type a return at it, you get a prompt. I can't imagine any model of the world in which this makes sense, and conclude that something evil, probably involving Elder Gods and/or Charles Keating, is involved. I don't know about this `evil' thing. Unix itself may be evil, but that doesn't mean that every action it takes is automatically evil. (Some of them might just be innocently dumb, for example.) Here are some possible explanations that occur to me which explain the behavior without any need at all to appeal to the supernatural: - As we all know, the Unix command set is not for the faint of heart. Perhaps Unix is just trying to protect itself from people who have the wrong idea about what to expect interface-wise by doing an up-front screening of potential users, and turning a cold shoulder to those who might think it follows from the fact that you connected to a machine that you might want to log in. - Perhaps there's some cool back-door thing we're not aware of. Perhaps everyone just assumes that it's waiting for to type return to get a login prompt, but in fact if you knew better you press a magic key sequence at just the right interval and it would let you in without going through login. It could be that before it announces "Please login" it whispers "Please breakin" under its breath. - Maybe it's just an optimization. [Background: A disproportionate number of unix-lovers have oft been suspected of having substantially less than average IQ, though studies by experts--the same ones that do the cigarette smoking studies, in case that's significant--have never proved this conclusively. And even among those who think there is a correlation, there's a raging debate over whether the low IQ level causes the interest in Unix or vice versa.] It could be that a large number of unix-lovers have such a limited memory that they forget why they were connecting to a machine and just forget to login. So maybe the Unix implementors are just saving some I/O instructions for the common situation of users spacing out in `mid-session' and not really -needing- all that extra typeout about "Login:" which you might expect to follow in a more protracted session. [On the other hand, given the overall usefulness of the Unix environment, it could be the -smart- users who realize at this early point in the session that it would be pointless to continue to the point of actually logging in. Hmmm...]   Date: Sun, 2 Dec 90 17:53:14 EST From: RS Subject: abUsenet flame (I tried to mail this once before, but (wouldn't 'ya know it), the mailer on life was broken...) Yes, Virginia, there *is* something worse than Unix - it is called "AIX" and is currently being pushed on an unwary public by IBM. But I digress. In case you don't read abUsenet, here's a post I just made to alt.folklore.computers: From: RS Subject: Hardware Architectures and I/O (was: Re: Jargon file...) **FLAME!!** Date: Sun, 2 Dec 90 15:43:03 GMT Lines: 53 In some previous article PT writes: > Back when there were REAL(tm) computers like 780, a lot of > time and energy went into designing efficient I/O from the > CPU bus to the electrons going to the disk or tty. > Damn right, but even the 780 was a step down. Get your KL-10 documentation set out and read about *them*. - Front-end PDP-11s that did Tops-20's command completion. - Separate I/O and memory buses. - 8-ported (that's eight, son) memory that talked to the I/O front-end machines for *real* DMA, not cycle stealing! > Sure OS's and apps have gotten bloated, but when you put a > chip like the MIPS R3000 on a machine barely more advanced > than an IBM-AT you end up with a toy that can think fast > but can't do anything. I can't really blame companies > like DEC and Sun for producing mismatched hardware, > because their marketing drones are constantly trying to > undercut each other in price. It's a hell of a lot more > expensive to ship a product with a well designed I/O > system than to drop in a "killer bitchen" CPU chip; > occasionally someone makes the attempt do design a great > piece of hardware, and you end up with something not half > bad (like the DECstation 5000, which is only crippled by > Ultrix You left out the worst offender of them all - IBM. The RS-6000 may crank out 27 MIPS, but it can't context switch or handle interrupts worth sh*t. You can lower machine performance to the point of unusability by FTPing a file from another machine on the same ethernet segment! Next time get a chance to play with an RS-6000, try this: Pop about a dozen xterms, iconify them, put the icons in a row, and wave the pointer back and forth over them as fast as you can. Astounding, no? The highlighting on the icons will keep bouncing back and forth long after you stop waving the pointer. My personal record is 20 seconds. Makes a Sun-2 running display Postscript seem astoundingly fast. RS-6000s also have an annoying tendency to "lock up" for a few seconds (5 < x < 15) and then return to normal - I'm told that this is normal and due to paging activity. The microchannel card cage design is pretty bad too - sure, you can put cards in, but God help you if you have to take them back out! And you better tighten down the retaining screws all the way... or the first time you look at the card funny it will pop out. To its credit, I must say it compiles GNU Emacs faster than any other machine I've used, but I do more with a workstation than just run compiles. And, if you think Ultrix is bad, it's only because you haven't tried AIX.   Date: Mon, 3 Dec 1990 09:28:21 PST From: LK Subject: Re: lazy prompting Both of you are wrong. Having to press the return key before getting a login prompt is a legal requirement stemming from last year's case where charges were dropped against a computer "criminal" because the login prompt said "Welcome to Foobar Unix." Pressing the return key constitutes an acceptance of the terms and conditions stated in the agreement to use, which can be revoked at any time. It's like breaking the seal on the package containing the Tetris disk you bought for the IBM PC. In other words, the return key in the Unix dialect means :Show Legal Notice.   From: JW Subject: Re: Lazy Prompting Date: Mon, 3 Dec 90 14:11:15 EST From: LK .... In other words, the return key in the Unix dialect means :Show Legal Notice. You know, I had never thought of this, but it is a fascinating theory. I just wanted to offer a supporting observation. It would seem that the more important a unix command is (to unix weenies) the shorter the name, e.g., "c" is much shorter than "restore". Now, here in the future, the unix world is becoming dominated by marketing, cross-licencing, and legal issues. So what a masterpiece it is to devote the only valid command name containing NO characters to addressing these concerns!   From: RA Subject: Just type "d" now, thank you Date: Fri, 7 Dec 90 1:12:59 EST Well, we just installed a kludge in MC's mailsystem which will, in theory, allow y'all to flame about unix without getting the bounce messages. Unix-Haters, you will be pleased to know, is the first list on MC to be so converted. Somehow it seemed appropriate. But, so that it shouldn't be a total loss: the MIPS (Risc/OS) dialect of unix is one of these SysV/BSD hybrids where the order of the various magic directories in your PATH variable determines whether it's emulating AT&T braindamage or UC Berkeley braindamage. Well, I had occasion to change my password on such a machine today, and dicovered that the AT&T emulation is more "secure" than the BSD emulation. The AT&T emulation absolutely refused to accept my chosen password because it didn't meet its security criteria: at least six characters long, at least two letters, and at least one digit (I didn't have any digits). The BSD emulation has a different set of pet peeves, about which it also flamed. The difference is that after you've typed the same "bad" password three times to the AT&T emulation, it tells you go away and take a stress pill, while the BSD emulation will accept your "bad" password if you repeat it five times.   From: PA Date: Fri, 7 Dec 90 15:36:43 GMT Subject: Here at Sussex, the unix mailer makes our lives miserable. Date: Fri, 7 Dec 90 15:12:51 GMT From: JG Subject: mailboxes owned by "nobody" This message applies to everyone whose mail is held on a Cogs computer. It is *especially* relevant to the people whose mail is held on tsuna, i.e. undergraduate and MSc students. There is a recognised problem with the mail system's final delivery agent, "binmail" (section 1 of the on-line manual). The final delivery agent, as the name may suggest, is the program which appends mail messages to a user's system mailbox, after the message has hopped from host to host, en route from the sender to the recipients. The problem is that, under certain circumstances, the ownership of a system mailbox may be changed to a special value, "nobody". This means that the true owner of the mailbox can no longer read his or her mail. I am currently trying to fix this bug in binmail. In the interim, it is possible to prevent the bug from manifesting itself by making a small alteration to your mail configuration file, held the file ".mailrc" in your home directory. Simply add the line: set keep=Yes Note that this workaround is only guaranteed to work for users of the standard UCB mail program - by default, "mail" on Suns, and "mailx" on bobcats. If you use a different mailer, then you probably know enough to make the corresponding change -- the object of the change is to prevent a user's system mailbox being deleted, even if all mail messages have been read. I shall restore shortly the ownership of all existing mailboxes (so that you can read this message), and again late afternoon (so you have time to change your mail configuration). If you see anyone experiencing this problem, tell them what to do to work around it, and *then* ask a systems person or myself to reset the ownership of the mailbox. Sorry for all the problems. Hopefully, SunOS 4.1.1 will be better.   From: JM Date: Fri, 7 Dec 90 11:35:19 PST Subject: Longest uptime Recently seen as the result of a call to finger: /bin/gnufinger/hostdata: file has not changed in 1 week, 4 days, 1:01:34 User Real Name What Idle TTY Host Console Location arg Don Lewis 9 year *co arcvid unknown bev Angelo 0:11 *00 alaska unknown What I find hard to believe is that a Unix system would remain up for 9 years even if it were left idle.   Date: Fri, 7 Dec 90 18:17:34 EST From: RS Subject: Re: Computational Cosmology, and the Theology of Unix ... So, patch the kernel on the file server or run sendmail on the server. Am I missing something, or wouldn't it be better to add "-root=foo,bar,baz" to /etc/exports? man 5 exports for information on it... Oh, I get it!!! IH, you told him to patch his kernel, but you forgot to tell him to delete the access control list in /etc/exports, so he ends up with a file that looks like this: / /usr /tmp /home ... It's friendly to provide anonymous FTP service, that's true, but it is so much friendlier to export all your filesystems read-write with root permissions to the entire Internet!   From: IH Date: Fri, 7 Dec 90 19:21:54 EST Subject: Re: Computational Cosmology, and the Theology of Unix Sorry. I should have put in a disclaimer. I haven't been a unix sysadmin for several years now and I haven't tracked the new features sun has put in. What I described was the case when -I- was a sysadmin, but Sun has changed things a great deal since then. ih   From: RM Date: Sun, 9 Dec 90 00:05:23 EST Subject: Why C is better than Lisp Some of you will remember the following (and will probably be able to think of a zillion similar examples - as we like to say "Lisp environments forgive worthless programmers building worthless systems far longer (long enough for them to get into -deep- shit)"): ====================================================================== Date: Fri, 11 Mar 88 16:50 CST From: S Subject: Some People Just Don't Get It This is what happens when a consultant with no LISP experience is paid $1000+/day to do program development in our system. I really think he can't know much about conventional programming, either, though I have this feeling he usually programs in COBOL [I've just been told it's PL/I]. He is employed by a large, well-known consulting firm. Code is verbatim with no indentation changes. There is no mode line in the file. ;********************************************************************** ;** ** ;** FUNCTION NAME: CHECK_FOR_WEEKEND ** ;** ** ;** PERFORMS THE FOLLOWING: ** ;** ** ;** (1) Converts x parameter to a string containing the ** ;** day-of-the-week and stores the string in DAY_DESCRIPTION ** ;** (2) If the first three characters of DAY_DESCRIPTION = "Sat" ** ;** of "Sun", DAY_CHECK is set to 'NOT_OK ** ;** (3) Returns DAY_CHECK ** ;** ** ;********************************************************************** (defun check_for_weekend (x) (setq day_description (time:print-universal-date x nil)) (setq day_check 'ok) (cond ((and (string-equal "S" (string (char day_description 0))) (string-equal "a" (string (char day_description 1))) (string-equal "t" (string (char day_description 2)))) (setq day_check 'not_ok))) (cond ((and (string-equal "S" (string (char day_description 0))) (string-equal "u" (string (char day_description 1))) (string-equal "n" (string (char day_description 2)))) (setq day_check 'not_ok))) day_check) ;********************************************************************** ;** ** ;** FUNCTION NAME: CONVERT_TO_DIV_NUM ** ;** ** ;** PERFORMS THE FOLLOWING: ** ;** ** ;** (1) Converts the division id to a numeric equivalent and ** ;** returns it as a string. ** ;** ** ;********************************************************************** (defun convert_to_div_num (x) (cond ((eq x 'aux) (setq div_num_string "1")) ((eq x 'boi) (setq div_num_string "2")) ((eq x 'com) (setq div_num_string "3")) ((eq x 'con) (setq div_num_string "4")) ((eq x 'ele) (setq div_num_string "5")) ((eq x 'gts) (setq div_num_string "6")) ((eq x 'tur) (setq div_num_string "7")) (t (setq div_num_string "8"))) div_num_string) ====================================================================== Well, I thought I'd like to share the following with you -- found in an actual, shipping, commerical product. The moment I saw this, I thought fondly of CHECK_FOR_WEEKEND: (A key point to realise is that a DOSDATE_T is a record structure with integer fields which represent year, month, day and day-of-week) ====================================================================== /* * earlier_than: * * Compares the date in the first DOSDATE_T structure against the second * DOSDATE_T structure. If the date in the first is earlier than the * date in the second, this function returns 1. Otherwise, it returns 0. */ static int PASCAL earlier_than (DOSDATE_T *fir, DOSDATE_T *sec) { long first_jul = cvrt_tojul (fir); long second_jul = cvrt_tojul (sec); return (first_jul < second_jul ? 1: 0); } /* * cvrt_tojul: * * Converts the DOSDATE_T structure date data to a julian date. */ static long PASCAL cvrt_tojul (DOSDATE_T *date) { char date_str[12]; sprintf (date_str,"%.2d/%.2d/%d", date->month, date->day, date->year); return ((long)tojul (date_str)); } /* * tojul: * * Converts a date string to a julian date. */ static long PASCAL tojul (char *sdat) { long yr; long mo; long da; long ctmp; long dtmp; long mtmp; long ytmp; long result1; long result2; long result3; yr = mo = da = 0; sscanf (sdat, "%d/%d/%d", &mo, &da, &yr); yr += (yr > 60 ? 1900: 2000); if (mo > 2) { mtmp = mo - 3; ytmp = yr; } else { mtmp = mo + 9; ytmp = yr - 1; } ctmp = (ytmp / 100); dtmp = ytmp - (100 * ctmp); result1 = 146097L * ctmp / 4; result2 = (1461 * dtmp) / 4; result3 = (153 * mtmp + 2) / 5; return ((long) result1 + da + result2 + 1721119L + result3); } ====================================================================== Now it should be obvious to you why C is superior to Lisp for all development purposes: The C code doesn't cons.   From: CG Date: Mon, 10 Dec 90 15:47 CST Subject: My SPARCstation is beeping loudly and continuously right now and all because I accidently hit the middle button instead of the left button. I'm running Motif on the damned thing. I had a large region marked. I wanted to click left on an xterm, but I accidently pressed the middle button. This sent lots of data to the shell which is running in the xterm. [ It just stopped, finally] The window system locked up and the speaker just kept on yelling at me. All I did was press the wrong button on the mouse.   From: PS Date: Mon, 10 Dec 90 23:47:16 EST Subject: which One obscene little fact about Unix is that the definition or lack thereof of the shell variable $prompt is usually used to determine whether an invocation of the shell is interactive or is running as an inferior. This is important because an inferior may have input and output piped from or to files, and certain operations may not be defined on streams that don't have a terminal attached to them. My .login file has in it the line setenv EDITOR `which emacs` so that I can invoke Emacs from mail and other Unix-weenie programs. The lab-wide .cshrc has in it a command that reads the terminal parameters when the shell being started is interactive. Unfortunately, the test for interactivity was apparently succeeding when it should have failed; I kept getting messages that said TIOCGETS: operation not supported by socket or something like that. I took my problem to DS, and he eventually looked at the sources for the "which" command: From: DS Date: Mon, 10 Dec 90 18:21:14 EST To: PS Subject: $&%^R&^%&^*%*&^ which command Take a look at this... the comment at the top of the command tells all. For now, I've moved the stty hacker to tcshrc... #! /bin/csh -f # # @(#)which.csh 1.8 88/02/08 SMI; from UCB 4.2 83/02/14 # # which : tells you which program you get # # Set prompt so .cshrc will think we're interactive and set aliases. ...   From: JW Date: Tue, 11 Dec 90 0:10:21 EST Subject: Re: which From: PS Date: Mon, 10 Dec 90 23:47:16 EST My .login file has in it the line setenv EDITOR `which emacs` So that I can invoke Emacs from mail and other Unix-weenie programs. Ah, well, of course. You appear to be using the 'toolkit' approach, in which a variety of small useful software tools are combined in a building block manner, so that great things can be done. Perhaps, some time ago, you read an article or book which suggested that this was the guiding philosophy of Unix. I think the problem is that you missed the great Revelation of July 14, 1989, in which Dennis Richie, at a mass meeting of over one hundred thousand Unix weenies at RFK Stadium in Washington, D.C., announced that the toolkit approach was Obsolete, and would henceforth be replaced by the One Big Hairy Program approach, in which, after linking in the required optional window system, mouse interface, screen manager, and distributed filesystem, simple programs such as the one I am using to type this message would require a guaranteed minimum of 3.5 megabytes of code space alone. And, by God, it's working. Ask S about Motif.   From: MP Date: Tue, 11 Dec 90 12:52:39 EST Subject: Re: which From: PS Date: Mon, 10 Dec 90 23:47:16 EST ... My .login file has in it the line setenv EDITOR `which emacs` Good thing you didn't try putting anything like that in your .cshrc! I did that once and then discovered that the which command is a csh script (as you showed), and therefore, obviously, runs my .cshrc, encountering this line again and reinvoking which. Unix weenies [claim to] invent recursion, but of course they do it wrong. This leads to the marvelous side effect that now when you type any command which under the covers is a csh script, you get the obvious "error: Process table full" (or something like that), of course a ps doesn't show it full.   From: PD Date: Tue, 11 Dec 1990 10:09:44 PST X-Mailer: Sendmail/Ream version 4.15 (The Choice for a New Generation) X-Subliminal-Message: Send me all your money Subject: Re: which > My .login file has in it the line > setenv EDITOR `which emacs` > Good thing you didn't try putting anything like that in > your .cshrc! I did that once and then discovered that the > which command is a csh script (as you showed), and > therefore, obviously, runs my .cshrc, Naw, it's ok, it began "#!/bin/csh -f". The "-f" flag (obviously) suppresses reading .cshrc. Evidently they got caught by that before. It's fun to watch people writing csh scripts where they forget this, and see X fire up every time, etc...   From: CG Date: Tue, 11 Dec 90 12:36 CST Subject: Recursive Weenies Date: Tue, 11 Dec 90 12:52:39 EST From: MP > Unix weenies [claim to] invent recursion, but of course > they do it wrong. Certainly they do it wrong, but as far as inventing something as useful as recursion, I'm afraid not. Lisp, for example, predates Unix by a decade or so, and I'm sure there are earlier examples. Can anyone think of anything good that Unix weenies *did* invent? Most of their inventions such as netnews or case-sensitive languages don't seem to qualify as good things, although I'm sure there are those who think that netnews is a good thing. Maybe the idea of a portable operating system is a good thing, but unfortunately, they only invented the idea, but still haven't come up with an implementation.   Date: Tue, 11 Dec 90 12:40 CST From: CG Subject: Re: which Date: Tue, 11 Dec 1990 10:09:44 PST From: PD > My .login file has in it the line > setenv EDITOR `which emacs` > Good thing you didn't try putting anything like that > in your .cshrc! I did that once and then discovered > that the which command is a csh script (as you > showed), and therefore, obviously, runs my .cshrc, Naw, it's ok, it began "#!/bin/csh -f". The "-f" flag (obviously) suppresses reading .cshrc. Evidently they got caught by that before. It's fun to watch people writing csh scripts where they forget this, and see X fire up every time, etc... Didn't you see this line: if ( -r ~/.cshrc && -f ~/.cshrc ) source ~/.cshrc Need we say more?   Date: Tue, 11 Dec 90 16:33:45 PST From: DW Subject: Something good about Unix? Date: Tue, 11 Dec 90 12:36 CST From: CG Date: Tue, 11 Dec 90 12:52:39 EST From: MP Unix weenies [claim to] invent recursion, but of course they do it wrong. Certainly they do it wrong, but as far as inventing something as useful as recursion, I'm afraid not... Can anyone think of anything good that Unix weenies *did* invent? Actually the other day I finally did run across a good idea I'd never seen before in Unix. That was such an unusual occurrence that I felt I had to mention it to our local unix-worshipper. Of course it would violate the purpose of this list were I to tell you what it was. Maybe the idea of a portable operating system is a good thing, but unfortunately, they only invented the idea, but still haven't come up with an implementation. Multics was written in a high-level language first. ITS ran on the PDP-6 and PDP-10. Sure they came up with an implementation. You just make a machine that looks just like a PDP-11 and you can port unix to it. No problem! The latest idea is to build machines (RISC machines with register windows) which are designed specifically for C programs and unix (just check out the original Berkeley RISC papers if you don't believe me: it was a specific design goal). Now, people tell me that the advantage of a Sun over a Lisp machine is that it's a general-purpose machine ("Of course it's general purpose." they say. "Why it even runs unix."). Hmm, well this example shows that at least the weenix unies know how to USE recursion!   Date: Wed, 12 Dec 90 08:38:18 EST From: RS Subject: Re: Tape Drives Date: Tue, 11 Dec 90 20:07:10 EST From: SS Where else could you define tape drives as virtual hard disks, including dividing their "tracks and sectors" up as mountable partitions? Ooooh! Groovy! # swapon /dev/rmt/0h You always did want 160 megs of paging space, right?   Date: Wed, 12 Dec 90 10:56:02 -0800 From: AB Subject: Re: which I had a similar problem: I wanted to set my PAGER variable to use "less", which could be in any number of places because UNIX people put things all over and have yet to decide *where* a program should live [hence the "which" command]. As we have seen, if you call "which" from your .cshrc, you get royally scrod. I ended up with the following kludge in my .cshrc file: # need the second test because which tries to fool us if ( $?prompt && ( "$prompt" != "" ) ) then setenv PAGER "`which less`" if ( ! -f "$PAGER" ) unsetenv PAGER endif The better solution which I just figured out would be... tty >& /dev/null if ( $status == 0 ) then # is an interactive shell setenv PAGER "`which less`" if ( ! -f "$PAGER" ) unsetenv PAGER endif [note that the second test is in case which tells you "no less in /big/long /hairy /obnoxious /path/list"] ab   Date: Wed, 12 Dec 90 11:03:04 -0800 From: AB Subject: Re: tape drives Date: Tue, 11 Dec 90 20:07:10 EST From: SS Where else could you define tape drives as virtual hard disks, including dividing their "tracks and sectors" up as mountable partitions? Um, ITS? Couldn't you mount DECTapes as virtual disks? I know that *someone* used DECTapes as virtual disks out there [seeking back and forth, rewriting in the middle, etc].   From: AB Date: Wed, 12 Dec 90 14:32:01 EST Subject: Re: tape drives Date: Wed, 12 Dec 90 11:03:04 -0800 From: AB Date: Tue, 11 Dec 90 20:07:10 EST From: SS Where else could you define tape drives as virtual hard disks, including dividing their "tracks and sectors" up as mountable partitions? Um, ITS? Couldn't you mount DECTapes as virtual disks? I know that *someone* used DECTapes as virtual disks out there [seeking back and forth, rewriting in the middle, etc]. Hell man, that's the way you were -supposed- to use a DECtape! DECtape is really a very slow linear disk drive. DECtapes are formatted into blocks just like a disk. ITS users used to keep their files in their own personal DECtape filesystems, which they could carry around and mount when then sat down to use the machine -- just like people walk around today with floppy disks. Just another way ITS was ahead of its time!   Date: Wed, 12 Dec 90 15:18:42 EST From: CZ Subject: Re: tape drives Well, there WAS the time I set the swap drive on my Pdp-11/34 (running RSX11) to use the TU58 Dectape instead of the RM02, and fired up about 10 processes. As I watched the computer flounder away, I thought "this is a good punishment for a bad computer..."   From: GP Subject: Re: tape drives Date: Wed, 12 Dec 1990 14:32 EST From: AB Date: Wed, 12 Dec 90 11:03:04 -0800 From: AB Date: Tue, 11 Dec 90 20:07:10 EST From: SS Where else could you define tape drives as virtual hard disks, including dividing their "tracks and sectors" up as mountable partitions? Um, ITS? Couldn't you mount DECTapes as virtual disks? I know that *someone* used DECTapes as virtual disks out there [seeking back and forth, rewriting in the middle, etc]. Hell man, that's the way you were -supposed- to use a DECtape! DECtape is really a very slow linear disk drive. DECtapes are formatted into blocks just like a disk. ITS users used to keep their files in their own personal DECtape filesystems, which they could carry around and mount when then sat down to use the machine -- just like people walk around today with floppy disks. Just another way ITS was ahead of its time! This wasn't a new idea when ITS did it. The PDP-1 at MIT put a filesystem on their DECtapes. (I used to own one until someone overwrote it with a humanities paper; I loaned out the wrong tape.) In fact, the first few blocks of the DECtape contained the version of the tape software used to create the tape as a guard against incompatible changes to the system.   Date: Fri, 14 Dec 90 10:54:45 PST From: DH Subject: MC:HUMOR;JARGON > The JARGON file is being updated. The guy doing so has changed the nasty references to Unix to refer to MS-DOS because "all the ITS partisans have now become Unix partisans, since the Unix philosophy is the same as the ITS philosophy." as he says.   Date: Fri, 14 Dec 1990 16:52-0500 From: CS Subject: Re: MC:HUMOR;JARGON > Why don't we write a complaintive group letter to the publisher?   Date: Fri, 14 Dec 1990 16:57-0500 From: KP Subject: Re: MC:HUMOR;JARGON > Date: Fri, 14 Dec 1990 13:54 EST From: DH The JARGON file is being updated. The guy doing so has changed the nasty references to Unix to refer to MS-DOS because "all the ITS partisans have now become Unix partisans, since the Unix philosophy is the same as the ITS philosophy." as he says. Isn't there some pending federal law against colorizing things that were originally black and white? Perhaps we should each call our congresspeople and lobby for its immediate passage of that so we can go after this vandal in court...   Date: Fri, 14 Dec 1990 18:25-0500 From: GP Subject: Re: MC:HUMOR;JARGON > Date: Fri, 14 Dec 1990 13:54 EST From: DH The JARGON file is being updated. The guy doing so has changed the nasty references to Unix to refer to MS-DOS because "all the ITS partisans have now become Unix partisans, since the Unix philosophy is the same as the ITS philosophy." as he says. Amazing! A valid argument against gun control ...   Date: Fri, 14 Dec 1990 14:54:11 PST From: KH Subject: Re: MC:HUMOR;JARGON > The JARGON file is being updated. The guy doing so has changed the nasty references to Unix to refer to MS-DOS because "all the ITS partisans have now become Unix partisans, since the Unix philosophy is the same as the ITS philosophy." as he says. YAAAARRGGGH!!! If you would be gracious enough to identify this, um, I believe the proper term is "loser", then we might have the opportunity to clarify our philosophical differences.   Date: Sun, 16 Dec 90 18:24:53 PST From: DH Subject: Re: MC:HUMOR;JARGON > Date: Fri, 14 Dec 1990 14:54:11 PST From: KH If you would be gracious enough to identify this, um, I believe the proper term is "loser", then we might have the opportunity to clarify our philosophical differences. Here's where you may ftp it. Notice the typical weenix unism: it has a very complex version number! Makes me think of the note I have written on my whiteboard: "I was a nobody until I re-implemented shar!" * Date: 16 Dec 90 02:56:11 GMT From: ER Newsgroups: alt.folklore.computers,comp.unix.internals,comp.misc Subject: The Jargon File Version 2.2.1 15 DEC 1990 follows in 10 parts This note should be followed by 10 parts containing the 2.2.1 15 DEC 1990 version of the infamous jargon file. To re-assemble it, simply unshar the parts and cat them together. This file will also be available on dorm.rutgers.edu under pub as `jargon.', where is the digits of the current version number (that is, version 5.6.7 would be `jargon.567'). Future versions up to 2.3.1 (whenever that is) will be posted as context diffs. This version is a draft for a contemplated second paper edition of "The Hacker's Dictionary" circulated to the hacker community for criticism and additions. Your comments and new entries are welcomed; mail them to jargon@snark.thyrsus.com or ...!uunet!snark!jargon. I should point out that GLS is helping this guy. * Shar is a short program for bundling files together -- sorry to expose you to such a unix-ism.   Date: Mon, 17 Dec 90 10:22:22 From: DM Subject: Re: MC:HUMOR;JARGON > > Date: Fri, 14 Dec 90 10:54:45 PST > From: DH > The JARGON file is being updated. The guy doing so has > changed the nasty references to Unix to refer to MS-DOS > because "all the ITS partisans have now become Unix > partisans, since the Unix philosophy is the same as the > ITS philosophy." as he says. Perhaps the saddest part of this is that, in truth, MS-DOS is closer to the ITS philosophy than Unix. But then there's a long tradition of the jargon file being promoted by people who are unclear on the concept, so this is really no surprise. Plus ca change, plus serait merde.   From: DC Date: Mon, 17 Dec 90 11:39:08 -0800 Subject: Unix Fellates Worm-Infested Camels I think I've identified the fundamental problem with unix. It's not that unix fellates worm-infested camels. It's that NO ONE DOES ANYTHING ABOUT IT. Unix is full of dumb bugs that any competent hacker could fix in ten minutes. But more than ten minutes is wasted by *every* hacker instead. ``Yup, that's another dumb unix bug. Sigh. Well, let's write an elaborate work-around...'' The problem is cultural: there seems to be an attitude of ``you can't fight city hall.'' ITS and the lispm are such wins not because they are better-designed (they may be, but god knows they have plenty of brain damage in them too) but because they have a culture of ``That symbolics namespace editor sucks, so I spent ten minutes writing a better one and installed it on b:.'' What I can't figure out is why there isn't a giant market for improved unix software. For example, it seems like it would be straightforward to write a decent C macro processor or garbage collector, and that you could make a bundle of money selling them because everyone would want them. But no one does this. Why not? Maybe it's because weenies are so used to not fighting city hall that they can't believe things could ever be better?   Date: Mon, 17 Dec 90 15:04:18 EST From: MT Subject: Re: MC:HUMOR;JARGON > Date: Sun, 16 Dec 90 18:24:53 PST From: DH From: ER This guy is also a flaming political loony, so make sure to mention that you're an agent of the international communist conspiracy if you write to him (unless you're trying to be persuasive, in which case you should claim to be a sworn enemy of the ICC).   From: IH Date: Mon, 17 Dec 90 15:21:04 EST Subject: Re: Unix Fellates Worm-Infested Camels Unix is a great many things. Unix is not one culture, but many different cultures. The original ideas behind the original implementation of unix were pretty reasonable. I have the sense that the original implementors were pretty reasonable too. They had a particular culture, but I don't know exactly what it is. Then there's the old university unix culture, and within that, the Berkeley-unix culture. All the unix cultures I have encountered have involved fixing things. That's probably its biggest problem. The [smart] unix people I have talked to talk very much like the [smart] ITS people I've talked to. I think the difference lies in the fact that Unix has historically been centered around cheap minicomputers which were owned by small fiefdoms each with a very small number of users. The result was that each person effectively had their own personal copy of unix, and made their own personal bug fixes. They did indeed spend an inordinate amount of time doing that. The problem with this is that it leads to a hacking mentality. I use "hacking" in the sense of "hacking something together", of jury-rigging. The unix culture never developed the notion of production software: software which has been thoroughly tested and which was expressly bomb-proofed during its development. As I've said before, it's research software with research quality. Every program is like a bachelor's thesis which the author didn't really expect to maintain, except possibly for herself. Never mind that the quality of the research is bad or that they're wantonly reinventing wheels.   Date: Mon, 17 Dec 90 15:50:52 From: DM Subject: Re: Unix Fellates Worm-Infested Camels > Date: Mon, 17 Dec 90 11:39:08 -0800 > From: DC > > What I can't figure out is why there isn't a giant market > for improved unix software. For example, it seems like it > would be straightforward to write a decent C macro > processor or garbage collector, and that you could make a > bundle of money selling them because everyone would want > them. But no one does this. Why not? Maybe it's because > weenies are so used to not fighting city hall that they > can't believe things could ever be better? > You really can't figure this out? It's because every tool depends for its operation on the bugs in every other tool, to exaggerate slightly. Thus anyone promoting an improved version of anything runs smack into insuperable compatibility problems. You have to work as hard as Stallman to make any headway at all.   From: DH Date: Tue, 18 Dec 90 08:35:56 PST Subject: Re: Unix Fellates Worm-Infested Camels From: IH Date: Mon, 17 Dec 90 15:21:04 EST The unix culture never developed the notion of production software: software which has been thoroughly tested and which was expressly bomb-proofed during its development. On the other hand they have the syntax: every program comes out with a plethora of "pre-release" version, all with six-part version numbers in full color with circles and arrows on the back. I dunno, personally I preferred the days when programs may have lived in their authors' homedirs, but at least they worked. Requisite unix bd: how come the best this supposedly "open networked" environment can do is pass terminal parameters around by NAME? The machine I'm on has some different interpretation of what "xterm" means so that my screen is continually garbled. Talk about People Unclear on the Concept...   From: AB Date: Tue, 18 Dec 90 16:03:00 EST Subject: Re: MC:HUMOR;JARGON > The `old' jargon file was last revised in 1983; its revisions are all un-numbered and may be collectively considered `Version 1'. So are there any surviving copies of this? The latest I bothered to keep was from 1982. And whatever happened to... The current plan is to turn MC off for good at 5PM on Friday May 25. We plan to take a snapshot of MC's filesystem before the final shutdown and to keep this snapshot available on some other file server for a couple of months. A similar snapshot of AI's final filesystem will be constructed from tape, as soon as the software to do that is finished.   Date: Tue, 18 Dec 1990 12:46:37 PST From: PD X-Mailer: Sendmail/Ream version 4.15 (The Choice for a New Generation) X-Subliminal-Message: Send me all your money > The original ideas behind the original implementation of > unix were pretty reasonable. I have the sense that the > original implementors were pretty reasonable too. It's worth noting that the originators of UNIX, almost to a man, despise current UNIX implementations, and UNIX as it is being touted these days. UNIX-as-perceived is the product of people like Bill Joy, someone whose value can be judged from both the appearance and implementation of vi.   From: PS Date: Tue, 18 Dec 90 18:13:09 EST Subject: Unix All you weenies who are defending Unix and the original implementors of Unix and generally exercising what can only be referred to under the circumstances as an utterly inappropriate sense of fair play should be aware that you are running the risk of being Tafted out of this mailing list. Reason, truth, fairness -- merely captious sophistry, the mark of Unix apologists. Such precepts are of no value whatever where they conflict with our fundamental purpose, which is the denigration, defamation, and, yes, where necessary the calumniation of that ruinous calamity among operating systems: UNIX. Syncretists! Backsliders, apologists, OSF-roaders: you have been warned once. Your next warning will come in the form of righteous justice, unstintingly administered by the champions of orthodoxy.   From: CS Date: Tue, 18 Dec 90 23:40:33 EST Subject: jargon file flamage From: ER Newsgroups: alt.folklore.computers,comp.misc Subject: Jargon file 2.2.1 typos Date: 18 Dec 90 04:59:07 GMT MB at somecompany has done an amazing (and amazingly *fast*) job of catching my typos and bobbles. To relieve the strain on my mailbox, therefore, please *don't* write just to correct spelling and minor grammatical solecisms. However, new entries and factual corrections to old ones are still quite welcome. Negotiations with publishers proceed apace. Y'all may be able to buy a paper copy of this compendium to give your girlfriend/boyfriend/parent/sibling/therapist/dog sooner than I'd have believed a week ago. One outfit I'm dickering with is talking about *8 weeks* from contract to the presses... -- ER From: ER Newsgroups: alt.folklore.computers,comp.misc Subject: Re: the jargon file Date: 18 Dec 90 17:30:13 GMT Followup-To: alt.folklore.computers CS wrote: > ER asserts that "all the ITS partisans have > now become Unix partisans, since the Unix philosophy is > the same as the ITS philosophy", and discusses his new > edition of our old jargon file. I never claimed that the UNIX philosophy is "the same" as ITS's. > In fact, most of the "ITS partisans" are really unhappy, > discouraged, and severely disapproving of this effort to > re-write the jargon file. I've received critical email from two ex-ITS people. I've also received entries, help, and encouragement from at least six others. Not to mention five of the six First Edition authors. The sixth, mrc, is unhappy about some editing decisions I've made but hasn't questioned that the job needs doing. On the evidence available to me, you speak for a minority which includes none of the principal authors of the file. > Also, we are definitely not "Unix partisans". I have been corrected on this in email. I naively thought that because MIT had gone with UNIX and most of the ex-ITSers I know are hacking UNIX these days the ex-ITS crowd could be fairly said to `prefer' UNIX. As it turns out, a lot of ex-ITSers would rather worship the ghosts of departed operating systems and bitch about UNIX rather than implement something they like. I think this is very sad. > It's unfortunate that one of the side-effects of not > taking steps to protect this material is that people can > steal it and use it misrepresent us, but who would have > guessed? I am doing my very damnedest not to misrepresent anybody; the First Edition authors (with whom I regularly discuss my editorial choices) can testify to this. Any ITSer who thinks he's being `misrepresented' by anything in the file is welcome to submit *specific changes* to correct the errors. Bellyaching at me about `philosophy' doesn't help any party unless you're willing to get specific about what you don't like. I am not an autocratic editor, as any number of people who've sent me changes can testify. I'll either merge in the change or explain why I didn't. If after that you still disagree, I'm willing to debate matters in the open. As for `stealing', this is unfair and insulting. You don't own JARGON.TXT and I don't claim to. If anyone has proprietary rights on any of this material it's Guy Steele via the 1983 paper addition, and he emailed the ms of that book to *me* to use as I saw fit. > ER probably isn't doing this out of malice; I'm > sure he just doesn't understand what the jargon file was > really all about. I'm sure I don't understand *your* theory of what it was all about. Your implied claim to authority on the subject is shaky at best. > The rest of us are a little baffled at GS's > cooperation with him. Why don't you *ask* him, then? Here's a clue, closed-captioned for the thinking-impaired: Maybe Guy Steele and I agree that the ITS culture had something valuable to transmit to latter-day hackerdom. Maybe we agree that it's worthwhile that that tradition not be lost, that it add its own flavor to the UNIX-dominated hackerdom of today. Maybe I still believe that. Maybe I'm beginning to doubt it now... Followups to alt.folklore.computers ONLY. -- ER   From: CS Date: Wed, 19 Dec 90 00:23:36 EST Subject: last thing I intend to say about JARGON, I suppose From: CS Newsgroups: alt.folklore.computers Subject: jargon file ER, Apparently you've misconstrued my complaints. I certainly never claimed to have personal ownership over the jargon file; I was relaying the feelings of a large number (probably most, despite whatever you wish to believe) of the members of the community which the original JARGON file documents (or, used to, anyway). I don't know what the legal copyright status of the material is, or what it was when it was published commercially. At least the ethics of commercially usurping community property were and are debatable. I don't really have time or inclination to argue with you about your notions. But imagine if someone took a book that you and your playmates had written about your childhoods, "updated it" to coincide with their very different attitudes (which you, for the most part disagreed with), and then published it under its original title. I think that's part of how a number of us feel. Most of the other MIT-AI people I've talked to seem to feel this way. I don't read this newsgroup, so if anyone wants to correspond about this, you'll have to send me email. But mostly, I'm not very interested. I'm certainly not interested in debating your confused interpretations of what our culture was about, whether myself or my associates represent that culture, nor am I interested in debating the technical merits of random operating systems. My intentions in my previous posting were mostly to clear up various strange assertions regarding the old ITS crowd, and relay my sense of violation. Sometimes I think there's no hope of people ever understanding what was going on back then. Oh, well. I think I've said all I wanted to.   Date: Tue, 18 Dec 90 23:45:54 PST From: DH Subject: jargon file flamage I like the way he capitalizes the phrase First Edition. Probably you didn't realize but it was given to Joseph Smith by Moronai, engraved on a Golden Ampex Disk Pack.   From: IH Date: Wed, 19 Dec 90 09:47:04 EST Subject: Unix From: PS Date: Tue, 18 Dec 90 18:13:09 EST Syncretists! Backsliders, apologists, OSF-roaders: you have been warned once. Your next warning will come in the form of righteous justice, unstintingly administered by the champions of orthodoxy. Oooh boy, that sound's exciting! It makes me all goosepimply just thinking about it. On a more orthodox note however, I will note that given a choice between a $10,000 Mac for my office and a $3000 SPARC with more pixels and memory, and which was twice as fast, I chose the Mac. Mostly because the Mac had software which was good for something (except its text editors), but also because it has an MTBF of > 30min.   From: AB Date: Wed, 19 Dec 90 15:14:51 EST Subject: jargon file I strongly urge everyone who reads Unix-Haters to drop a note to er@al.gol.tla expressing your concern that he may be violating the spirit of the original jargon file. Recall that we have not actually -seen- what he has proposed to do, so don't jump down the man's throat, but I think he could use some reinforcement on the idea that part of the ITS culture was a healthy disrespect for Unix, and that for many of us this is still the case. Be reasonable, calm and brief. Don't antagonize him. just make your point. It would probably help if you can impress him with your ITS credentials. Like if you ever helped maintained ITS, or some ITS system program, be sure to mention that.   Date: Wed, 19 Dec 90 13:36:48 -0800 From: DC Subject: message to ER Date: Wed, 19 Dec 90 13:35:25 -0800 >From: DC To: er@al.gol.tla Hi, I've heard you are working on ai:gls;jargon >, to which I contributed several entries (which appear also in the published version). It seems to me that the file documented a culture that no longer exists, because it was tied to a particular period, particular long-dead machines and networks, and particular institutions that have changed unrecognizably. It doesn't, therefore, seem meaningful to revise it. It is a spendid idea to document (for instance) current unix culture, but such a document should be clearly distinct from The Hackers' Dictionary, not a revision. It should have a new title, and perhaps a different format. It should *not* include words from jargon > that are not current (as, I think, relatively few are). Making a new book a ``revision'' of jargon > would imply a kind of continuity between late-70s ARPANet culture and early-90s unix culture that simply doesn't exist. To do so would confuse members of the latter culture and annoy members of the former. Contemporary unix culture contains many more people than the group jargon > was written for and about. They would be best served by an entirely new book that documents their own jokes and terminology in a way that reflects the contemporary style.   Date: Wed, 19 Dec 90 17:01:54 From: DM Subject: Re: message to ER Well done! I could never have written such a calm, rational, and incontrovertible essay myself.   Date: Wed, 19 Dec 90 16:18 CST From: CG Subject: message to ER Here's the body of my message to him. I seem to have misplaced the headers: I've seen forwardings of your postings on alt.computers.folklore about the jargon file and understand that some ITS hackers are less than thrilled by some of your modifications of the file. It may be that your intentions have been misrepresented to me, but if not, I have a few things to say. I was barely an ITS hacker (although I had an account on AI for a while), but instead went through RSTS, NOS, and Genera before getting stuck with Unix, so I don't quite have the same purist attitude that some of them may have. However, if it is indeed true that you're altering insults about Unix to be about MSDOS instead, this *does* bother me. It bothers me because it sounds like you're revising history. New insults about MSDOS are fine (as well as insults about RSTS, NOS, or Genera), but you aren't reporting on a culture if you make these changes. To remove the anti-Unix slurs in a documentation of computer culture would be like rewriting history to say that Ronald Reagan was elected unanimously and that nobody opposed any of his policies. A documentation of the computer culture as it exists on Unix hosts today could be interesting, but I respectfully request that you not modify the ITS era entries as you add new ones. You should, however, document what part of the culture they came from. As I recall, the original jargon file spoke of Stanfordisms and MITisms. Most of the original jargon file should be listed as ITSisms. Note that it would be worth doing the reseach to find out what other cultures they might exist in such as Multics, Genera, VMS, etc. The computer culture is not a single culture, but is a number of different cultures. In fact, proper research should document phrases as saying that they developed in the ITS user community as such-and-such, and then migrated into the Unix community as so-and-so. Certainly, if a phrase or piece of terminology was only used in the ITS community, it shouldn't be rewritten so that it could be used in the Unix community. Your purpose should not be to provide people with a collection of cute things to say, but instead to document what people *do* say. I find that it's interesting that none of the registered unix-haters had anything to do with your version of the file. You'd probably not be getting jumped on if you'd contacted us and asked if we'd like to review what you were doing. This file really shouldn't be made Unix-centric, and to allow non-Unix-philiacs a review might help to keep you intellectually honest. Besides, the phrase "MSDOS weenie" doesn't have the same ring to it as "Unix weenie", and "Weenix" can't be translated into anti-MSDOS-speak at all. "MSWeenos"?   Date: Wed, 19 Dec 90 18:08:22 EST From: RS Subject: Unix From: PS Date: Tue, 18 Dec 90 18:13:09 EST All you weenies who are defending Unix and the original implementors of Unix and generally exercising what can only be referred to under the circumstances as an utterly inappropriate sense of fair play should be aware that you are running the risk of being Tafted out of this mailing list. Actually, Unix and C are part of the Con's sinister set of creativity-draining tools. C is at the root of the problem. Brain damage being hereditary, every piece of software will inherit a greater or lesser part of it - every so often there are wonder children like display postscript, but time after time, C's bastard offspring takes the form of a granite monolith like X (which takes over a page and a half of code to do "hello world"). Programmers tend to lose sight of the original goal when they have to deal with this sort of crap. As the government pushes through infringement after infringement on personal liberty (gun control, war on drugs, high taxes with little or no services in return), other Tools of the Conspiracy are pushing Motif, POSIX, OSI, NeXT Step... the list goes on. Unix is but a small piece of a Master Plan to reduce everyone's brain to the consistency of cold cream of wheat so that they will be in no position to pose a threat to the Con's agenda. Like any dictatorship, they are going after intellectuals first. This accounts for the fact that there are no consumer-oriented Unix machines... Reason, truth, fairness -- merely captious sophistry, the mark of Unix apologists. Such precepts are of no value whatever where they conflict with our fundamental purpose, which is the denigration, defamation, and, yes, where necessary the calumniation of that ruinous calamity among operating systems: UNIX. NO! These people are agents of the Con! Calling them apologists would only be too kind! Mount your defense now, while you still can! PS: Unix security tip of the week (keeps people from booting your system single-user and becoming root): # cp /dev/null /etc/init   From: NZ Date: Wed, 19 Dec 90 18:50 EST Subject: New version? Can we see? I think very few of the people who are arguing about your changes to JARGON > have actually seen the new version. If you mail it to me (or give me a pointer) I will make it available for FTP in a place very close to the last version of the original, on MC.   From: NC Date: Wed, 19 Dec 90 18:33:14 EST Subject: Re: jargon file flamage >From: DH >Date: Tue, 18 Dec 90 23:45:54 PST >Subject: jargon file flamage > >Probably you didn't realize but it was given to Joseph >Smith by Moronai, engraved on a Golden Ampex Disk Pack. Is this Tim Moronai?   Date: Wed, 19 Dec 1990 22:31-0500 From: CS Subject: message to ER Great message!   Date: Wed, 19 Dec 90 20:39:53 -0800 From: DC Subject: ER's reply to me [ Apparently he found my message less compelling than some of you did.] Are GLS, RMS, et al. being wedged, is this guy's project being misrepresented to us, or is he misrepresenting their support? Or what? (Sigh.) (What can you expect from someone who signs himself ``the mad mastermind of TMN-Netnews?'' We used to throw highschool students off AI for lesser infractions...)] >From: (ER) Subject: Re: your mail To: DC Date: Wed, 19 Dec 90 18:14:12 EST > Making a new book a ``revision'' of jargon > would imply a > kind of continuity between late-70s ARPANet culture and > early-90s unix culture that simply doesn't exist. I disagree, and so do GS and RS and the other four major authors of the original Jargon File. > To do so would confuse members of the latter culture and > annoy members of the former. So far, the only people who have seemed either confused or annoyed are a couple of rather troglodytic ex-ITSers. The UNIX culture loves what I'm doing, I'm swamped with new entries and supportive email. And I've gotten more help than criticism from ITS alumni. Quite frankly, I've concluded that the only people offended by the idea of jargon 2.x.x are people I don't mind offending. I hope and trust you are not among them. Would you like to enter changes or additions to your previous entries, or submit any new ones? -- ER = er@al.gol.tla   From: MC Subject: Re: the jargon file Date: 19 Dec 90 17:14:19 GMT In article <1YqWpR#1YnZJF2ktJM020ODXT8YVbVG=er@al.gol.tla> ER writes: > On the evidence available to me, [CS] speak[s] for a > minority which includes none of the principal authors of > the file. > > I am doing my very damnedest not to misrepresent anybody; > the First Edition authors (with whom I regularly discuss > my editorial choices) can testify to this. These statements are out-and-out lies. ER has *never* communicated any of his editorial choices to *me* until I took him to task for it on alt.folklore.computers. Then all he did was send me a message saying, in effect, "tough shit, ITS and the PDP-10 are dead and it's too bad if you don't like it." From what Guy Steele sent me in private, I doubt that he is correctly representing Guy either. The issue was *never* one of PDP-10/ITS vs. Unix. The PDP-10/Unix war was settled years ago. The issue is whether or not you brand an entire culture "extinct" just because the environment which birthed that culture has died. That culture is alive and well today, having successfully transplanted itself to Unix and reimplementing the beloved features of the old environment on top of Unix.   From: IH Date: Thu, 20 Dec 90 09:36:05 EST Subject: Raymond's reply to me Date: Wed, 19 Dec 90 20:39:53 -0800 From: DC [ Apparently he found my message less compelling than some of you did. Are GLS, RMS, et al. being wedged, is this guy's project being misrepresented to us, or is he misrepresenting their support? Or what? (Sigh.) (What can you expect from someone who signs himself ``the mad mastermind of TMN-Netnews?'' We used to throw highschool students of AI for lesser infractions...)] Perhaps someone should package this stuff up and send it to GLS and RMS (I never had much of a chance to hack ITS so I don't think I should do it) and ask if they are being accurately portrayed. If not, one might consider sending a note to this guy's publisher just to let them know what's going on.   Date: Thu, 20 Dec 90 14:09:18 EST From: RS Subject: who hates what... From: PD It's worth noting that the originators of UNIX, almost to a man, despise current UNIX implementations, and UNIX as it is being touted these days. UNIX-as-perceived is the product of people like Bill Joy, someone whose value can be judged from both the appearance and implementation of vi. It's probably also true that Gary Kildall (who wrote CP/M) hates MS-DOS. And I know a lot of old RSTS/E people who wouldn't wish VAX/VMS on their worst enemies. (actually, I wouldn't wish Unix on my worst enemies either) Just because the original product was smaller (creating less total lossage) doesn't mean that it was any less horrendus on a percentage basis. And Unix is fertile ground for hunting for lossage. I mean, how many {operating systems, software packages, computers} are so horrible that they can support a mailing list upon which people talk about how badly they suck.   From: PB Date: Thu, 20 Dec 90 19:03:08 EST To: gs Subject: jaron file redux hey quux, we have been hearing rumors about some guy out in east overshoe who intends to publish a revision of the jargon file (as previously lifted by you off the ITS machines, where it had been a communal construct, and published in some random fashion). it sounds like what he intends to do is RE-WRITE a bunch of the entries to change their intent from denigration of unix to denigration of some pc system (msdos?). that, of course, would be a significant alteration from the original aim of the file, and a lot of ITS lovers are objecting. this fellow has been contacted online, and he claims he is working with you, RMS, and "most of the other original authors", which he claims to number about 4 more. what is the story?   From: CG Date: Thu, 20 Dec 90 18:11 CST Subject: How would you route ? The message of 20 Dec 90 16:21 CST from eric@cbmvax!snark.thyrsus.com, The message of 20 Dec 90 16:21 CST from ER Message-Id: <19901221001101.5.7THSON@GLOWWORM.LispM.SLCS.SLB.COM> Needless to say the unix program nslookup is incapable of looking up his "host". The curious thing is that my mail to him appears to have gone somewhere. I wonder where. Anyway, I'm going to be nice to him until I can get a copy of the file. ========== Begin Forwarded Messages ========== From: ER To: CG Date: Thu, 20 Dec 90 16:21 CST Subject: Re: Jargon file Thanks for your thoughtful and temperate letter. I am preparing a posting which I think will address most of your criticisms, but there was one in paricular I wanted to respond to privately. > I find that it's interesting that none of the registered > unix-haters had anything to do with your version of the > file. You'd probably not be getting jumped on if you'd > contacted us and asked if we'd like to review what you > were doing. This file really shouldn't be made > Unix-centric, and to allow non-Unix-philiacs a review > might help to keep you intellectually honest. Quite frankly, I didn't know unix-haters *existed* until a week ago -- then I asked Gumby how I could join. He rejected the idea. I would very much *like* to have several certified UNIX-haters in the loop. Care to volunteer? > Besides, the phrase "MSDOS weenie" doesn't have the same > ring to it as "Unix weenie", and "Weenix" can't be > translated into anti-MSDOS-speak at all. "MSWeenos"? Nah. ``Ween-DOS''. So you know how serious I am about unbiasedness...could I get you to write up WEENIX and UNIX WEENIE for the new file? -- ER = er@al.gol.tla =========== End Forwarded Messages ===========   From: CG Date: Thu, 20 Dec 90 18:24 CST Subject: I'm impressed that this address actually works I got mail with headers that looked like this: Return-Path: Received: from uunet.UU.NET by SLCS.SLB.COM (4.1/SLCS Mailhost 3.12) id AA17313; Thu, 20 Dec 90 17:46:38 CST Received: from cbmvax.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA20824; Thu, 20 Dec 90 18:44:23 -0500 Received: by cbmvax.cbm.commodore.com (5.57/UUCP-Project/Commodore Jan 13 1990) id AA03744; Thu, 20 Dec 90 17:30:42 EST Received: by snark.thyrsus.com (/\=-/\ Smail3.1.18.1 #18.14) id ; Thu, 20 Dec 90 17:21 EST Message-Id: From: eric@cbmvax!snark.thyrsus.com (ER) Date: Thu, 20 Dec 90 17:21:48 EST Subject: Re: Jargon file Naturally, I didn't think that "cbmvax!snark.thyrsus.com" looked like a very likely hostname, but astoundingly this mail appears to do the right thing: My resolver finds an MX record for *.thyrsus.com via UUNET.UU.NET, and I send the message there. Once there, the address must get UUCP'd into "cbmvax!snark.thyrsus.com!eric" which does the right thing. However, the fact that it works does not mean it should be done. My mailer would have every right to look at the @ before the ! and declare the address invalid. You're lucky that I'm an Internet-only site. Some UUCP sites might see this as `user "snark.thyrsus.com" on host "eric@cbmvax"'. CG Postmaster@Someplace   From: KJ Date: Fri, 21 Dec 90 11:55:00 EST Subject: Re: I'm impressed that this address actually works w.r.t. From: eric@cbmvax!snark.thyrsus.com (ER) Of course this is really some sort of header munging problem but... CG writes: > Naturally, I didn't think that "cbmvax!snark.thyrsus.com" > looked like a very likely hostname, but astoundingly this > mail appears to do the right thing: > > My resolver finds an MX record for *.thyrsus.com via > UUNET.UU.NET, and I send the message there. Once there, > the address must get UUCP'd into > "cbmvax!snark.thyrsus.com!eric" which does the right > thing. Here at UUNET, we look in our routing tables as see that mail for thyrsus.com should be UUCP'd to snark. So that's what we do, rewriting eric@cbmvax!snark.thyrsus.com to cbmvax!snark.thyrsus.com!eric and uux'ing the resulting path to rmail on snark. > However, the fact that it works does not mean it should be > done. My mailer would have every right to look at the @ > before the ! and declare the address invalid. Why? The address is valid. There is an MX record for cbmvax!snark.thyrsus.com. There needn't be an actual host corresponding to that name as long as _some_ real Internet host will handle the mail. > You're lucky that I'm an Internet-only site. Some UUCP > sites might see this as `user "snark.thyrsus.com" on host > "eric@cbmvax"'. UUCP-only sites shouldn't be seeing @'s in the first place. It is the job of network gateways (such as UUNET) to do conversions as required for the networks they gateway. So some Internet->UUCP gateway should have rewritten the address to bang form before the UUCP-only site received it. The Internet hosts can follow their rules, and the UUCP hosts can follow theirs, and with gateways doing the necessary conversions, there needn't be any problems. kj   From: GS Date: Fri, 21 Dec 90 12:05:12 EST Subject: Re: jargon file redux Date: Thu, 20 Dec 90 19:03:08 EST From: PB hey quux, we have been hearing rumors about some guy out in east overshoe who intends to publish a revision of the jargon file (as previously lifted by you off the ITS machines, where it had been a communal construct, and published in some random fashion). it sounds like what he intends to do is RE-WRITE a bunch of the entries to change their intent from denigration of unix to denigration of some pc system (msdos?). that, of course, would be a significant alteration from the original aim of the file, and a lot of ITS lovers are objecting. this fellow has been contacted online, and he claims he is working with you, RMS, and "most of the other original authors", which he claims to number about 4 more. what is the story? The project started out as an expansion and slight revision of the file, with a view toward eventual distillation into another book. By "the other original authors" he is referring to the set of names on the first book: Richard Stallman Geoff Goodfellow Raphael Finkel Mark Crispin Don Woods myself who were on it because they had made substantial contributions both to the file and to the polishing of the book version. I would certainly not want anyone to understand from this that these were the only contributors to the original file! Anyway, Eric cut loose and published several updated versions of the file to today's hacker community, which, for better or for worse, is much more UNIX-oriented than that of ten years ago. He has gathered tremendous amounts of new material, much of it interesting. To the extent that we augment the file, I think it's great. Historical revisionism is, however, highly inappropriate, and there is some debate over the designation and treatment of "obsolete" entries.   From: DM Date: Fri, 21 Dec 90 13:26:17 EST X-Subliminal-Message: unix rots Subject: Re: jaron file redux In the Tech Square basement where they kept the CADR carcasses they now have growing pods, hackers emerge saying 'email' instead of 'netmail' but you can really confuse them by saying 'enews' instad of 'netnews' although I suspect this will be changed in the next release by Eric "the Flute" Raymond.   Date: Fri, 21 Dec 90 19:41 EST From: NZ Subject: From ER ... I received this yesterday from ER, asking me to forward it to unix-haters. Not sure why he didn't just post it himself. Perhaps he thinks the list might be moderated :-) ... I'm going away for a week, so it might be awhile before the ascii copy of the "new" jargon file shows up. Mary Xmas, - nick ---- Forwarded Message Follows ---- In the last several days I have received a number of letters from ex-ITS hackers in regard to my effort to update and publish a 1991 Jargon File. I have responded individually to a couple of these notes, but now feel the interests of all parties are best served by a consolidated response which collects and amplifies points I have made in private email. This posting is directed in particular to: DC JR DH CS CG DP DM DM SM AM A copy is also going to NA, who has kindly offered to advertise a copy of the current text on sdl so the ex-ITSers nearby can get a look at it. I will send it to him as soon as I have caught up on the current batch of submissions. The criticisms I have received share a number of common themes: 1. That any claim of connection to the old on-line JARGON.TXT or Steele-1983 can only be a pretense and should be dropped. 2. That the UNIX and ITS cultures are definitely separate and that mixing ITS jargon with new material is confusing or misleading. 3. That I do not understand the ITS culture, am thus unequipped to represent it, and should leave it and its artifacts alone. 4. That the effort necessarily "rewrites history" in a way that would misrepresent the attitudes and ideas of ITS people now and in the past. 5. That ITS-derived entries should not be changed; that the most updating acceptable to ITSers would be to publish an annotated edition, with new material kept rigidly separate from the old. 6. That the name of the effort should not be `the Jargon File' but something different. 7. That the new material is UNIX-centric. In what follows, I will try to answer these points one by one. 1. That any claim of connection to the old on-line JARGON.TXT or Steele-1983 can only be a pretense and should be dropped. False by the most obvious test -- Guy Steele didn't think so, he sent me softcopy of Steele-1983 to merge in, and I have done so. The new File incorporates nearly the entire text of the most recent JARGON maintained on prep.at.dot.dot. The revision was begun quite intentionally as an update of that material, though I had no idea at that time that a weekend hack was going to turn into a mega-project and a book. Therefore, whether jargon-2.x.x is an evolutionary descendent of JARGON.TXT cannot be in question; by every test, it certainly is. Whether that continuity validly reflects a cultural continuity is a fair question. 2. That the UNIX and ITS cultures are definitely separate and that mixing ITS jargon with new material is confusing or misleading. This is also false, though I am beginning to understand why ITSers tend to believe it. I first read the Jargon File while I was an ITS tourist fourteen years ago. At that time the ITS culture cast a long shadow over the ARPAnet -- not the least because lots of people far outside MIT were impressed by the humor and spirit of the old Jargon File. Many of us adopted the File's slang as our own, feeling that we'd found a tangible sign of the community of minds we'd half-guessed to be out there. As UNIX burgeoned and USENET grew, the ITS influence receded in relative importance but remained with us as a recognizable and honored strain in the evolving poly-culture of the net. Even though I call myself a UNIX hacker these days and haven't seriously hacked LISP for nearly ten years, FROB and MOBY and all the rest have been part of my cultural heritage for half my life -- and this is *not in the least unusual*! Yes, the UNIX community has an identity of its own. But enough of us have the old JARGON.TXT as part of our roots that it would have done gross violence to history *not* to start from there. 3. That I do not understand the ITS culture, am thus unequipped to represent it, and should leave it and its artifacts alone. I don't claim perfect understanding; I don't need to. I am not interested in eulogizing bygone days, but in creating a document that speaks to present ones. If you want history, well, JARGON.TXT is out there. I suppose one might claim that I never knew the `real' ITS culture at all, only its reflection in the File. I could probably argue that, because (among other things) I've known RMS for more than ten years, visited the Lab back in the days of its glory, read a lot of the folklore, and heard many of the war stories from one point of view or another. But I don't need to argue that either, because I'm not really interested in `representing' ITS culture per se and don't pretend to be doing so. Yes, I think the ITS tradition had and still has much to offer (it would be damn silly of me to think otherwise, considering that I'm typing this in EMACS). But I didn't go into this intending to represent anybody at all, just to distill some history and reports of current usage into an educational and amusing whole. That leads straight to: 4. That the effort necessarily "rewrites history" in a way that would misrepresent the attitudes and ideas of ITS people now and in the past. This is really hubris. The wider culture doesn't think of the file as a historical document, but as a collection of intellectual graffiti. To the extent that it *is* a historical document, it's become mythic history to all of us -- a sort of hacker-culture Matter of Britain indirectly chronicling the adventures of the Knights of the Lab as they strove against darkness and ignorance. That the real people involved had feet of clay, and that things have changed a lot since then, is understood. This oversimplifies in its own way, of course. It's also possible to question just whose history the file mythologized on a more factual level. The claim that my effort would rewrite ITS history in particular assumes a cathedral-like purity the original didn't possess -- or am I just imagining all the stuff from SAIL and WPI and CMU and elsewhere? 5. That ITS-derived entries should not be changed; that the most updating acceptable to ITSers would be to pub an annotated edition, with new material kept rigidly separate from the old. I have neither the ability nor the desire to nuke all existing copies of JARGON.TXT. That should be sufficient answer by itself. However, I do feel compelled to add that there seems something faintly ludicrous about treating the File as a sacred, untouchable icon. Where has the keen irreverence that was so much of the original's appeal gone? Must I conclude that many of the playful geniuses of 1977 have soured into a misanthropic gang of navel-gazing fuddy-duddies? That the only role they can now imagine for the File is one which exalts history and makes only the most grudging concessions to time and change? I hope not. But more than once on this long strange trip I've felt a weird sense of dislocation, of disbelief, of sadness -- because, among other things, too many of the people willing to condemn the new File have done so on the basis of rumor, without having read it or offered constructive criticisms. I simply could not reconcile the bold, youthful spirit of the original File with the peevish chuntering now emanating from some of its would-be defenders. To be fair, though, many critics do have the name issue separated from the content issues. This leads to: 6. That the name of the effort should not be `the Jargon File' but something different. There have been times I was almost tempted to agree with this -- until I thought about the contributions and reactions of the vast majority of the people who've seen it. The revision process has acquired a momentum of its own -- the fact that I've done it in public has changed the very conditions under which we can debate what `is' or `is not' the One True Jargon File. To the USENET and the whole world other than the last ITS purists, what I'm collecting *is* `the jargon'; functionally, linguistically, and mythically this document is as intimately related to JARGON.TXT as it could possibly be and remain a celebration of the present -- and if I were to change the official name to pacify disgruntled ITSers, the net would just nod and go on calling it the Jargon File! But even that ducks the most fundamental issue. Even if I *had* the power to make people think of 2.x.x as something else, *I wouldn't do it*. It was long past time for JARGON.TXT to be superseded -- it just isn't representative any more; it no longer fills the communal needs that originally earned it a special place in hacker folklore. I guess I was responding to this in a half-conscious way when I began the revision. I'm very conscious about it now, having received bucketfuls of email expressing the most touching gratitude for the drafts I've posted, from old-timer and newbie alike. It is clear that the new File, even in the rough, typo-ridden form publicly seen so far, *does* fill those needs. Please understand that I claim no special prescience about this; in a weird way I even doubt I deserve much of the credit. When I started, I was simply responding as a member of my culture to a conspicuous gap; if it hadn't been me, it would've been somebody else (quite possibly someone without my ties to the historical ITS who would have had far less respect for the older parts of the material). Finally, there is: 7. That the new material is UNIX-centric. Of all the criticisms levelled at the effort, I think this is the single one that really troubles me -- because I agree that it may be a problem, and I'm not sure how I can fix it. I could dismiss it by arguing that hacker *culture*, taken as a whole, is now UNIX-centric; and that such a bias is appropriate, and part of the flavor, just as (say) the anti-Multics bias in JARGON.TXT was in relation to the TOPS-10 and ITS-dominated culture it was describing. I have two problems with this. The first, which is more personal, is that (even though I believe it's true) if I heard it from somebody else it would sound lazy, too easy a copout for a guy who happens to be a professional UNIX wizard living in a USENET world. The second, which is more `social', is that it clearly raises the risk of discounting and smothering contributions from vigorous `minority' computing cultures that might otherwise add breadth and color to the File. I have tried to address the problem by making a special effort to cultivate respondents from non-UNIX technical cultures (Mac fans, Multics people, MS-DOS hackers, etc.) To some extent I've been able to lean on my own career history, which happens to span an unusually broad range of machines and languages. And there are a lot of entries from inside -- of all places -- *IBM* in the File. Nevertheless, I feel continuing concern about this, and it is a respect in which I would appreciate constructive help from ex-ITSers and everybody else. Please -- rather than complaining that I am "rewriting history", *help me write it*! I would *like* to have entries for `UNIX WEENIE' and `WEENIX' that are just as funny and snide as JARGON.TXT was about other things, preferably entries written by a certified unix-hater with a cursor dipped in acid. More generally, I would *like* to have entries that skewer present computing environments by comparing them to `stone knives and bearskins', providing only that they adduce something suitably illuminating and funny about ITS or their targets. Please read the new File. Think about it. And then ask yourselves what you can do that's *constructive*, that adds to the richness of the culture and represents your viewpoints within it, rather than simply trying to stop the effort or redirect it away from any particular herd of sacred cows. And more than that -- this will be a book. I want it to be a *good* book. I want it to capture the exuberance and vitality of our *shared* culture. I want it to present a positive picture in this decade when legal trends and the acts of a criminal minority threaten to erode the freedom to explore that we've all enjoyed and taken for granted. Please help me show that the true-hacker spirit is still alive. -- ER = er@al.gol.tla   Date: Fri, 21 Dec 90 21:07:21 EST From: RS Subject: Re: I'm impressed that this address actually works From: KJ w.r.t. From: eric@cbmvax!snark.thyrsus.com (ER) CG writes: > Naturally, I didn't think that > "cbmvax!snark.thyrsus.com" looked like a very likely > hostname, but astoundingly this mail appears to do the > right thing: > > My resolver finds an MX record for *.thyrsus.com via > UUNET.UU.NET, and I send the message there. Once > there, the address must get UUCP'd into > "cbmvax!snark.thyrsus.com!eric" which does the right thing. Here at UUNET, we look in our routing tables as see that mail for thyrsus.com should be UUCP'd to snark. So that's what we do, rewriting eric@cbmvax!snark.thyrsus.com to cbmvax!snark.thyrsus.com!eric and uux'ing the resulting path to rmail on snark. Pretty rude if you ask me. For instance, suppose Joe Blow gets his feed from you, and feeds Fred Fool, who has a machine that for some random reason, he's named "ucbvax". Now, your mailer, when confronted with "uunet!blow!ucbvax!fool" will say "Aha, I know where ucbvax is!" and gratuitously reroute the mail. Now, I know that there aren't *supposed* to be duplications in the flat namespace of UUCP-land, but UUCP allows explicit routing, and messing with it is pretty anti-social. If I want you to impose your wisdom about the shape of the world on me, I'll use the percent hack. Hey, after having to suffer with it for a year, does R still think that going from a Sequent to a Pyramid was a good idea? (heh, heh)   From: JW Subject: [mmdf@alfa.beta.gamma: Failed mail (msg.aa07457)] Date: Fri, 21 Dec 90 21:23:43 EST Well. Here is either a mailer with a mind of its own, or some unix user who is a bit unclear on the concept. Wonder which? Date: Fri, 21 Dec 90 17:00:43 EST From: mc Mail System (MMDF) Subject: Failed mail (msg.aa07457) Your message could not be delivered to 'bboard-recipients@bale.alfa.kappa' for the following reason: ' rthu off for holidays... User unknown'   Date: Sat, 22 Dec 1990 00:17:24 PST From: ML To: eric@thyrsus.snark.com Subject: real hackers Removing PDP-10 jargon is like removing hackers. The fact of the matter is, that all real hackers have at one time hacked PDP-10's. The PDP-10 was the ultimate hackers machine. And, although Unix has been ported to almost every computer architecture known to man, it still hasn't been ported to the machine all real hackers come from. In fact, the PDP-10 designers had the forethought to make a machine that would be difficult, inefficient and ugly to port any brain-damaged operating system or language to. They put in lots of accumulators, and hid them in the address space, to confuse compiler designers. They made byte pointers different from addresses, to prevent people from designing ambiguous syntax languages. They made sure case could be converted between upper and lower in just three instructions, so people wouldn't write case-sensitive code. They didn't allow byte-addressing, so byte swapping would be unheard of, and bytes would always be in the proper order. They made the word size a multiple of 3 bits, so people would use octal over hex. They made numerous instructions that did the same thing, to allow the hacker to impart his own personal style in the code. They allowed return-plus-one and skip, so that all subroutines could return a true/false condition as a side-effect. And they called it the PDP-10, because names don't matter.   From: MY Date: Sun, 23 Dec 90 16:19:19 EST Subject: Think how much faster and more efficiently this smaller program is able to trash the filesystem compared to a bloated AI-weenie one (which would all its time checking for uninitialised variables, doing bounds checking, allocating and freeing storage, actually caring about exceptional cases, signalling errors, etc.) Sender: MY From: KB Newsgroups: comp.bugs.4bsd.ucb-fixes Subject: V1.92 (4.3BSD-Reno fsck fix) Date: 14 Dec 90 00:10:24 GMT Organization: University of California at Berkeley Subject: 4.3BSD-Reno fsck fix Description: There is an uninitialized variable in the version of fsck(8) distributed with 4.3BSD-Reno which can cause fsck to destroy the file system instead of repair it. Note, this problem is ONLY found in 4.3BSD-Reno systems. Fix: Apply the following patch: [...]   From: CS Date: Mon, 24 Dec 90 03:25:53 EST Subject: life in hell I'm honestly not sure whether it's the fault of my terminal emulator, or a bug in the TERMCAP entry. But I don't get enough newline padding. This makes finger entries always print out with the line: hell: /bin/csh   From: KJ Date: Wed, 26 Dec 90 14:58:52 EST Subject: Re: I'm impressed that this address actually works w.r.t. From: eric@cbmvax!snark.thyrsus.com (ER) CG writes: > My resolver finds an MX record for *.thyrsus.com via > UUNET.UU.NET, and I send the message there. Once there, > the address must get UUCP'd into > "cbmvax!snark.thyrsus.com!eric" which does the right > thing. KJ writes: > Here at UUNET, we look in our routing tables as see that > mail for thyrsus.com should be UUCP'd to snark. So that's > what we do, rewriting eric@cbmvax!snark.thyrsus.com to > cbmvax!snark.thyrsus.com!eric and uux'ing the resulting > path to rmail on snark. RS writes: > Pretty rude if you ask me. For instance, suppose Joe Blow > gets his feed from you, and feeds Fred Fool, who has a > machine that for some random reason, he's named "ucbvax". > Now, your mailer, when confronted with > "uunet!blow!ucbvax!fool" will say "Aha, I know where > ucbvax is!" and gratuitously reroute the mail. No, it will not. UUNET is a passive rerouter. In the above example UUNET would reroute only if it did not have a direct conenction to `blow'. In that case UUNET would try to find a path to `blow', NOT `ucbvax'. If UUNET could not find a path to `blow', then it would return the mail to sender. In the case of "eric@cbmvax!snark.thyrsus.com", we rmail to `snark' instead of `cbmvax' because `snark' handles mail for all subdomains of "thyrsus.com". "cbmvax!snark.thyrsus.com" is such a subdomain as far as the Internet is concerned.   From: CG Date: Wed, 26 Dec 90 14:09 CST Subject: Re: I'm impressed that this address actually works All I have to say about this is to repeat I said in the original message: "the fact that it works does not mean it should be done" "user@node!host.domain" shouldn't have been generated in the first place. That fact that mail to that address worked is amazing, but it's a situation which should never have arisen in the first place.   From: KJ Date: Wed, 26 Dec 90 16:18:24 EST Subject: Re: I'm impressed that this address actually works CG writes: > All I have to say about this is to repeat I said in the > original message: > > "the fact that it works does not mean it should be done" > > "user@node!host.domain" shouldn't have been generated in > the first place. That fact that mail to that address > worked is amazing, but it's a situation which should never > have arisen in the first place. I agree. Does anyone know what host is responsible for the header mangling? I've received mail from snark and the headers looked fine.   Date: Sat, 29 Dec 90 15:23:44 EST From: SS Subject: [postmaster@GATE.SWITCH.SWITCH.ARCOM.CH: SWITCH.ARCOM.CH Mail Network -- failed mail] I guess the spate of recent subway accidents in Boston and New York proved to be too much for at least one unix mailer. Or perhaps it's a flu-season thang, and it needs some Dristan. ------------------------------------------------------------------------------ Date: Sat, 29 Dec 90 21:18:31 +0100 To: SS From: SWITCH.ARCOM.CH Gateway Subject: SWITCH.ARCOM.CH Mail Network -- failed mail ----- Mail failure diagnostics ----- Message Recipients: concrete@mee.munge.fondue: MTA congestion ----- Unsent message follows ----- From: SS To: wave@alfa.gamma.chai Cc: hackers@alfa.gamma.chai Message-ID: <9012272117.AA29771@alfa.gamma.chai> ...   Date: Tue, 1 Jan 91 17:25:11 EST From: RS Subject: This Is What Worries Me Eric the Flute's credibility has just taken another nose-dive... you would expect someone who claims to be a purveyor of net history and lore to at least get the dates right when he's lying... From: DH Newsgroups: alt.folklore.computers Date: 28 Dec 90 22:08:22 GMT Date: 27 Dec 90 07:17:26 GMT From: ER For the record, I have been a GNU contributor and supporter since 1982. Um, for the record, there wasn't any GNU project in 1982.   From: ER Date: Tue, 1 Jan 91 19:44:17 EST Subject: Re: This Is What Worries Me In recent spewage, dh calls me a liar for writing that I've been a GNU contributor and supporter since 1982. My history with GNU spans its entire lifetime to date (most recently, RMS accepted an SCCS control mode into the libraries for v19 EMACS). It's possible that the project had an official start time that postdates 1982, but I was involved before that, when the project was just a gleam in RMS's eye (by 1982 I'd already known him for four years). He's welcome to ask RMS when I volunteered the code that became GNU sed. That was before the project had even definitely settled on the GNU name. RMS may even recall that I was one of the first people -- possibly *the* first -- to urge that an EMACS implementation be the flagship product of his embryonic project. I can only assume that gumby's remarks are a function of ignorance and his expressed distate for the Jargon File revision I am currently undertaking. I leave it for others to judge whether any juxtaposition of the above facts with GNU's official history justifies a vindictive flame. -- >>eric>>   From: AB Date: Tue, 1 Jan 91 21:09:08 EST Subject: But DH didn't know Mr. Raymond was on unix-haters! For the moment I have removed Mr. Raymond from unix-haters. If anyone wants to put him back, they should first give him a crystal clear explanation of the boundaries of discussion, and they should also warn the rest of us in advance so that we can avoid repeating dh's faux pas. Personally, I think it's kind of inhibiting to have "prominent Unix personalities" on unix-haters. It's hard to work up a really good flame about clueless, twinkie-crazed, brain damaged unix weenies when you have to worry that you might offend someone. This is not a list for the faint of heart. Accuracy is -not- required on unix-haters. Unix-haters requires only hatred. (Of course accuracy does have its role. Nothing improves a really good anti-Unix rant more than the knowledge that the eye-popping misfeature in question really does work -exactly- as described.)   From: MT Date: Wed, 2 Jan 91 07:42:04 PST Subject: Re: this is what worries me From: ER In recent spewage, dh calls me a liar for writing that I've been a GNU contributor and supporter since 1982. Um, DH didn't call you a liar. Somebody else did. DH merely pointed out the fact that 1982 predates the GNU project. I'm not calling you a liar; rather, I am merely pointing out that DH didn't call you a liar.   From: MY Date: Wed, 2 Jan 91 14:23:19 EST Subject: Another thing to hate about The Mad Mastermind of TMN-Netnews I really hate it when feeble weenies with feeble mailers (another example which is the MIT AI Lab) create a local mailing-list (weenix: "alias") "foo@my-stupid-local-machine" which forwards to "foo@real-distribution-machine" Then when somebody with a slightly-less-feeble Mailer User Agent goes to reply, we end up with fun round-trips to UUCP-land like this: Received: from TOLD.TLA.MENT by hhh.aug.hhh id aa04447; 2 Jan 91 14:03 EST Received: from mc by told.tla.ment id aa16833; 2 Jan 91 14:01 EST Received: from UUNET.UU.NET by told.tla.ment id aa16816; 2 Jan 91 13:58 EST Received: from cbmvax.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA25683; Wed, 2 Jan 91 13:58:30 -0500 Received: by cbmvax.cbm.commodore.com (5.57/UUCP-Project/Commodore Jan 13 1990) id AA06488; Wed, 2 Jan 91 13:44:28 EST Received: by snark.thyrsus.com (/\=-/\ Smail3.1.18.1 #18.14) id ; Wed, 2 Jan 91 12:55 EST Received: by cbmvax.cbm.commodore.com (5.57/UUCP-Project/Commodore Jan 13 1990) id AA25500; Wed, 2 Jan 91 11:17:42 EST Received: from LABREA.STANFORD.EDU by uunet.UU.NET (5.61/1.14) with SMTP id AA10506; Wed, 2 Jan 91 10:52:51 -0500 Received: by labrea.stanford.edu; Wed, 2 Jan 91 07:38:00 PST Received: by cygnus.com (4.0/SMI-4.0) id AA22462; Wed, 2 Jan 91 07:42:04 PST Date: Wed, 2 Jan 91 07:42:04 PST From: MT To: cbmvax!snark.thyrsus.com!eric@uunet.uu.net In-Reply-To: "ER"'s message of Tue, 1 Jan 91 19:44:17 EST Subject: Re: this is what worries me   From: MP Date: Wed, 2 Jan 91 18:19:07 EST Subject: MC:HUMOR;JARGON > A couple of weeks ago (actually 18 Dec 90) AB asked (in part): ... whatever happened to... "We plan to take a snapshot of [the ITSs] and [make it] available on some other file server." Well, since I didn't see anyone else reply I thought I would. The file systems from the old ITS machines AI and MC are available by anonymous FTP (I'm not sure AI is fully rebuilt yet. Alan? Penny?) from the new edition of MC (sorry, but it's a UNIX). After logging in as anonymous, there is a directory "its" containing directories "ai" and "mc" each containing the original directories with their files. This is UNIX, so those names are all lower case. The files were transformed from ITS to UNIX, I'm not sure what the translation for binary files is, but ITS 7-bit text files can be read as standard files. Alan set this up and you can ask him if you want any binary files. The ai files seem to all be in UNIX compressed format (Alan, are we going to move these to the opti-disk, too, then can they be uncompressed?) so you need to have a UNIX to read them, sigh. BTW, at the time of the snapshot, the humor directory was on AI, not on MC.   From: RZ Date: Wed, 2 Jan 91 16:22:27 -0800 Subject: Re: Why find doesn't find anything Of course, you need to give find the -print option, otherwise (by default) it finds the relevant files silently and does nothing. God forbid that a Unix program default to doing something reasonable. Another related NFS lossage has to do with directories that suddenly appear out of nowhere. You know, you type "ls" and find there is no such directory as "bin", but if you do "cd bin" it suddenly appears? Does anyone out there know how this misfeature works?   From: PD Date: Wed, 2 Jan 1991 16:39:05 PST X-Mailer: Sendmail/Ream version 4.15 (The Choice for a New Generation) X-Subliminal-Message: Send me all your money Subject: Re: Why find doesn't find anything > Another related NFS lossage has to do with directories > that suddenly appear out of nowhere. You know, you type > "ls" and find there is no such directory "bin", but if you > do "cd bin" it suddenly appears? Another example of UNIX implementors ignoring anything done by anyone else. NFS implements a distributed file system (well...) but has no notion of "cache consistency". The little checking that's done is all based on machine's private notions of what the hell time of day it is, and you can normally reckon that *none* of your machines really know, never mind agree with each other. Now what we have is the basis for a wonderful piece of misfeature synergy. Let's combine this wonderful state of affairs with the delights of X (X, X, all you ever think about is X) and remote terminal windows. Fine and dandy until you use lots of 'em with local editting and remote compilation on some big machine, 'cos there's no guarantee that they agree on what's in your source file. And, of course, since this bug isn't reckoned as serious (!) there's not even a recommended procedure other than 'cat'ting lots of files or doing other file-intensive behaviour to clear out the caches. Ack, I've got a headache.   Subject: Re: Why find doesn't find anything Date: Wed, 2 Jan 91 17:19:14 -0800 From: DC I once complained about this bug to a unix fan at the AI lab. His reply was ``well, this is just a hard problem. There's no way to do it right. Learn to work around it.'' I thought about explaining that MLDEV did it right in 1975, but decided I wouldn't get anywhere. [PS. Complaining about gnumacs seems unfair, since it is the one piece of unix software that works, but since I got bitten while composing this message by a bug that's been annoying me since I started using it, and since unix-haters is not about being fair (``we're not paid to do that''): WHY CAN'T GNUMACS REMOVE PEOPLE WHO ARE IN THE TO LIST FROM THE CC LIST? Emacs did this right in 1975...]   Date: Thu, 3 Jan 91 09:45 CST From: CG Subject: Upon further review . . . I'm so glad that my documentation suggestions are being reviewed by people who write well. (In case you can't follow the structure below, the paragraph at the bottom with newlines in it is what I sent, and the paragraph above without newlines is the answer.) ========== Begin Forwarded Messages ========== Date: Thu, 3 Jan 91 08:35 CST From: R Subject: [Corp.Sun.COM: grammatical error in install script so 631788] Return-Path: Date: Wed, 2 Jan 91 15:18:56 PST From: rodo@Corp.Sun.COM (RL USAC/PAL) To: R Subject: grammatical error in install script so 631788 Cc: rodo@Corp.Sun.COM R, Apon further review I am going to leave this as it is. The reason for several minutes is to allow ambiguity in the amount of time required because the difference in system performance. Regards, Rod In install.x25 (and I think also in install.mcp), you might note that "can take up to several minutes" is awkward grammar. Of course, it's not worse than "now you must do a make", so a Unix hacker would probably never notice, but nevertheless, someday Sun may wish to market to real people as well as to Unix hackers. The phrase "can take up to" should be followed by something less vague than "several minutes", such as "10 minutes". I suggest that "up to" be removed, and instead simply say "can take several minutes". As long as I'm microediting this phrase, I would probably actually say "might take several minutes", but you can check with your documentation people on that one. =========== End Forwarded Messages ===========   From: RA Date: Thu, 3 Jan 91 18:07:43 EST Subject: Re: Why find doesn't find anything Date: Wed, 2 Jan 91 16:22:27 -0800 From: RZ Another related NFS lossage has to do with directories that suddenly appear out of nowhere. You know, you type "ls" and find there is no such directory as "bin", but if you do "cd bin" it suddenly appears? Does anyone out there know how this misfeature works? Yep. They reinvented job-devices and blew it. The culprit is the automount facility. This kludge consists of a per-machine daemon which the kernel talks to via the NFS protocol in loopback mode. The automount daemon thus receives I/O requests for files named things like "/net/twinkie/usr/loser/snork" and decides that this is a request for the file "/usr/loser/snork" on the machine "twinkie". All well and good, except that of course one can only mount entire filesystems via NFS, and of course it would be too simple to just mount it where you're going to use it, so the automount daemon tells you that "/net/twinkie/usr/loser/snork" is really a symbolic link to something like "/tmp_mnt/fs-0135226/loser/snork". All of which would still work, although you might lose your lunch if you make the mistake of looking at it while all this is happening, except that sometimes the automount daemon just tells you that the file doesn't exist because it would take to long to compute all of the above braindamage and obviously it is more important to get the wrong answer fast than to get the right answer slowly.   From: DC Date: Fri, 4 Jan 91 15:34:28 -0800 Subject: gnumacs r command WHY CAN'T GNUMACS REMOVE PEOPLE WHO ARE IN THE TO LIST FROM THE CC LIST? Emacs did this right in 1975... Several people misunderstood this. The point is not that I want the functionality of 1r, but that I don't want the person in my to: list to appear in my cc: list as well, because then they get redundant copies. In other words, the sender of the replied-to message should be removed from the cc: list. All clear?   From: AB Date: Sat, 5 Jan 91 04:19:31 EST Subject: Unix has it in for Mr. Raymond Definitely the worst thing about Unix is how flakey mail is. Tonight I learned that some of my mail during December was lost, apparently due to filesystem or mailer problems at the AI Lab. (I suspect a lot of mail was lost, but apparently we don't bother to publicize these little mailer glitches any more.) After groveling around I found the following message was one I never received, and I suspect that many of -you- never got it either. If you had, you might have had more warning of Mr. Raymond's arrival on unix-haters! The irony of this should be obvious. [ Apologies to those of you who have seen this before, but I thought that the others would be, uh, "interested". ] From: ER Subject: Why I hate UNIX -- a UNIX weenie confesses Date: Sat, 22 Dec 90 13:26:47 EST Ten Things I Hate About UNIX (by a UNIX weenie who has (at least for the duration of this message) Seen the Light...) 1. The @!$#! file system is so stupid that it has to masturbate for three to five minutes before it's sure it's retained enough of its vitality to let me boot up. 2. X. Don't get me started about X. Only in X could you need to write three pages of Old Sanskrit to do "Hello, world!". Yes, X, the window system so hoglike and slow that it brings even RISC machines to their knees. And the X documentation? Don't make me laugh... 3. Kitchen-sink kernels that enshrine every incompatible special-purpose hack in the last ten years. Fer cripes' sake, who *needs* cruft like the Indian Hill IPC package or ioctl handlers for every I/O device more recent than a @#!$% stone tablet to be resident all the time? 4. Four different (and, of course, mutually incompatible) wild-carding notations. Was that `.' or `?', sir? Do you want `*' or `.*', sir? Can I use `+' here? or `|' here? Sheesh... 5. The `editor' vi. Oh, this is a good one. Don't you just *love* insert vs, command mode? Doesn't it make your day to press an arrow key and get `[[B' munged into your text? 6. The $#@&!!# default octal escapes in all the tools, which we're stuck with forever because Ritchie thought it was more important to support hand-hacking three-bit PDP11 opcode fields than to be able to actually read data dumps on a byte-addressable machine. 7. The pcc compiler, perpetually about three to five years behind the times and the *only* major implementation not to support the bloody ANSI standard (not that X3J11 doesn't have its own share of brain-damage). 8. Data dependencies in all those nice clean `filters' UNIXoids like to rave about. Did you ever try passing nulls for a graphics escape through nroff or the print spooler? Or typing high-half graphics characters to cat(1) through the shell's `cooked' line discipline? Yeah, you'll find out about `cooked' all right... 9. Text-processing tools that `silently truncate' long lines. Better than that: fixed-length buffers as far as the eye can see in tools with no input-length checks, so you can garbage static data, smash your stack or worse (``worse'' as in the RTM worm). 10. And there's no !@#$@ legal *source* any more for less than the approximate yearly GNP of a small third-world nation, so I can't *fix* things. *That* is the most unkindest cut of all. -- ER = er@al.gol.tla   From: CG Date: Mon, 7 Jan 91 10:29 CST Subject: I love timely and informative error messages. ========== Begin Forwarded Messages ========== Date: Sun, 6 Jan 91 00:05 CST From: MAILER-DAEMON@uunet.UU.NET Subject: Failed Mail After 30 days (727 hours), your message to the following people: zardoz!security-request (host=spsd) could not be delivered. ----- Unsent message follows ----- Received: from SLCS.SLB.COM by uunet.UU.NET (5.61/1.14) with SMTP id AA11599; Thu, 6 Dec 90 17:28:18 -0500 Received: from GLOWWORM.LispM.SLCS.SLB.COM by SLCS.SLB.COM (4.1/SLCS Mailhost 3.10) id AA28685; Thu, 6 Dec 90 16:30:28 CST Date: Thu, 6 Dec 90 16:22 CST From: CG Subject: lol@slcs.slb.com has been added to the security list To: security-request@cpd.com Cc: postmaster@slb.COM, mariner@SLCS.SLB.COM In-Reply-To: <9012061938.AA03098@uninet.cpd.com> Message-Id: <19901206222219.8.MARINER@GLOWWORM.LispM.SLCS.SLB.COM> [ . . . ] =========== End Forwarded Messages ===========   From: MY Date: Mon, 7 Jan 91 23:09:32 EST Subject: What you once thought was a brain-dead misimplementation is now the protocol definition! or, Unix Historical Revisionism At Work Again, or, IETF-approved RFC1196 This whole thing is pretty sad, or pathetic, or depressing or something. Firstly, there's the rewriting of a protocol to conform to a ubiquitous misimplementation -- the unix story over and over. Then there's the growing Balkanisation (or Multics-ification) of the net -- I remember laughing out loud when I found that MIT-MULTICS refused finger service on security grounds. Then, or course, there's the pathetic implementational warnings about how one should be very very careful in implementing this sensitive and dangerous protocol -- as if this perilous protocol somehow innately offered a direct way to shove fingers up unix' sockets. Or something. Network Working Group D. Zimmerman Request for Comments: 1196 Center for Discrete Mathematics and Obsoletes: RFCs 1194, 742 Theoretical Computer Science December 1990 The Finger User Information Protocol Status of this Memo This memo defines a protocol for the exchange of user information. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program. Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. This edition corrects and clarifies in a minor way, RFC 1194. [...] 1. Introduction 1.1. Intent This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program (RUIP). Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many current implementations or add unnecessary restrictions to the original protocol definition. The most prevalent implementations of Finger today seem to be primarily derived from the BSD UNIX work at the University of California, Berkeley. Thus, this memo is based around the BSD version's behavior. [...] 2.3. Query specifications An RUIP MUST accept the entire Finger query specification. The Finger query specification is defined: {Q1} ::= [{U}] [/W] {C} {Q2} ::= [{U}]{H} [/W] {C} {U} ::= username {H} ::= @hostname | @hostname{H} {C} ::= {H}, being recursive, means that there is no arbitrary limit on the number of @hostname tokens in the query. In examples of the {Q2} request specification, the number of @hostname tokens is limited to two, simply for brevity. Be aware that {Q1} and {Q2} do not refer to a user typing "finger user@host" from an operating system prompt. It refers to the line that an RUIP actually receives. So, if a user types "finger user@host", the RUIP on the remote host receives "user", which corresponds to {Q1}. [...] 2.5.2. {U}{C} query A query of {U}{C} is a request for in-depth status of a specified user {U}. If you really want to refuse this service, you probably don't want to be running Finger in the first place. An answer MUST include at least the full name of the user. If the user is logged in, at least the same amount of information returned by {C} for that user MUST also be returned by {U}{C}. Since this is a query for information on a specific user, the system administrator SHOULD be allowed to choose to return additional useful information (per section 3.2.3), such as: - office location - office phone number - home phone number - status of login (not logged in, logout time, etc) - user information file A user information file is a feature wherein a user may leave a short message that will be included in the response to Finger requests. (This is sometimes called a "plan" file.) This is easily implemented by (for example) having the program look for a specially named text file in the user's home directory or some common area; the exact method is left to the implementor. The system administrator SHOULD be allowed to specifically turn this feature on and off. See section 3.2.4 for caveats. There MAY be a way for the user to run a program in response to a Finger query. If this feature exists, the system administrator SHOULD be allowed to specifically turn it on and off. See section 3.2.5 for caveats. [...] 2.5.4. /W query token The token /W in the {Q1} or {Q2} query types SHOULD at best be interpreted at the last RUIP to signify a higher level of verbosity in the user information output, or at worst be ignored. [...] 3.1. Implementation security Sound implementation of Finger is of the utmost importance. Implementations should be tested against various forms of attack. In particular, an RUIP SHOULD protect itself against malformed inputs. Vendors providing Finger with the operating system or network software should subject their implementations to penetration testing. Finger is one of the avenues for direct penetration, as the Morris worm pointed out quite vividly. Like Telnet, FTP and SMTP, Finger is one of the protocols at the security perimeter of a host. Accordingly, the soundness of the implementation is paramount. The implementation should receive just as much security scrutiny during design, implementation, and testing as Telnet, FTP, or SMTP. 3.2. RUIP security Warning!! Finger discloses information about users; moreover, such information may be considered sensitive. Security administrators should make explicit decisions about whether to run Finger and what information should be provided in responses. One existing implementation provides the time the user last logged in, the time he last read mail, whether unread mail was waiting for him, and who the most recent unread mail was from! This makes it possible to track conversations in progress and see where someone's attention was focused. Sites that are information-security conscious should not run Finger without an explicit understanding of how much information it is giving away. [...]   From: DM Date: Tue, 8 Jan 91 12:52:56 EST Subject: Why *did* I log into UNIX? I got so sick of unix spell, I fixed m-$ to use webster instead. Webster knows RELATED but not UNRELATED, OBVIOUS but not OBVIOUSLY, even when those variations are listed in the definition! What a crock. I fondly recalled the ITS ispell program I used to use, and guess what, Pace Willison ported it to unix, oh boy, now I can win! Let's try it out... "obviously" found because of "OBVIOUS" "Webster" not found "Webster's" found because of "OBVIOUS" Er, not quite how I remember it. And that capitalization, ugh. But look, ispell on fenchurch works ok, I'll copy it to here... >rcp -r fenchurch.mit.edu:/usr/src/usr/eecs/bin/ispell /usr/site/ispell.good ...piss, every time I try rcp it randomly loses, hmmm, should be simple... >cd /usr/site/ispell.good; rsh fenchurch.mit.edu '( cd /usr/src/usr/eecs/bin/ispell; tar cf - . )' | tar xpfB - ./config.h: Permission denied ./dict.2.cnt: Permission denied ./dict.2.stat: Permission denied ...Huh? I don't have permission to make a file in my own directory? how come the other files copied just fine? I summon a Weenie... Weenie: That's funny, aren't you in the build group? Me: The what group? I created that directory myself! W: Why did you use the 'p' option? You probably don't have permission to chmod the file. M: But that's the point. I just wanted to keep the dates correct. W: Huh? But you're starting over! M: What about version info? W: We have RCS for that. M: Oh, I get it, weenies are so clueless, you'd never dream of keeping file dates and authors right there in the directory, when you could stuff it in some other file somewhere else! *GROAN* What is this RCS? Is it as easy to learn and use as tar? W: If you didn't want a whipping, why did you log into UNIX anyway? A true live story! Well, I needed to vent that upon y'all, now I'm going to go to see if tar without the 'p' will copy my files or not...   From: SR Date: Thu, 10 Jan 91 00:12:29 EST Subject: Re: Why *did* I log into UNIX? Date: Tue, 8 Jan 91 12:52:56 EST From: DM M: Oh, I get it, weenies are so clueless, you'd never dream of keeping file dates and authors right there in the directory, when you could stuff it in some other file somewhere else! *GROAN* What is this RCS? Is it as easy to learn and use as tar? W: If you didn't want a whipping, why did you log into UNIX anyway? I was interviewing with an info tech strategy/management consulting firm yesterday. The interviewer asked me why I thought Unix wasn't catching on the way "it was supposed to." We had a discussion about weenie-type cultures. His conclusion, as an outside non-techie observer, was that Unix weenies scare off real programmers and anyone who would want to do anything useful on a computer. I hadn't realized it was THAT obvious...   From: JL Date: Thu, 10 Jan 91 09:34:47 EDT Subject: Ah, those wonder Unix mailer error messages! A message sent to me by a mailing list was bounced with the following message: From: Mail Delivery Subsystem To: Subject: Returned mail: Service unavailable Message-Id: <9012290014.AA13231@ELI.CS.YALE.EDU> ----- Transcript of session follows ----- 554 striker@twa.com... Cannot deliver: ARPA access denied to user " (The interesting truncation to 80 characters was in the > original - though it isn't clear whether that's a Unix > crock or a BITNET crock.) The "diagnosed" (to use the word very broadly) cause was reported to me as follows by the maintainers of the machine: There was a problem with bulldog because a disk got full. I think you should be okay now. Ah, well, at least it didn't inform me once again that I wasn't a typewriter.   Date: Thu, 10 Jan 91 10:05:53 EST From: SS Subject: #$%^! I never realized unix came with a utility for automatically generating racial epithets and derogatory sexual references. Considering the time spent by users uttering such maledicta, perhaps this is a great productivity tool. ------------------------------------------------------------------------------ From: JL Newsgroups: comp.lang.lisp Subject: Unix CURSE-like utility in Commom LISP? Date: 9 Jan 91 20:08:47 GMT Distribution: usa Greeting *: Does anyone out there know if there is an Unix CURSE-like utility in Commom LISP? Any hint or reference is appreciated. Thanks in Advance!   From: JJ MMDF-Warning: Parse error in original version of preceding line at told.tla.ment Date: Fri, 11 Jan 91 16:41:57 CST Subject: USENIX and UniForum dress Resent-Comments: Now even the wardrobe is a box of incompatible tools. Since D and R will be attending the USENIX and Uniforum conferences, I thought this item might be of interest. ------------------------------------------------------------------------ Tired of being snubbed by bearded longhairs who refuse to discuss important technical issues with you because your clothes are too neat? Frustrated by marketing people who won't provide you with essential information because your shoes aren't shined? You need the UniSuit, the only suit designed exclusively by Unix experts in Texas for the intense fashion demands of the annual joint USENIX/UniForum conference. Just slip into a restroom and in less than five minutes the beautiful, conservative wool suit is converted into an appropriate outfit for the next USENIX session. The comfortable UniSuit UniShoes with Vibram(tm) soles convert quickly to shiny dress shoes or scuffy, rugged mountain hikers. UniSuit slacks are wrinkle resistant wool blend on one side and faded and patched denim on the reverse. Other UniSuit components reverse to assorted garments of random colors and patterns, guaranteed not to match. Just add your own T shirt statement, and you fit right in with the USENIX crowd. Necktie may optionally be worn as a headband. UniSuit available in grey or navy wool blend. Women's UniSuits available in time for UniForum '92. Also available is the optional UniPack. This fine executive satchel converts into a colorful backpack. Don't spend valuable time trying to overcome a first impression. Wearing a UniSuit allows you to focus on the real reasons you attend the USENIX and UniForum conferences. UniPack and UniSuit available at fine clothiers and wilderness shops in your area.   From: MY Date: Fri, 11 Jan 91 18:48:43 EST Subject: What, you whiners aren't happy with the conservative GC bone we threw you? David Chase (ex-Olivetti modula-3 dude, now at Sun) sent a message pointing out how any compiler which relied on using C as an intermediate language (and doesn't declare every single variable to be `volatile' -- ie not-storable-in-a-machine-register) cannot even rely on `conservative' GC working in the presence of what unix weenies call `aggressively' optimizing C compilers. (Their ideas of `aggression' in a compiler seem pretty tame.) Below is a classic response: even if it is possible, it probably won't happen, and even if it did happen, it probably was somebody else's fault, and even if it really really did happen, one can always empirically adjust an empirically-derived fudge factor until it doesn't happen any more on that machine with that release of that particular C compiler and C runtime. Parallels between political and garbalogical conservatism keep occuring to one... (Bleeding-heart garbage-collectors invest energy in locating and equally ensuring the welfare of every single pointer because they know that a heap in which some pointers are mislocated is an untenable heap.) From: muller@src.dec.com (Eric Muller) Newsgroups: comp.lang.modula3 Subject: Re: optimization and garbage collection Date: 10 Jan 91 02:43:52 GMT References: <91Jan2.131022pst.3117@arcturia.parc.xerox.com>, <5142@exodus.Eng.Sun.COM>, <39976@super.ORG>, <5293@exodus.Eng.Sun.COM> David Chase argues that an aggressive C optimizer can disturb Modula-3 programs (in the case of a Modula-3 compiler that generates C, of course). In particular, garbage collection can be a real trouble, as roots can be "hidden". While such occurrences are possible, I would not rule out a bug in the Modula-3 compiler or in the C optimizer to conclude right away in favor of an unwanted side-effect of aggressive optimization. If I were to give probabilities to: 1. SRC Modula-3 generates incorrect C code 2. the C compiler is incorrect 3. it is one of those things we cannot do because we generate C I would say: p(1) = 99.9%, p(2) = 0.099%, p(3) = 0.001%. Of course, we make assumptions when generating code and in the garbage collector, and they may not be satisfied. As for the generated code, we try to use no more than what ANSI-C says. For the garbage collector, we assume that if a traced heap object (i.e. a traced OBJECT or REF) is accessible by the program, then there is somewhere in the stacks or the registers a reference to one of the pages that contains that object. If it turns out that this is not reasonable, we can increase the level of conservatism, for example that saying that the pointer can be as far as x bytes from object. However, we have yet to see an example of 3. In the mean time, keep these bug reports coming so that we can achieve p(1) = 50%.   From: OS Date: Tue, 15 Jan 91 09:31:34 EST Subject: Re: Unix debuggers Nice theory, but I'm afraid you are too generous. When I was porting a Scheme compiler to the RT, I managed to make adb -- nothing like a fancy, source-level debugger, or anything, just dumb ol' adb -- dump core with about 6 or 7 keystrokes. Not arcane keystrokes, either. Shit you would tend to type at a debugger. It turned out that the symbol table lookup code had a fencepost error that barfed if a particular symbol happened to be first in the list. The C compiler never did this, so... it's good enough for Unix! Note that the RT had been around for *years* when I found this bug; it wasn't raw software. The RT implementation of adb also had the interesting feature of incorrectly printing the value of one of the registers (r0). After I had spent a pleasant, relaxing afternoon ineffectively trying to debug my code, and discovered this, I remarked upon it to my RT-hacking friends. They replied, "Oh, yeah. The debugger doesn't print out r0 correctly." In order to use adb, it seems, you just had to know this fact from the grapevine. I was much amused at the idea of a debugger with large, obvious bugs. I recently managed to wedge our laserwriter server by queueing up a large number of short files to it. My officemate flamed me for doing so. I replied, which led to the following illuminating interchange: >> How was I to know the idiot system would vapor-lock on me? >> Because it's Unix? And that about sums it up for Unix. When the revolution comes, and the mob drags Bill Joy screaming from his Ferrari at the factory gates, I, for one, will not be there to urge clemency.   From: JL Date: Tue, 15 Jan 91 09:53:31 EDT Subject: Oh, you mean you wanted to DEBUG that code? An officemate of mine a couple of years ago was trying to debug a program on a Unix system. When he ran it, it chugged a bit and then just exited - no error message or error value to be seen anywhere. So he tried to use sdb (or maybe dbx) on it. Now, instead of the program just dying, the debugger died in the same way. We puzzled over it for a while, and I finally convinced him that adb was the only thing left to try. Even with adb, it took us a while to get to the point of being able to SEE the error return: "Text busy". Sure enough, sitting there in a background job was a suspended invokation of (I guess) an earlier version of the program. Tracking this down took some two hours, as best I can recall. My officemate was a fairly experienced Unix hacker; at the time, I dabbled. Still, the only reason we found it at all was that I knew too little Unix to be willing to rely on the, ahem, "tools" that come with it.     From: CF Date: Tue, 15 Jan 91 16:31 PST Subject: Revisionist weenies For reasons I'm ashamed to admit, I am taking an "Intro to Un*x" course. (Partly to give me a reason to get back on this list...) Last night the instructor stated "Before Un*x, no file system had a tree structure." I almost screamed out "Bullshit!" but stopped myself just in time. I knew beforehand this guy definitely wasn't playing with a full deck, but can any of the old-timers on this list please tell me which OS was the first with a tree-structured file system? My guess is Multics, in the late '60s. PS. Is this list available on net news? <:-) PPS. Part of why I hate Un*x is that its acolytes are every bit as parochial and insulated from the rest of computing history as the old IBM OS/360 (/370, etc) types used to be. (Are there any OS/370 types still out there at this late date?)   From: DM Date: Wed, 16 Jan 91 12:05:24 Subject: Re: #$%^! > Date: Thu, 10 Jan 91 10:05:53 EST > From: SS > > I never realized unix came with a utility for > automatically generating racial epithets and derogatory > sexual references. Considering the time spent by users > uttering such maledicta, perhaps this is a great > productivity tool. Interesting. This means that, under the state law on sexual harrassment, any manager in a California corporation who becomes aware of the use of Unix within his/her organization is responsible for immediate removal of the Unix system from that organization, under penalty of the law.   From: DC Date: Thu, 17 Jan 91 10:09:41 -0800 Subject: Re: Unix debuggers Um, this is probably an inappropriately constructive question, but: why can't the debugger rename the core file as the first thing it does, thereby avoiding overwriting it if the debugger itself crashes?   From: PB Date: Thu, 17 Jan 91 11:17:57 PST Subject: Re: Unix debuggers You're supposed to rename the core file before debugging it. Debuggers aren't there to hold your hand.   From: PS Date: Thu, 17 Jan 91 16:31:43 EST Subject: 25 ^D's = logout despite ignoreeof Remember the old Unix "I tell you three times" rule? And the fact that, even if you have ignoreeof set, typing 25 ^D's consecutively will cause you to be logged out? When I first heard about this, I thought, "Of course, this is a provision to turn off a line that is running open and simply producing random noise. Makes sense." I was just explaining this to someone, and it occurred to me that a line that is producing random, uniformly distributed 8-bit characters is going to take a long time to produce 25 ^D's in a row. In fact, if you think of a process whose state is the last 25 characters that were read, then the limiting probability of being in the state where the last 25 characters were all ^D's is 1 ----- 25 256 and the expected number of characters between sequences of 25 ^D's is then 1606938044258990275541962092341162602522202993782792835301376 But this also has to be the expected number of characters to go from a sequence of 24 ^D's to one of 25 ^D's. Because we need a sequence of 24 ^D's before we can have 25 ^D's, we have that the expected number of characters until the first string of 25 ^D's is that until the first string of 24 ^D's plus the humungo number above. If we follow this rule recursively, we find that the expected number of characters until the first string of 25 ^D's is the sum of 256^i for i from 1 to 25. As any schoolchild knows, this will be 26 256 - 256 ---------- 255 or 1613239762079613766818597237801324024492878299640764571910400 If the characters are generated at 19200 baud, this will take about 48 2.66435 x 10 years This is beyond the MTBF of most Unix boxes. In fact, it's beyond the MTBF of the universe! So the purpose of this amazing Unix feature remains a mystery!   From: SG Date: Thu, 17 Jan 91 16:52:16 EST Subject: Re: 25 ^D's = logout despite ignoreeof Actually, the reason to log off if you get 25 ^D is that the ^D is the end of file character. The shell automatically dies if it gets 25-EOF's in a row. If it didn't, and you were silly enough to execute something like this: echo "foo" | csh Then csh would loop forever. Of course, csh *could* check to see if its input was a file. But what if its input was a pty? It's just too complicated to figure out a solution. So unix does what unix does.   Date: Thu, 17 Jan 91 14:13:28 -0800 From: AB Subject: Re: 25 ^D's = logout despite ignoreeof You estimated too long. The 8th bit on a comm line [unless you explicity turn it off, at which point there is no EOF character] is ignored. Thus it's only 128 characters in the set.   From: AB Date: Thu, 17 Jan 91 17:41:58 EST Subject: Re: 25 ^D's = logout despite ignoreeof Date: Thu, 17 Jan 91 14:13:28 -0800 From: AB You estimated too long. The 8th bit on a comm line [unless you explicity turn it off, at which point there is not EOF character] is ignored. Thus it's only 128 characters in the set. Excuse me!?!? I don't see any Hatred in this message! Earlier today Chapman was pushing it by asking a question, but there was a touch of annoyance in his tone and the replies were suitably vituperative. Bit -this- message isn't even mildly irked! Surely you can find something about how Unix treats that 8th bit to flame about. (Hell, -I- can!)   From: DC Date: Thu, 17 Jan 91 14:47:01 -0800 Subject: Re: 25 ^D's = logout despite ignoreeof Yes: for example, some unix telnets pass the meta bit and some don't. It seems to be a compile-time parameter or something; there doesn't seem to be any way to set it. Ugh.   From: AB Date: Thu, 17 Jan 91 15:25:45 -0800 Subject: the eighth bit Well, I was going to flame about the 8th bit on SUN workstations, but as it turns out, they've made everything but /bin/ls [from just poking around] work just great. ARGH! [Thus it's very hard to hate SUNOS in regard to 8-bit characters. Terminal handling, on the other hand, is an entirely different story] 8th bit flammage' on unix: [Please pardon errors - I spent too much of last night watching relayed CNN broadcasts and trying to listen to the shortwave] Most systems don't even have a "pass8" option to stty, so you're stuck at square one. Most shells use the 8th bit to indicate quoting! Thus, it strips out the 8th bit before it uses the arguments. Whose bright idea was it to use the 8th bit for quoting? Didn't you think about the future? Do you think the entire world is ASCII? Did someone drop you on your head at birth? What are you going to do in order to atone for this? Redesign the ethernet slide-lock connector??? [Btw, I have the net address of the pinhead who was responsible for it] Then there's what application programs do. vi? Heh heh. It gets so confused, there's nothing you *can* do with it. You can create files with 8bit chars in their file names through a program you write yourself or via ftp [heh heh]. After you get a file with the 8th bit in its name, you can only access it by writing a program, through ftp or, if you want to delete it, then you have to resort to writing a program, ftp, or good ol' /bin/rm -i /dir/ectory/name and tell it *not* to remove all but the one file that you want to zap. Change its name? Program or ftp again. How about /bin/ls? It won't even *SHOW* the character, well, it does show it as '?'. ARGH.   From: IH Date: Thu, 17 Jan 91 18:28:07 EST Subject: Re: 25 ^D's = logout despite ignoreeof Date: Thu, 17 Jan 91 14:47:01 -0800 From: DC Yes: for example, some unix telnets pass the meta bit and some don't. It seems to be a compile-time parameter or something; there doesn't seem to be any way to set it. Ugh. Unix rlogin only passes the 8th bit if you say "-8" in the command line. I ask you: why? why? why? It makes no sense.   From: LK Date: Thu, 17 Jan 1991 17:48:51 PST Subject: Re: 25 ^D's = logout despite ignoreeof I like the feature. It lets me log out with one hand. It's good for demos, where you want to log out or close a window while you're talking.   From: PS Date: Thu, 17 Jan 91 22:52:03 EST Subject: 25 ^D's = logout despite ignoreeof Date: Thu, 17 Jan 1991 17:48:51 PST From: LK I like the feature. It lets me log out with one hand. It's good for demos, where you want to log out or close a window while you're talking. I like that too. But I never set ignoreeof, so I have to get my thrills with the twenty-five-control-D-"feature" in other ways. This is how I typically do it: 1. I su, in order to do something that Unix won't let me do otherwise. 2. I finish my business and attempt to leave the recursive shell invocation in which I am logged in as root, in my usual way: via ^D. 3. That results in root@august-east# ^D Use "exit" to leave csh. root@august-east# 4. I work up a good testosterone haze, saying, "I'LL show you!" and lean on my ^D key. 5. The result is quick and dramatic, typically looking (at the end) like this: ... Use "exit" to leave csh. root@august-east# ^D Use "exit" to leave csh. root@august-east# ^D Use "exit" to leave csh. root@august-east# ^D pgs@august-east> ^D There are stopped jobs. pgs@august-east> ^D /usr/games/lib/fortunes.dat: read-only file system NO CARRIER If I may paraphrase the immortal words of John Taft: "Horribly wedging my very own personal Unix machine gives me a comfortable, old-shoe kind of feeling, laced with that racy edge of raw, cold-boot power."   From: VA Date: Sun, 20 Jan 91 15:30:50 -0500 Subject: Marginally Relevant Seminar Announcement Tue 22 Jan 7:00 pm MIT Sloan School, Room E51-329 Speaker: Jared M. Spool, User Interface Engineering "Software That Makes People Cry" Host: Joint GB/SIGCHI & BCS UI Design Group For Info: Jared M. Spool at (508) 470-1213   From: CM Date: Mon, 21 Jan 91 14:10:37 EST Subject: hatred? Date: Thu, 17 Jan 91 14:47:01 -0800 From: DC Yes: for example, some unix telnets pass the meta bit and some don't. It seems to be a compile-time parameter or something; there doesn't seem to be any way to set it. Ugh. I really hate how u**x gives perfectly normal hackers a slave mentality after only a few sessions. Get with the program, you backslider, or we'll have to change the name of this list to wimps-mildly-annoyed-with-unix.   From: DM Date: Mon, 21 Jan 91 16:16:17 EST Subject: EUUG Onomatopoetic acronym of the European Unix Users Group.   From: MT Date: Tue, 22 Jan 91 23:36:21 PST Subject: future globs (was "UNIX mindset...") From: RM Date: Wed, 23 Jan 91 02:08:10 -0500 From: D Newsgroups: comp.arch,comp.unix.wizards Date: 22 Jan 91 00:33:50 GMT Followup-To: comp.unix.wizards Subject: future globs (was "UNIX mindset...") RS writes, in response to the glob wars: > Given the move towards kernel bloat, I fear that one > alternative we might see some day is moving file name > globbing into the kernel. "Let's let namei do it; namei > does everything!" Blech. Plus, namei is undoubtedly the single most hacked-over piece of code in the entire kernel! It was already battered ten years ago. Nowadays, it's more complicated than that. First, we'll need a System V kernel globbing interface and a BSD globbing interface. There will be new system calls for this--setglbent() and getglbent() for Sys V, setfilename- globbing() and getfilenameglobbing() for BSD. Of course, they'll have different arguments, and BSD will modify namei-globbing only for the current process, while SysV will modify it for an entire glob-group (a new conceptual grouping of processes). Then, V.4 will have to provide for both mechanisms. The selection of globbing will be based on the file system types, a kernel examination of the process's PATH variable, and the endian-ness of the processor in use. Next, we'll need POSIX globbing, which will be almost like both but not entirely compatible with either, with switches to enable more-nearly-BSD- like and more-nearly-SysV-like behavior. AIX will provide its own extended globbing mechanism, promising support for BSD and POSIX globbing in a future release, anticipating OSF/3 globbing, and also providing for eventual user-specified globbing via callback from namei() to user code. The first release will fail to glob a single '*' correctly, although it will be 26% faster than any other globbing as measured on DhryGlob 0.0.3. A little-known patent on file name wild card expansion will be discovered to have been granted to a now-bankrupt Oregon software company, in an obscure paragraph of a patent originally intended for selecting add-ons to hamburgers in a fast-food point-of-sale terminal. The patent will have been sold to a California paper company which consists only of lawyers, and which will immediately start filing look-and-feel lawsuits to any vendor which won't pay a royalty of $0.005 per globbed name. In response, FSF will issue a dire warning about the consequences of proprietary globbing. Buttons saying "Keep Your Lawyers off My Globs" will appear at the June 1991 USENIX. An extended globbing mechanism will be built into the next release of emacs. OSF will announce that it has studied existing globbing mechanisms and found them to be inadequate. Thus, it will issue an RFT for distributed, open, architecture-neutral globbing mechanisms which also protect vendors' proprietary investments in unexpanded file names. The globbing technology will be selected by an entirely open and fair evaluation process from all submissions received, provided only that the submitter is a large multi-national OSF corporate member with annual revenues exceeding $10^9.   From: DM Date: Thu, 24 Jan 91 16:43:19 Subject: standards This doesn't really meet the criteria for this mailing list, but it's so apposite that I'm going to pass it on anyway: From: dlw in Desperado #3040: Overhead in a stairwell: "I keep getting confused by the word `standards'." Nothing to be confused about, really: stand-ard (n) 1 : a figure adopted as an emblem by a people 2: the personal flag of a ruler You must "pledge allegiance to" or "embrace" it, to avoid the wrath of the millions. That's all there is to it. The computer industry has its own laws on this topic: new standards, once announced, can never be burned, *not even* if they are worn out and tattered. Hence the present situation of dozens and dozens of simultaneous standards...   From: ML Date: Tue, 29 Jan 1991 02:31:42 PST Subject: Unix canned New Jersey -- Just a day after Microsoft announced the end of OS/2, AT&T announced today that it will halt all further development of the UNIX operating system. Bob Gates, spokesperson for AT&T said, "We've had our best engineers working on this system for over 10 years, and look what its produced. We're still making more money selling phone calls". AT&T announced all its UNIX engineers would immediately be reassigned to start working on Windows V. Further licensing of UNIX to all users, including industry leader Sun Microsystems, would be halted immediately. "It wouldn't make sense to let everyone keep using it, after all, we want them to switch to Windows too", said Gates. In related news, Sun Microsystems, now without an operating system for its SPARCstation, announced late today it would begin production of the Sun Classic 386i. Also announced today was an upgrade for SPARCstation users to a 486 processor. Scott McNealy said, "We were ready in case this happened. When we introduced the SPARCstation, you'll remember we also switched to a PC-style keyboard and swapped the backspace and delete keys, and our window system is already called Open Windows. Windows isn't a multi-user operating system, but we never could figure out how to make the scheduler work right under UNIX anyways."   From: RS Date: Wed, 30 Jan 91 11:53:59 EST Subject: Propaganda Just so you know what the enemy is babbling about these days... Return-Path: Date: Wed, 30 Jan 91 11:19:21 EST From: flash@sunvice.east.sun.com (John J. McLaughlin-SunFlash Editor) To: sunflash@sunvice.east.sun.com Subject: SunFlash: Why UNIX Will Win on the Desktop ---------------------------------------------------------------------------- The Florida SunFlash Why UNIX Will Win on the Desktop SunFLASH Vol 25 #17 January 1991 ---------------------------------------------------------------------------- This is an article by Dr. Eric E. Schmidt. It is reproduced with permission. -johnj Dr. Eric E. Schmidt is vice president, General Systems Group, at Sun Microsystems, Inc. , Mountain View, Calif. -------------------------------------------------------------------------------- Why UNIX Will Win on the Desktop By Dr. Eric E. Schmidt Sun Microsystems, Inc. It's trendy to say that the line between PCs and workstations is blurring. The real truth is that UNIX-based systems are taking over, and by the end of the 1990s, the market will clearly distinguish between two types of desktop computers: machines that run DOS and machines that run UNIX. DOS machines will be purchased primarily as single-user systems for stand-alone applications. And in the long run, the only single-user machines the only DOS machines will be in people's homes. Why is this? Because the power of distributed, networked computing is effecting a profound change on corporations. The fact is that humans are inherently networked: we inherently need to commmunicate with each other. Anyone that has networked application needs will turn to UNIX-based solutions, because UNIX is the only multi-tasking, multi-user, multi-vendor operating system available today. That's what makes it the only choice for the next generation of distributed applications. That's why UNIX will win. It's the closest thing the industry has to a pure open standard. Because AT&T Bell Labs made it available in source form in the 1970s, nearly all systems companies either base themselves on UNIX or offer a form of it, including major players such as IBM, Apple, Intel, HP, Sun, DEC, Olivetti, Fujitsu and Unisys. UNIX is available on all PCs today in one form or another. Within five years, all high-end '386 and '486 PCs will be running UNIX with DOS emulation. Gradually, the final "dumb terminal" applications will disappear when this occurs the death knell of the minicomputer. And mainframes? They aren't going away: they'll become servers. We'll just stop using them with dumb terminals. The other operating system in contention (more or less) is OS/2. While OS/2 provides multi-tasking, it's still a single-user operating system. It will have some following because of the existing installed base of DOS applications. However, users are looking for open solutions and OS/2 isn't open. Particularly since IBM recently took back primary control over it. The resulting perception of OS/2 as a proprietary solution will stunt its growth and limit it to the derivative market of DOS applications. Besides pointing to the "threat" of OS/2, UNIX foes have brought up other arguments. But they just aren't valid anymore. For example: Myth: The UNIX market is splintered. Fact: we're down to two choices: UNIX System V Release 4 and OSF/1. All the major computer companies have endorsed one or the other. OSF/1's sponsors say that it will be interoperable with SVR4, giving us as close to a single standard as possible without having a monopoly. Myth: There aren't any UNIX applications. Fact: the leading PC software applications Lotus 1-2-3, WordPerfect, dBase, Ventura Publisher are ported or are in the process of being ported to UNIX. The combination of these applications and new distribution mechanisms based on CD-ROM will initiate an explosion in UNIX use by former DOS users. CD-ROM is inexpensive, easy to use and stores up to 644 megabytes of information, making it a much more effective software distribution medium than floppy disks. Myth: UNIX is hard to use. Fact: Sun and other companies have created graphical user interfaces like OPEN LOOK that conceal the complexity of UNIX, making it easier to install and use. DOS, of course, has been easier to use because it doesn't do much. There's no functionality, so it's not complicated. Myth: UNIX will always be outdistanced by Macintosh OS and DOS. Fact: Although they currently have a larger market share, UNIX is catching up. According to UNIX International, UNIX has more than 10 million users worldwide as well as the highest growth rate. There will surely be more than a million SPARC/UNIX seats alone within the next few years, translating to more market opportunity for software developers and more innovative solutions for end users. Myth: UNIX systems are too expensive. Fact: A comparably equipped high-end PC now costs more than a Sun SPARCstation, which unlike a PC comes standard with such useful features as Ethernet connection, large memory and a monitor. And the cost of UNIX systems will continue to drop. UNIX is synonymous with "open," which is one reason why UNIX and the accompanying open systems movement are revolutionizing the computer industry. The amazing events of the past year, with long-time proprietary vendors being pushed onto the open systems bandwagon, will only ensure UNIX's ascendancy. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ For information send mail to info-sunflash@sunvice.East.Sun.COM. Subscription requests should be sent to sunflash-request@sunvice.East.Sun.COM. Archives are on solar.nova.edu and paris.cs.miami.edu. All prices, availability, and other statements relating to Sun or third party products are valid in the U.S. only. Please contact your local Sales Representative for details of pricing and product availability in your region. Descriptions of, or references to products or publications within SunFlash does not imply an endorsement of that product or publication by Sun Microsystems. John McLaughlin, SunFlash editor, flash@sunvice.East.Sun.COM. (305) 776-7770.   From: IH Date: Wed, 30 Jan 91 19:03:36 EST Subject: Re: MIT-MAGIC-COOKIE-1 The security problem with X access is that X allows programs to type things on the keyboard for you. There are probably other problems too. In any case, it is perfectly possible to write a program which connects to the X server and reads your windows until it sees a super-user prompt, then grabs the keyboard and mouse so that you can't do anything and proceeds to type things at the super-user terminal window. A friend of mine is doing a book on unix security. That's why I know this. Of course you could do this before X, you just did it differently. Ask me sometime about forging NFS packets with a random C program...   Date: Wed, 30 Jan 91 21:05:41 PST From: MT Subject: [Your gcc-pmax mail may have bounced] Date: Wed, 30 Jan 91 21:52:05 -0700 From: DG Subject: Your gcc-pmax mail may have bounced If you sent mail to gcc-pmax@foobar.colorado.edu in the last couple of days, your mail may have bounced due to silly static array sizes declared in sendmail. Death to silly hackers. Q. How can you tell when they've cleaned up UNIX? A. When there's nothing left.   From: SR Date: Thu, 31 Jan 91 00:07:49 EST Subject: Re: MIT-MAGIC-COOKIE-1 IH Your friend's book on Un*x security sounds interesting. If s/he would like proofreaders, I'm volunteering...   From: SR Date: Thu, 31 Jan 91 00:14:15 EST Subject: Re: MIT-MAGIC-COOKIE-1 From: OS Date: Wed, 30 Jan 91 23:49:46 EST It's really sobering to think we live in a society that allows the people who design systems like xauth to vote, drive cars, own firearms and reproduce. I'm just graduating from business school*, and was interviewing with a consulting company that does full scale analysis, design, and implementation of information technology systems for companies. My interviewer looked at me with a rather puzzled, sad expression on his face, and asked mournfully: "We put money into Unix. We put a LOT of money into Unix. *Why* isn't it any turning out to be any good for doing really useful projects?" We decided the answer was obvious. * [At business school, I've mainly learned that business is * set up about as sensibly as the X authorization file. * *Sigh* So much for $70,000.]   From: SG Date: Thu, 31 Jan 91 09:08:46 EST Subject: Re: MIT-MAGIC-COOKIE-1 I'm the person writing the unix security book, to be published this May by ORA. Thanks for the offer, SR. Long time no see.   From: IH Date: Thu, 31 Jan 91 10:14:46 EST Subject: Re: MIT-MAGIC-COOKIE-1 The friend is SG. You probably know him. I think he said the book was at the publishers and was going to be published soon so it's probably past proofreading but you can certainly ask him.   From: SM Date: Thu, 31 Jan 1991 10:28-0500 Subject: Re: MIT-MAGIC-COOKIE-1 Date: Thu, 31 Jan 1991 10:14 EST From: IH The friend is SG. You probably know him. I think he said the book was at the publishers and was going to be published soon so it's probably past proofreading but you can certainly ask him. Hey, there's too much mail going by here that's serious. Cut it out. <:-)   From: DH Date: Thu, 31 Jan 91 10:40:08 PST Subject: ITS vs Unix From: AB Date: Thu, 31 Jan 91 12:49:31 EST It seem that nobody can locate the sources to nfsauth. We had .LOSE and they have find. .LOSE, when needed, helped the user win. But it seems that no matter how much you type "find" to unix, you can't help but lose, lose, lose.   From: DC Date: Thu, 31 Jan 91 11:58:42 -0800 Subject: I can't remember, have I flamed about this here recently? It seem that nobody can locate the sources to nfsauth. It never fails to amaze me the percentage of their time unix weenies spend looking for sources. I just can't understand why it doesn't occur to them that they could put the source information into the object file. It would improve unix productivity by ten percent. The ``it wouldn't be compatible'' excuse doesn't even apply, since object files aren't compatible anyway.   From: DC Date: Thu, 31 Jan 91 17:46:51 -0800 Subject: Gratuitously Vicious Rant Three report lines from ftp: 4081 bytes received in 9 seconds (0.44 Kbytes/s) 5592 bytes received in 8.6 seconds (0.63 Kbytes/s) 93042 bytes received in 1.6e+02 seconds (0.56 Kbytes/s) Evidently there is a routine that tries to print flonums rationally. Evidently it fails miserably (``1.6e+02'' ??). Presumably part of the problem is that presumably unix doesn't have a standard routine you could just *call* to print a flonum. This isn't one of your namby-pamby hand-holding systems; real men can write flonum output routines, and if you can't hack it you should go back home to Mama.   From: JW Date: Thu, 31 Jan 91 21:48:47 EST Subject: Re: Gratuitously Vicious Rant Date: Thu, 31 Jan 91 17:46:51 -0800 From: DC Three report lines from ftp: 4081 bytes received in 9 seconds (0.44 Kbytes/s) 5592 bytes received in 8.6 seconds (0.63 Kbytes/s) 93042 bytes received in 1.6e+02 seconds (0.56 Kbytes/s) Evidently there is a routine that tries to print flonums rationally. Evidently it fails miserably (``1.6e+02'' ??). Presumably part of the problem is that presumably unix doesn't have a standard routine you could just *call* to print a flonum. This isn't one of your namby-pamby hand-holding systems; real men can write flonum output routines, and if you can't hack it you should go back home to Mama. Eh? Of course it does. A perfectly good one, too. I even know of some implementations where actual real numerical hacker types were employed to worry about floating point errors and roundoff and so on. Why on earth do you think a unix programmer would use a standard routine just because it exists?   From: IH Date: Fri, 1 Feb 91 10:37:25 EST Subject: Re: Gratuitously Vicious Rant Date: Thu, 31 Jan 91 17:46:51 -0800 From: DC Three report lines from ftp: 4081 bytes received in 9 seconds (0.44 Kbytes/s) 5592 bytes received in 8.6 seconds (0.63 Kbytes/s) 93042 bytes received in 1.6e+02 seconds (0.56 Kbytes/s) Evidently there is a routine that tries to print flonums rationally. Evidently it fails miserably (``1.6e+02'' ??). Presumably part of the problem is that presumably unix doesn't have a standard routine you could just *call* to print a flonum. This isn't one of your namby-pamby hand-holding systems; real men can write flonum output routines, and if you can't hack it you should go back home to Mama. More likely they told the standard routine to take three columns to print it and when it can't do it in three columns it gives up all notions of propriety and goes into magic cryptic mode. What you didn't realize is that in the unix standard notation, "1.6e+02" means that the exponent is in octal but the mantissa is in decimal. The base is ambiguous. Am I the only one who keeps thinking of natural logs when I see xxxe+yyy?   From: MY Date: Wed, 6 Feb 91 19:39:14 EST Subject: Epiphany from shell scripts? From: JG Date: 4 Feb 91 21:21:27 GMT Newsgroups: comp.arch Subject: Re: Computers for users not programmers From article , by CS: > According to JG: > [...] >>The most productive programmers I have known here have >>only recently been introduced to UNIX (most think it's >>horrible). > > This anecdotal evidence proves nothing. Anyone who > changes environments will notice only the features missing > from their old environment, since the new and potentially > useful features aren't yet a part of their work patterns. > Thus, initial reactions to an environment change will > almost always be negative. No surprise here. Exactly. Which is why the part of my article that you _cut_ is relevant here. The people I'm talking have used _many_ different systems and have switched many times. They _know_ what's involved in moving to a new system. They _have_ learned a lot about the UNIX environment (in spite of only recent exposure - for most systems, "recent" would be defined as "the last few weeks", on UNIX the definition is more like "the last year or so"; because UNIX is _MUCH_ harder to come to speed on). The conclusion is that UNIX does _not_ have sufficient capability to offset those features it lacks. But, your point is quite accurate and explains why there's so much resistence to change from UNIX users. Most of them have never used another system - or only VMS or MS-DOS - and are _very_ negative about any change to _their_ status quo. > [...] >>I'd rather learn what _they_ know than learn UNIX. > > You would trust UNIX neophytes to evaluate the value of > UNIX? To me, that decision appears very unwise. I gave them as a data point.   From: PD Date: Fri, 8 Feb 1991 10:58:38 PST X-Mailer: Sendmail/Ream version 4.15 (The Choice for a New Generation) X-Subliminal-Message: Send me all your money Subject: Disk wait? DISK WAIT?? So, here I am, running a service between EuroPARC and PARC. And, since UNIX craps out so often, I'm running it on my own machine. But, lo, what's this? 'Pon my soul, 'tis a process in disk wait. Now, once upon a time, "disk wait" meant "disk wait", right? Wait for something that's going to happen Real Soon Now, like the disk block you want coming under the head. So soon will this happen, in fact, that we might as well make the process ignore *all* signals in the meantime, 'cos a signal can't possibly get delivered before the process becomes runnable again (a dubious idea, already). But the UNIX weenies started using disk wait all over the place as "wait for something that won't take too long". What's more, their idea of "not too long" was a bit shakey, since it didn't take into account things like network services. Unclear on the concept? Indeed. So, what happens? My process is stuck in disk wait (a not uncommon experience under SunOS) and I'm going to have to reboot the workstation before anything can be done about it. Which, of course, is a real pain in the absence of any decent kind of session manager, etc. What the hell. I think I'll go to the pub instead.   From: JL Date: Fri, 8 Feb 91 14:50:55 EDT Subject: Compatible? What's that mean? Just to fill out what Steve said a little for those of us who don't use MM [and need to distinguish between "reply to author" and "reply to all recipients"]: UNIX-mail users must choose between the "r[eply]" and "R[eply]" commands. On Sun machines, the former replies to only the author and the latter replies to the author and all recipients of the original message. Unfortunately, Sun's definition of these commands is exactly the opposite of UNIX mail on virtually all other UNIX machines (or at least the non-Suns around here), and this sometimes may be a contributor to people's confusion, if one is used to executing mail somewhere else. Note that Sun's mail provides the 'set replyall' (which may be specified in the MAILRC file) to reverse the sense of 'r' and 'R', and this may help some folks. I don't know about rmail. Maybe someone else does? Doesn't this last paragraph just define the essense of Unix use?   From: DC Date: Fri, 8 Feb 91 18:28:47 -0800 Subject: .f_ckmerc I knew this .-hiding kludge was going to shaft me some day. I was always amazed it worked at all. So I moved from go4 to dec-lite. I tried to figure out how rcp worked to transfer all my files, but no matter what I did it just said 'Permission denied', so I figured I'd fall back on ftp, which has to at least loosely conform to international law. Besides, I'd used it before. Moreover, someone had given me the hint that if I wanted to transfer a lot of files, the 'prompt' command is useful. 'prompt' means "don't ask me about each file". Mnemonic, no? So I fired up an ftp and said 'get *' and it said '*: no such file or directory'. Great. No, really, I do want to get all my files. Try it again out of supersition; doesn't work any better. Well, shit. I know there's a way to do this. Try 'man ftp' out of further superstition. Luckily I haven't eaten since lunch five hours ago; you wouldn't believe some of the commands it has. (Did you know that unix ftp has a whole hairy interactive macro facility? With sixteen registers? I've no idea what the macros expand *into*; I suspect if I knew, I'd throw up anyway.) Ahah! Evidently I want the 'mget' command, which allows wildcards. Why do we have a separate command for wildcard get, I wonder? Why isn't it the default? No doubt because the wildcard facility was added by a Berkeley freshthing between bouts of D&D. OK. 'mget *'. Good thing I told it I didn't want interactive mode; it spews a lot of stuff on my screen. Seems to have worked. Quit out of ftp. Out of superstition, do an 'ls' to see that the files are there. Yup. Out of superstition, log out and log back in again to see if they are still there. Uh-oh. Prompt doesn't look right. Get an emacs. 'emacs: command not found'. What the f__k? 'more .login'. '.login: no such file or directory'. WHAT?? 'ls -a'. All the real files are there, but all the . files are missing. Oh, shit. It's all too obvious what happened. I knew I was going to get screwed by .-hiding someday...   From: WW Date: Sun 10 Feb 91 00:54:46-PST Subject: Re: .f_ckmerc So I fired up an ftp and said 'get *' and it said '*: no such file or directory'. .... Ahah! Evidently I want the 'mget' command, which allows wildcards. Why do we have a separate command for wildcard get, I wonder? Why isn't it the default? If you are going to hate unix properly, you must complain about things that are done correctly by other systems. As far as I know, there was only one FTP implementation (the Stanford TOPS20 FTP) that automatically did wildcard retrieves and sends. Other implementations went so far as to make you type "multiple get ...." The problem is that such a capability is not defined by the FTP protocol, and the contortions that one goes through to get it to work are painful. First the server has to query the remote for all the files that match the expression that was typed (using NLST or LIST). Of course, neither what constitutes a wildcard nor what a filename looks like are standardized anywhere, so there might be problems parsing the results, or picking the local hostnames to copy the files to. I remember ending up with a unix directory full of files called things like "MC: HUMOR; PURITY MALE", for example, thanks to such ambiguities.   From: DC Date: Mon, 11 Feb 91 12:48:03 -0800 Subject: Ftp Wildcards Have Worked Right Since 1978 If you are going to hate unix properly, you must complain about things that are done correctly by other systems. Ahem. This is the sort of namby-pamby line handed to us by kindergarten teachers. ``If you can't say anything nice, don't say anything at all.'' And people who tell you not to criticize Bush because you probably wouldn't do any better if YOU were president. In any case, the lisp machine has done this properly since the late 1970s. So far as I can tell, computer science has been executing a rapid rearward strategic advance since 1980, starting with the loss of the TKTVs.   Date: Mon, 11 Feb 1991 17:25-0500 From: KP Subject: Re: Ftp Wildcards Have Worked Right Since 1978 Comments: Aleph, your From field is missing appropriate domain qualifiers after dec-lite. Date: Mon, 11 Feb 1991 15:48 EST From: DC ... In any case, the lisp machine has done this properly since the late 1970s. I'm glad someone made this point. Perhaps the real point should not be that ftp wildcards are not done right in unix, but that in fact unix (and so many other operating systems, for that matter) still have to use ftp at all. After all, for many years not only have lispms done `ftp wildcards' right, but they have also successfully kept most users from even knowing that FTP was involved at all by making the entire FTP-level dialog occur at an internal level not ever seen by most users. Most lispm users would be shocked to know the complexity of what goes on underneath an innocent-looking lispm command like: Command: Copy File (pathnames of files) PETER-PAN:[JOE]FOO.LISP;* (to) PEGASUS:/ufs/misc/joe/* But mostly those users are happy that they never have to know. The sad part about unix is not just that people have to know about ftp programs, connection protocols, details of filename syntaxes and how to convert them, etc. but that the implementors aren't even apologetic, and perhaps don't even realize that there's something amiss. So far as I can tell, computer science has been executing a rapid rearward strategic advance since 1980, starting with the loss of the TKTVs. That's for sure.   From: DC Date: Mon, 11 Feb 91 15:24:57 -0800 Subject: Comments: Aleph, your From field is missing appropriate domain qualifiers after dec-lite. Subject: Re: Ftp Wildcards Have Worked Right Since 1978 ``Sonny, when I was your age, email *worked*. Why, you could send a piece of mail from MIT to anywhere in the country, and it would *get there*. That was in the days before the Post Office monopoly on email was declared during the Great Breakdown after the '91 War. It was before unix, even... I remember when the Department of Informatics coup imposed mandatory home unix ownership during the Japonomic War and the Weenies were given extra-Constitutional powers...'' ``Shut up, grandad, Jim is trying to plug the optical feed into this socket we found in the bomb crater on Embarcadero.'' ``Sonny, in my day, computers were *made* here in this country. In fact we led the world in computers... America was great in those days. That was before the army was spun off... It seemed like a good idea at the time; who would have thought it would lead to the Informatics coup? We'd supply the high-tech weapons and Japan would supply the money... Too bad the army was better at fighting Congress than the Brazilians...'' ``Shut up, grandad.'' ``Y'know, in my day, the screens weren't as purty, but at least they didn't have these advertising windows popping up all the time --'' ``Commerflashes, grandad.'' ``Yeah, yeah, whatever you call them... and you could *understand* computers, because you could always look at the source code if they did something strange...'' `` `Source code.' '' ``You know, the programs. The guts, what makes the computers work.'' ``Oh, come on, grandad, everybody knows you have to have a Jap brain to understand computers.'' ``Don't you believe that racist propaganda! Why, in my day, I understood computers just fine, and I'm white as the driven snow.'' ``Yeah? So if you are so smart, why don't you fix the Cybermate, eh? Shit. If you're so smart, why can't you get email to Mom in Colorado, huh? If you're so smart, why don't you get the wires out of Mike's brain? If you're so smart, how come are you on Nippon Third World Aid like all the rest of us? Answer me that! Or shut the f**k up!''   From: TK Date: Mon, 11 Feb 91 17:31 EST Subject: Re: .f_ckmerc The lisp machines, of course, allow the use of FTP to do transparent remote file access within arbitrary applications, without having to explicitly transfer the file. Someday Unix will "invent" this idea, and we'll have another Bill Joy.   From: JW Date: Fri, 15 Feb 91 22:32:27 EST Subject: Bugs Everywhere This from Berkeley. I wonder how they could tell the difference? Subject: 4.3BSD-Reno fsck fix From: bostic@okeeffe.berkeley.edu (Keith Bostic) Index: sbin/fsck/pass2.c 4.3BSD-Reno Description: There is an uninitialized variable in the version of fsck(8) distributed with 4.3BSD-Reno which can cause fsck to destroy the file system instead of repair it. Note, this problem is ONLY found in 4.3BSD-Reno systems. Fix: Apply the following patch: [....]   From: DC Date: Mon, 18 Feb 91 17:30:13 -0800 Subject: [Funny Sco Unix Story] A friend of mine runs the bugfix BBS for SCO (a maker of unix for too-small computers). She forwarded me the following: Date: Fri, 08 Feb 91 16:06:19 -0500 From: SE Subject: Funny Sco Unix Story [...] at sco last week, they told me that their customer service line had received a call from a US Army dude who was calling from inside his M1 tank in the Saudi desert. apparently, SCO Unix runs on one of the computers in the tank. The customer service person pointed him to the SCO BBS system and he dialed it and downloaded the bug fix. Good to know that our defense is in capable hands.   From: WW Date: Tue 19 Feb 91 16:25:03-PST Subject: Re: Worse is better >> I once went to hear a talk by Thompson at MIT. Thompson >> said one of the professors had said to him, "I hate you. >> UNIX stopped all research in operating systems." Thompson >> apologized. Actually, it's more the hardware vendors fault. For about 15 years now, the solution has been to throw more hardware (memory, cpu cycles, graphics co-processors, and so on) at the users. UNIX has the dubious advantage of looking more like "a real operating system" to the microprocessor crowd (who are used to CPM/MSDOS/etc). So they think that by installing unix, it makes their system into a "real computer". In fact, unix is just a minicomputer operating system (at best). So what they end up with is a box with more MIPs than a 70s mainframe, more memory than a 70s mainframe, more disk than a 70s mainframe, and a 70s minicomputer operating system. And it runs about as fast as a 70s minicomputer, asn supports as many users. The wonder is that anyone is surprised.   From: EB Date: Tue, 19 Feb 91 16:42:55 PST Subject: Another Reason To Hate C Consider the following code fragment: 1 switch (something) 2 { 3 case THIS_CASE: 4 do_this_case(); 5 break; 6 caseTHAT_CASE: 7 do_that_case(); 8 break; 9 } This is legal C. What looks like the start of the code for THAT_CASE is in fact just a label named "caseTHAT_CASE". The compilers I've tried all silently accept this. Now consider the possibility that THAT_CASE only happens once in a blue moon. This seems like pretty severe punishment for a typo. In fact, this is almost as bad as the infamous Fortran DO 100 I = 1.10 error.   From: PB Date: Tue, 19 Feb 91 20:41:30 EST Subject: Re: Another Reason To Hate C Of course this is legal C too; switch( value ) { case 1: stuff; break; case 2: more_stuff; if( something_or_other ) { >>> case 3: even_more_stuff; } break; } (altho the Green Hills C compiler used to reject it -- I found THAT out because cfront (the preprocessor for the C++ alleged "language") put out unneeded {}'s around the case tags) Now I seem to recall BLISS allowed you to have the case "tags" be expressions! Not only that, but in COMMON BLISS (the DEC (per)versions) of BLISS-11) you could "switch" on more than one value!!   From: AB Date: Tue, 19 Feb 91 21:41:08 EST Subject: Re: Another Reason To Hate C I feel compelled to submit the following piece of C code: switch (x) default: if (prime(x)) case 2: case 3: case 5: case 7: process_prime(x); else case 4: case 6: case 8: case 9: case 10: process_composite(x); This can be found in Harbison and Steele's "C: A Reference Manual" (page 216 in the second edition). They then remark: This is, frankly, the most bizarre switch statement we have ever seen that still has pretenses to being purposeful. In every other programming language the notion of a case dispatch is supported through some rigidly authoritarian construct whose syntax and semantics can be grasped by the most primitive programming chimpanzee. But in C this highly structured notion becomes a thing of sharp edges and lose screws, sort of the programming language equivalent of a closet full of tangled wire hangers.   From: IH Date: Wed, 20 Feb 91 14:13:40 EST Subject: Re: Another Reason To Hate C From: AB Date: Tue, 19 Feb 91 21:41:08 EST I feel compelled to submit the following piece of C code: switch (x) default: if (prime(x)) case 2: case 3: case 5: case 7: process_prime(x); else case 4: case 6: case 8: case 9: case 10: process_composite(x); This can be found in Harbison and Steele's "C: A Reference Manual" (page 216 in the second edition). They then remark: OK. How about: switch (x) default: if (prime(x)) { int i = horridly_complex_procedure_call(x); case 2: case 3: case 5: case 7: process_prime(x, i); } else { case 4: case 6: case 8: case 9: case 10: process_composite(x); } Is this allowed? If so, what does the stack look like before entry to process_prime() ?   From: MP Date: Wed, 20 Feb 91 14:29:39 EST Subject: Re: Another Reason To Hate C I saw no hatred in your message. It seemed to be mainly a request for real-live actual technical information. This is the wrong list. This list is for vitriolic pronouncements about the brain-damage of UNIX. You probably want one of those news things where the Unix Weenies (TM) hang out...   From: DW Date: Wed, 20 Feb 91 11:39:01 PST Subject: Re: Another Reason To Hate C OK. How about: switch (x) default: if (prime(x)) { int i = horridly_complex_procedure_call(x); case 2: case 3: case 5: case 7: process_prime(x, i); } else { case 4: case 6: case 8: case 9: case 10: process_composite(x); } Is this allowed? If so, what does the stack look like before entry to process_prime() ? -ian I've been confusing my compiler class with this one for a while now. I pull it out any time someone counters my claim that C has no block structure. They're usually under the delusion that {decl stmt} introduces a block with its own local storage, probably because it looks like it does, and because they are C programmers who use lots of globals and wouldn't know what to do with block structure even if they really had it. But because you can jump into the middle of a block, the compiler is forced to allocate all storage on entry to a procedure, not entry to a block. This brain damage is, of course, due to praying to "simplicity of implementation" when implementing switch and goto, without worrying about "the right thing."   From: IH Date: Wed, 20 Feb 91 14:45:51 EST Subject: Re: Another Reason To Hate C Date: Wed, 20 Feb 91 14:29:39 EST From: MP I saw no hatred in your message. It seemed to be mainly a request for real-live actual technical information. This is the wrong list. This list is for vitriolic pronouncements about the brain-damage of UNIX. You probably want one of those news things where the Unix Weenies (TM) hang out... God, what a loser. If you were a REAL man, you would see invective inherent in the question itself. Get off this mailing list, you stupid twinkie-stuffing, D&D-playing weenie.   From: IH Date: Wed, 20 Feb 91 14:52:43 EST Subject: Re: Another Reason To Hate C Date: Wed, 20 Feb 91 11:39:01 PST From: DW OK. How about: switch (x) default: if (prime(x)) { int i = horridly_complex_procedure_call(x); case 2: case 3: case 5: case 7: process_prime(x, i); } else { case 4: case 6: case 8: case 9: case 10: process_composite(x); } Is this allowed? If so, what does the stack look like before entry to process_prime() ? I've been confusing my compiler class with this one for a while now. I pull it out any time someone counters my claim that C has no block structure. They're usually under the delusion that {decl stmt} introduces a block with its own local storage, probably because it looks like it does, and because they are C programmers who use lots of globals and wouldn't know what to do with block structure even if they really had it. But because you can jump into the middle of a block, the compiler is forced to allocate all storage on entry to a procedure, not entry to a block. But it's much worse than than because you need to invoke this procedure call before entering the block. Preallocating the storage doesn't help you. I'll almost guarantee you that the answer to the question "what's supposed to happen when I do ?" used to be "gee, I don't know, whatever the PDP-11 compiler did." Now of course, they're trying to rationalize the language after the fact. I wonder if some poor bastard has tried to do a denotational semantics for C. It would probably amount to a translation of the PDP-11 C compiler into lambda calculus.   From: JW Date: Wed, 20 Feb 91 15:21:25 EST Subject: Re: Another reason to hate C Date: Wed, 20 Feb 91 11:39:01 PST From: DW [...] I've been confusing my compiler class with this one for a while now. I pull it out any time someone counters my claim that C has no block structure. They're usually under the delusion that {decl stmt} introduces a block with its own local storage, probably because it looks like it does , and because they are C programmers who use lots of globals and wouldn't know what to do with block structure even if they really had it. But because you can jump into the middle of a block, the compiler is forced to allocate all storage on entry to a procedure, not entry to a block. Hey, bud, whadduh mean we dont got no block structure? Of -course- we got block structure. In fact, we got so much block structure that at least one C compiler I know of allocates the storage for a block when you enter the block, just like you might expect. You jump, you lose. I asked them about this. "Gosh, wow, why would you want to do that?" On a kinder note (sorry), it really does seem to be true that most modern C compilers (read: ones that don't think "flow analysis" is something you do to the drains after you've peeled too many veggies into your kitchen sink) will (yow!) -actually detect- which blocks can't be jumped into the middle of, and block-allocate storage whenever they can legally do so.   From: EB Date: Wed, 20 Feb 91 15:15:24 PST Subject: Re: Another Reason To Hate C From: IH Date: Wed, 20 Feb 91 14:13:40 EST OK. How about: switch (x) default: if (prime(x)) { int i = horridly_complex_procedure_call(x); case 2: case 3: case 5: case 7: process_prime(x, i); } else { case 4: case 6: case 8: case 9: case 10: process_composite(x); } Is this allowed? If so, what does the stack look like before entry to process_prime() ? I hate to supply useful information about C on unix-haters, but I'd like to terminate this line of questions. In C (K&R and ANSI) this is allowed. It is explicitly stated that initializations for variables are not performed when a goto is made from outside a block to the inside of a block. In this case, that means i is uninitialized in the call to process_prime if x is 2, 3, 5 or 7. In C++ this is not allowed, mainly because it is bad karma to call a destructor for something for which the constructor was not called. Just because this is well defined doesn't mean one has to like it.   From: EB Date: Wed, 20 Feb 91 15:43:11 PST Subject: Re: Another reason to hate C Date: Wed, 20 Feb 91 11:39:01 PST From: DW I've been confusing my compiler class with this one for a while now. I pull it out any time someone counters my claim that C has no block structure. They're usually under the delusion that {decl stmt} introduces a block with its own local storage, probably because it looks like it does, and because they are C programmers who use lots of globals and wouldn't know what to do with block structure even if they really had it. But because you can jump into the middle of a block, the compiler is forced to allocate all storage on entry to a procedure, not entry to a block. Not quite. It is possible for the compiler to adjust the stack pointer to match its depth inside the block before doing the jump, just as it might be necessary to adjust the stack in the other direction before jumping out of a block. This brain damage is, of course, due to praying to "simplicity of implementation" when implementing switch and goto, without worrying about "the right thing." Yes, and they've succeeded. Hordes of grumpy C hackers are complaining about C++ because it's too close to the right thing. Sometimes the world can be a frightening place.   From: DC Date: Wed, 20 Feb 91 16:02:41 -0800 Subject: Re: Another reason to hate C Yes, and they've succeeded. Hordes of grumpy C hackers are complaining about C++ because it's too close to the right thing. Sometimes the world can be a frightening place. I've been wondering about this. I fantasize sometimes about building better programming environments. It seems pretty clear that to be commercially viable at this point you'd have to start with C or C++. A painful idea, but. What really worries me is the impression that C hackers might actively avoid anything that would raise their productivity. I don't quite understand this. My best guess is that it's sort of another manifestation of the ``simple implementation over all other considerations'' philosophy. Namely, u-weenies have a fixed idea about how much they should have to know in order to program: the amount they know about C and unix. Any additional power would come at the cost of having to learn something new. And they aren't willing to make that investment in order to get greater productivity later. This certainly seems to be a lot of the resistance to lisp machines. ``But it's got *all* *those* *manuals*!'' Yeah, but once you know that stuff you can program ten times as fast. (Literally, I should think. I wish people would do studies to quantify these things.) If you think of a programming system as a long-term investment, it's worth spending 30% of your time for a couple years learning new stuff if it's going to give you an n-fold speed up later.   From: PB Date: Wed, 20 Feb 91 16:04:14 PST Subject: Re: Another Reason To Hate C Date: Wed, 20 Feb 91 15:15:24 PST From: EB From: IH Date: Wed, 20 Feb 91 14:13:40 EST OK. How about: switch (x) default: if (prime(x)) { int i = horridly_complex_procedure_call(x); case 2: case 3: case 5: case 7: process_prime(x, i); } else { case 4: case 6: case 8: case 9: case 10: process_composite(x); } Is this allowed? If so, what does the stack look like before entry to process_prime() ? [Description of C rules and justification deleted for your mental health] Just because this is well defined doesn't mean one has to like it. This whole line of discussion is making me ill. Now that we have the apparently definitive answer, can we stop beating this horse? Oh, how I wish it were a dead horse, but this live one doesn't respond at all to beating.   From: MT Date: Wed, 20 Feb 91 19:11:48 EST Subject: Nothing To Do With C From: MH Date: 25 Jan 91 12:43:00 -0800 Subject: Raves for Sun ____________________________________________________________________________ ___ _____ ___ / \ | | | | | | | | | / \ | | | |\ | |\ | | | | | \___ | | | \ | | \ | |___ | | \___ \ | | | \ | | \ | | \ / \ | | | | \| | \| | \ /\ / | \___/ \____/ | | | | |____ \/ \/ \___/ ____________________________________________________________________________ November 8, 1990 YOU CAN'T FOOL 'EM DOWN ON THE FARM! Real Americans talk About Why They Chose the Sun SPARCstation 2000 (tm) "Wow - with a workstation that powerful, I could get twice as much milking done." - Mrs. Elaine Noose, Scumwater, Oklahoma "Out here on the farm, you really learn to appreciate the value of good graphics resolution." - Ted Lumplin, Brat's Head, Nebraska "After we lost most of our cattle stock to pellegra, our barn burned down. After that, Joe got himself caught in the thresher and lost most of his body hair. Then the banks foreclosed. It sure was a comfort to know that we had 28 MIPs of power to see us through hard times." - Darrell LaQuench, Pine Agony, Maine "I believe that Virtual Quilting, using high-speed networking services, will be the wave of the future." - Mrs. Jane Dobrynin, Fleughh, Utah "Last week we had a fella from Digital come out and look at the soybean crop. After 20 minutes, Ma chased him off and threw his keyboard out the window. We`re from old Norwegian stock, and we know a thing or two about bus controllers." - Buck Flange, Arkansas, Texas Why has the SPARCstation 2000 caught the imagination of the American working man and working woman like no other computer in its class? Maybe it's the extra features, like the padded Corinthean leather screen, or the safety air bag that inflates when the typing buffer gets too full. Maybe it's the tradition of honest service and free doughnuts. Then again, maybe not. Sun Microsystems. A Step Ahead of Your Cows.   From: TK Date: Thu, 21 Feb 91 14:24 EST Subject: Re: Another Reason To Hate C This certainly seems to be a lot of the resistance to lisp machines. ``But it's got *all* *those* *manuals*!'' There is a certain irony in this for those of us who recall the early complaints about lisp machine environments. The most vocal complaint of the establishment computer science community was that this system was just a hack, and that besides no one could understand it because there were no manuals. Here in the future, `man' serves as the constantly available, online, up to date information resource we know and love. In the words of the famous song `Who could ask for anything more'.   From: SS Date: Thu, 21 Feb 91 16:30:51 EST Subject: No Need To Fix Vi Under Warranty Quoted out of context from RISKS: Date: Wed, 20 Feb 91 20:21:30 CST From: s@poincare.geom.umn.edu Subject: Re: Software Warranties It seems clear that safety-related bugs, like holes in operating systems, should be fixed for free. And if there is gross misrepresentation of what the software does, or if it is so flaky as to be unusable, you would want a refund. If you buy a "screen editor" and get "ed", you return it. But if you get "vi", I'm afraid you're stuck with a few minor problems and shouldn't expect to have them fixed. Everyone seems to know bugs in "vi" (especially in autowrap), but don't hold your breath waiting for Sun or Silicon Graphics or anyone like that to fix them. The bugs are often annoying, but "vi" is still quite useful, and does its basic job.   From: SS Date: Thu, 21 Feb 91 16:37:57 EST Subject: Du And Injustness Just how hard, I ask you, is it to print a number RIGHT-JUSTIFIED in a 7-digit column. Is this too much to ask for in a utility whose sole purpose is to help you identify big numbers? ------------------------------------------------------------------------------ omega@hose-me> du -s * 6788 ImageMagick 4 READ_ME 19660 SGI_VGX_HiVision 258544 X 574684 alpha1 404980 apE 4528 cga_bin_ds5000 305720 cga_bin_hp835 5508 cga_include 40436 cga_lib_hp835 78856 dead 172220 djs 980 graphics-gems 324 include 3748 make-3.59 29768 man_hp835_7.0 8772 marg 274608 mikey 34340 mikey.incbak 61412 paul 13588 pbm 653256 pieper 440760 pix 20984 rti 4 smd 7224 softbench 80720 straz 4 tag 756 tar.2.6.91 18180 thesaurus 3692 tib 21396 tiff 70472 utah 4268 wave 485968 wave_sig90   From: DH Date: Thu, 21 Feb 91 13:40:37 PST Subject: Re: No Need To Fix Vi Under Warranty Actually, if you ask for a screen editor and get vi you should complain until they give you a real editor like emacs. Preferably with a teco interpreter.   From: DC Date: Fri, 1 Mar 91 14:27:50 -0800 Subject: A Joke In Every Sentence In a fit of work avoidance, I just flipped open a copy of The Sun Observer, and read the following from a ``helpful hints'' type column. It is NOT A JOKE. Using noclobber and read only files only protects you from a few occasional mistakes. A potentially catastrophic error is typing rm * .o instead of rm *.o In the blink of an eye, all of your files would be gone. A simple yet effective preventive measure is to create a file called -i in the directory in which you want extra protection: touch ./-i In the above case, the * is expanded to match all of the filenames in the directory. Because the file -i is alphabetically listed before any file except those that start with the character: !#$ percent&`()*+,. The rm command sees the -i file as an argument. When rm is executed with the -i argument, files will not be deleted unless you verify the action. This still isn't perfect. If you have a file that starts with a comma in the directory, it will come before the file starting with a dash and rm will not get the -i argument. SunOS's make utility creates file starting with a comma if the make file understands hidden dependencies by having the following line in the make file: .KEEP-STATE: The -i file also won't save you from errors like rm [a-z]* .o The bit about files that appear before -i is garbled in the original. I blame nroff.   From: DC Date: Tue, 5 Mar 91 13:52:52 -0800 Subject: Spell Checking For the first time since the demise of ITS I just tried to spell a document. The available tools were the unix spell and the symbolics one. The both suck worse than you can imagine, on six different dimensions at once. It's very hard to believe, in particular, that the person who wrote the symbolics one ever tried to use it; there were about nine obvious bugs manifested in spelling my file, each of which could only required been a ten line fix. I ended up using the symbolics one over the unix one, however, because while the unix one was marginally less stupid its output was considerably less interpretable. How hard can it be to write a spell program? Honestly.   From: JW Date: Wed, 6 Mar 91 5:17:04 EST Subject: Duh. Oh, I see. I tried this UW (unix windows) program on the Mac. I thought it seemed really slow. I didn't see why it should be so slow. I was bummed, because it is otherwise way useful. The problem is, I'm a twit. More specifically, I have been left back in the late 70's by modem technology, which has apparently advanced (euphemism) by leaps and bounds since then. UW, here, comes up thinking that it should talk to the modem at 2400 baud. So, it does. Now, I know full well that this modem is set at 9600 baud, 'cause I've been using it at 9600 for years. _But the modem knows better_. Apparently, the modem hasn't got a fixed speed, even though its little tiny electronic mind is set to tell it 9600. It just happily ignored that fact completely, and set itself to 2400. I wonder, if I type ITS commands to a unix, maybe it'll... Nah. Rats.   From: DC Date: Wed, 6 Mar 91 11:05:22 -0800 Subject: [postmaster@att.att.com: ] This is a mysterious error message, to say the least. From: postmaster@att.att.com Date: Tue, 5 Mar 91 17:05:59 EST To: aleph@hpela.lun Mail to `at.dot.at!bang' alias `at!bang' from 'som.ewhe.re!at' failed. The mailer `exec route.uucp 'som.ewhe.re!at' 'att'' returned error status 100. The error message was: uux failed ( -1 ) ...   Date: Wed, 6 Mar 91 11:17:03 -0800 From: DC Subject: Spell Follow Up At a risk of failing my vituperative duty: Apparently there is an ITS-style speller for unix called ispell. It's supposed to be good. I haven't tried it yet. (Sorry to be useful, here.) Several people from Symbolics offered to try to fix the problems with their spell program. Another reason to keep using a 1980-technology machine whose yearly maintenance cost is the same as the purchase cost of the ten-times-faster SPARC my officemate uses...   From: SS Date: Sun, 10 Mar 91 09:41:44 EST Subject: ps - A Great Feature For Protecting Viruses Lou Reed says you can't depend on intelligence - you need a busload of faith to get by. Just a minor little joy - you can't depend on "ps" to tell you the name of a process, either. Whenever I fire up a big lisp process on my HP835, there's a good minute or so where ps can return damn near anything it wants as the process name. It must be ashamed - usually it names my lisp process after whatever I ran last - like /usr/local/emacs, /usr/bin/mail, or /usr/local/3d (my rendering application). One reason why this is so thrilling for me is that I was attemping to write a smart utility (silly me) that makes sure there's exactly one copy each of 3d and lisp running on my machine. This is so they can keep talking to each other as needed, even if something crashes. Of course, it was stupid for me not to realize that when ps tells me that there's a running process called /usr/local/3d, what it REALLY means is that there's no 3d process running at all, and lisp is starting up instead. My utility kept trying to gun the errant 3d process, but it was lisp that got killed by friendly fire every time. Here for example, are two consecutive runs of ps. Notice how process 6124 decides to disguise itself as the very grep command that's looking for it. Now, THERE's a survival trait for you virus authors. iguana@okay> ps -ef | grep lisp iguana 6140 5146 4 09:14:57 ttysa 0:00 grep lisp iguana 6124 5921 36 09:14:40 ? 0:03 grep lisp iguana@okay> ps -ef | grep lisp iguana 6142 5146 2 09:14:59 ttysa 0:00 grep lisp iguana 6124 5921 31 09:14:40 ? 0:04 /ok/usr/local/lisp/biglisp   From: MT Date: Sun, 10 Mar 91 12:54:22 PST Subject: UNIX In The Office This is verbatim text from "Exploring the UNIX System, Second Edition", probably reprinted without appropriate permissions: Don't confuse the `calendar' command with the file of the same name. The `calendar' file myst reside in your `HOME' directory in order to get automatic once a day processing of the file (if supported on your system). However, when you execute the `calendar' command, it looks for the file `calendar' *only in the current directory*. This means that you should be in you `HOME' directory whenever you execute this command. The `calendar' command is not very intelligent ... Since my `PATH' environment variable searches `.' first, I can't run `calendar' where I would usually want to: from my `HOME' directory. What brain-damage! You would think that between the first and second editions they would have had the decency to fix this!   Date: Sun, 10 Mar 1991 16:26-0500 From: KP Subject: Re: UNIX In The Office Maybe it was on someone's calendar to fix, but they never see it because they can't run the program either. Hmm. I used to think the strength of lisp machine tools came from the fact that the developers actually used them regularly in their work and depended on them in order to develop everything they were going to need in the next generation system. That is, I though that there was a causal link between using your own tools and making them better. But maybe it's not whether you use your own tools that makes them good, but rather that the goodness or badness of your tools is just magnified over time by continuing to use them. That would explain a lot of things about Unix...   From: CS Date: Mon, 11 Mar 1991 02:34-0500 Subject: [Re: Risks of naming a node [RISKS DIGEST 11.20]] ----- Begin Forwarded Message ----- Date: Tue, 5 Mar 1991 18:26 EST From: PF Subject: Re: Risks Of Naming A Node [RISKS DIGEST 11.20] Around 1983, the research group I worked in had a machine whose full name was MIT-FLAME-OF-THE-FOREST. Several FINGER programs around the Internet are said to have broken when they encountered it, unprepared for such a long name. My present machine has prompted some problems -- "islington-terrace" is too long for its own disk label, so it must boot under an alias and find out its full name later. It used to have the alias "it," until a broken local mailer started sending me all the mail destined for Italy. ----- End Forwarded Message -----   From: HM Date: Mon, 11 Mar 91 17:46:20 EST Subject: What The...? I was running the SPICE circuit simulator remotely on the MIT CRAY-2 from my Lisp Machine. The CRAY is running UNICOS, Cray's SysV unix OS. It seemed to be working fine, but then it stopped working for one of my designs. SPICE couldn't seem to find my input file which I had written out, with the name of module as a prefix: SPICE-BACK-PORT.sp I checked the input file which was written to the CRAY and, yes, it had been truncated to 14 characters. Just like MS-DOS. (BTW, could someone add me to this mailing list-- I now have a Sparcstation 2 on my desk, and boy, is it a blast. I've never seen anything that can compare to Sun's suninstall program. )   From: JM Date: Fri, 15 Mar 91 22:44:07 PST Subject: Weenie Limits, Weenie Robustness In 1991. Sigh. % egrep baselisp *.lisp [Huh? I *KNOW* it's in there somewhere.] % cat build-base.lisp | egrep baselisp (defun build-base (&optional (name "/usr2/pc386/baselisp")) [Well, there it is. So why did egrep fail?] % egrep baselisp build-base.lisp (defun build-base (&optional (name "/usr2/pc386/baselisp")) [Hmm. Egrep didn't fail. Globbing failed. But why?] % ls *.lisp 386-patch.lisp bug-5634.lisp build-app.lisp cold-prep.lisp make-subs.lisp makefile.lisp params.lisp prep-aux.lisp setup.lisp x.lisp [What the ?? I just saw build-base.lisp] % ls b* build-base.3bi: No such file or directory build-base.lis: No such file or directory bug-5634.3bin bug-5634.lisp build-app.3bin build-app.lisp build-kernel build-lisp.old [Oh, right. If a 15-char filename is in the directory the shell can't find it when it expands *.] % In 1991. Sigh. And of course the reason I'm even doing anything here is that a bug in the 387 emulator kills my lisp session (and has the gall to indicate normal program termination) on the first floating point interrupt of any kind that follows any one of a few particular kinds of fp interrupts (like division by 0.0). But of course, processes are cheap. People expect a few to die randomly and perversely every day. In 1991. Sigh. Sometimes I feel that putting lisp on unix is a bit like making a silk purse out of a sow's ear. jlm   From: AB Date: Sun, 17 Mar 91 23:04:09 EST Subject: Help Stamp Out The Smiley! [ If you overlook the writer's annoying habit of labeling everybody a net.something, he makes a good point about Unix culture. -AB ] From: RT Newsgroups: sci.skeptic Date: 17 Mar 91 21:58:40 GMT Summary: Stamp out the damn things. Subject: The Devolution Of The Smiley (was: CSICOP name ...) ----- In JS writes: >> P.S. I think he was kidding, by the way. In some article (TG) writes: > Yes, I found that out later. Initially, I wasn't sure due to > the lack of a ":)" or something of that nature. Sigh. Initially, the smiley had a fairly small ecological niche. It was used by the careless to protect a humorless offering from well-deserved rejection. Since people are afraid of not catching a joke, or appearing louts for over-serious or heavy-handed response to flip remarks, the smiley served its purpose. The average net.denizen was swallowing the bitter product from the net.dimwitted, because the smiley disguised its odor. It spread from this niche opportunistically. Quickly, the net.skunk realized that in spreading its stupid and vicious offal, in hopes that net.denizens would eat it, the smiley would help disguise its nature. Soon, the most noxious posts were laced with this device. Somehow, this voluntary symbiosis has become mandatory. Many net.denizens have learned to recognize the smiley, and ignore the nature of what surrounds it. (There is an explanation for this seemingly unrewarding behavior: it is easy to recognize a smiley, more difficult to tell the nature of the the many other objects in networld.) So, many net.denizens gobble up offal if it is laced with smileys, and pass by flowers if they are not infected with this pest. It has gotten to the point that those who make flowers are treated like the net.skunks who drop offal unless those flowers are so infected. "How was I to know it was humor -- it didn't have a smiley." A guy who would say this probably doesn't date women unless they wear skirts. Feh! And feh again! The smiley is an attack on writers and readers alike. If it is funny, it doesn't need a smiley. If is not funny, a smiley won't help it. The smiley teaches writers that anything they write will pass as humor as long as it is punctuated properly. It teaches readers that they must ignore their better judgment, and look only at punctuation to determine intent. It is time to eradicate this pest. Don't use. Ignore it when it appears in postings. Remove its ecological niche, and soon it will disappear. Russell   From: PD Date: Tue, 19 Mar 1991 11:36:16 PST X-Mailer: Sendmail/Ream version 4.15 (The Choice for a New Generation) X-Subliminal-Message: Send me all your money Subject: Signatures RK signed a recent message on a mailing list: > Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.   From: RZ Date: Tue, 19 Mar 91 19:39:09 -0800 Subject: Wait, I Thought RISC Was A *Good* Idea "RISC is to hardware what the UNIX operating system [sic] is to software." SPARC Documentation, RISC Tutorial, page 2   From: Andy Beals Date: Thu, 21 Mar 91 12:17:06 -0800 Subject: Of Filesystems And Inodes Boy do I ever hate it when the pinheaded system runs out of inodes. "/usr, write failed, out of inodes". You go and do a "df" in order to find out how much space there *is* left and you find out that inodes are the only thing in short supply - there could be jillions and jillions of megabytes of space left on the stoopid thing but it won't allocate these magical "inodes" out of the regular "free space" on the drive or visa-versa. Why don't programs which shouldn't lose data [like the mail programs] check to see if they're filling up the stupid disk and turn themselves off appropriately? I guess Eric Allman was just too damn busy putting in back doors rather than checking to see if the latest write() call that he executed returned bad status.   From: SM Date: Fri, 22 Mar 1991 10:47-0500 Subject: Query As DLW says, "C++ is the C of object oriented programming languages."   From: WW Date: Fri 22 Mar 91 17:58:59-PST Subject: Re: Wait, I Thought RISC Was A *Good* Idea "RISC is to hardware what the UNIX operating system [sic] is to software." Subject: Wait, I thought RISC was a *good* idea No, the quote is exactly right. RISC is a lazy solution along the lines of "well, we don't know how to write compilers that use complex instructions efficiently, and we don't know how to design complex hardware that runs fast, so we'll make everything simple, and we can advertise we run at 80Mhz even though the system supports fewer user than a 1 MIP DEC-20." It's exactly analagous to "you can use pipes and redirection shell scripts to do anything, so we don't have to write any REAL programs" and "portability is more important that usability" philosophies so rampant in the unix world. (Was I properly vitrolic this time?)   From: JW Date: Fri, 22 Mar 91 21:34:47 EST Subject: Re: Wait, I Thought RISC Was A *Good* Idea Date: Fri 22 Mar 91 17:58:59-PST From: WW No, the quote is exactly right. RISC is a lazy solution along the lines of "well, we don't know how to write compilers that use complex instructions efficiently, and we don't know how to design complex hardware that runs fast, so we'll make everything simple, and we can advertise we run at 80Mhz even though the system supports fewer user than a 1 MIP DEC-20." (Was I properly vitrolic this time?) Hey. This is unix-haters, not RISC-haters. There's another list for that, except it's called RISKS, and - what? That's about something completely different? Oh, sorry. Never mind. Yesterday, I had the extreme pleasure of being killed by two birds with one stone, as I found it necessary to install unix on a PC clone. This, I must point out was not just any unix, but AT&T System 5 Release 3.2 Version 2.1 (Consider It Standard). So fine; for those of you not familiar with PC's (like me), the first thing you do in a situation like this is to tell the PC what sort of disk you have. No problem. 918 cyls, 15 heads, 17 sectors per track. The PC remembers this in battery backed-up RAM, and there's a standard BIOS call to pass the info to anyone that cares. Cool. Now format the disk. No problem, the (unix supplied) formatter figures out that there are 918, 15, etc. and formats the disk, and happily tells me about my 120MB of disk space. Then you "partition" the disk, which is basically saying that you want to use X percent for unix and Y percent for DOS and so on, and, again cool, my (unix-supplied) partition program figures out that there are 918, 15, etc. and partitions the disk, and happily tells me about my 120MB of disk space. Then you "partition" the disk again, only this time you are talking about the usual unix "partitions", where you split the disk up into chunks. No problem, my (unix-supplied) unix-partition program happily figures out that it has 72MB of disk space to work with, and, um, wait. 72? What the f***? Eventually (and I do mean *eventually* here, since, as you have perhaps realised by now I am running unix off a floppy disk to do all this stuff), I come to the awareness that my unix partition program *knows* that my disk has 9 heads. In fact, it also knows that it has 1024 cylinders, but I can live with that. This information is compiled in. Now. Many of you would stop here, look knowingly at the person next to you, say "But of course. This is unix, after all", and throw the PC out the window. Unfortunately, the lab hasn't -got- a window, so I had to keep at it. Which, even more eventually, led to my final enlightenment. The unix kernel itself, which we haven't even gotten to yet, has disk geometry compiled in. And -it- knows that the disk has 9 heads. You can change that, of course, but not until you have it running. So to keep you from screwing yourself, the unix partition program is set up to also know that the disk has 9 heads, and partition it accordingly. Then you fire the whole thing up, reconfigure your unix kernel to have the right info for your disk, run the partition program -again- with an option that overrides the compiled-in info, re-create the file systems just wiped out by your repartitioning, and you are all set. (Fine print: This is not, in actuality, AT&T's fault. It is the fault of the here unnamed company that supplied this particular unix, and the programmer that wrote their disk driver; a person who has clearly studied the Unix Way for many, many years.)   From: DH Date: Fri, 22 Mar 91 18:58:28 PST Subject: Hating Unix Means Hating Risc Date: Fri, 22 Mar 91 21:34:47 EST From: JW Hey. This is unix-haters, not RISC-haters. Look, those guys at berkeley decided to optimise their chip for C and Unix programs. It says so right in their paper. They looked at how C programs tended to behave, and (later) how Unix behaved, and made a chip that worked that way. So what if it's hard to make downward lexical funargs when you have register windows? It's a special-purpose chip, remember? Only then companies like Sun push their snazzy RISC machines. To make their machines more attractive they proudly point out "and of course it uses the great general-purpose RISC. Why it's so general purpose that it runs Unix and C just great!" This, I suppose, is a variation on the usual "the way it's done in unix is by definition the general case" disease.   From: WW Date: Fri 22 Mar 91 18:50:50-PST Subject: I particularly like this one... Try to find somebody.... dirt23>pfind YYYYYY Didn't work. Oh yeah, Ihave my own pfind from the old days: dirt24>which pfind pfind: aliased to grep -i !* ~billw/.phonelist dirt25>alias pfind grep -i !* ~billw/.phonelist Well, I know how to fix that... dirt26>unalias pfind dirt27>alias pfind Now it should work... dirt28>pfind YYYYYY YYYYYY, Zzzz xXXXX YYYYYY Engineering Success. I wonder where thre real pfind resides... dirt29>which pfind pfind: aliased to grep -i !* ~alge/.phonelist Ho! Ho! I wonder how it knows that. I wonder why it lies. I wonder how to get it to tell me which pfind I'm REALLY using. Sigh.   From: CS Date: Fri, 29 Mar 1991 21:01-0500 Subject: PDP 11/04 I'm a little embarassed to mention where I got this, but... > Well i'm trying to restore a PDP 11/04 and am told > that a version of unix was available for it once. Now > would anyone know what it was or perhaps have it on 8 inch > floppies? Or is it just an emulator running on RT-11??   From: CM Date: Sat, 30 Mar 91 16:52:33 EST Subject: Don't miss this! I wonder if they'll be serving Twinkies and Coke for refreshments. Gaschnig/Oakley Memorial Lecture Dr. Brian W. Kernihan AT&T Bell Laboratories PROGRAMMING STYLE IN C Wednesday, April 17, 1991 3:30 PM Wean Hall 7500 ABSTRACT Good programming style leads directly to programs that work well. But most programmers have never been taught what good programming style is; as proof we need only look at their programs. In this talk I will examine some examples of C style, both good and bad, and try to draw some lessons about how to write better C programs.   From: AB Date: Wed, 3 Apr 91 15:40:59 EST Subject: Running zephyr on a terminal [ Background for Unix-Haters: Rob complained that I should be running something called "zwgc" (Zephyr WindowGram Client) so that he could send me interactive messages using the Zephyr notification system. ] After looking at the gigantic manual page for zwgc I decided that the chances were .01 that in fact just adding "zwgc &" to the right place in (the X specific part of) my .login would be sufficient. Nothing with that many features ever just works the first time on Unix. Sure enough: zwgc: error while opening /usr/lib/zephyr/acl/zwgc.desc for reading: No such file or directory So, why don't I run zwgc? Because my time is more valuable than figuring shit like this out. A civilized operating system would allow users to conveniently send each other well-behaved interactive messages without making them spend an afternoon debugging arcane new command lines in their init files. BTW, I only scanned that manual page, but given that Zephyr apparently tries to use Kerberos to authenticate messages, I'll bet that lurking further down the road is some screw involving the goddamned 8-hour expiration time on Kerberos tickets. "Zephyr", "Kerberos"... Clever names.   From: SS Date: Sun, 7 Apr 91 04:38:45 EDT Subject: Call For C++ Flames A friend of mine is a freelance writer whose latest gig is for the French computer magazine "01 Informatique". It seems their big, special edition, 25th anniversary, extra advertising (by C++ vendors) issue will be devoted to the state of the art of object-oriented programming. Quelle opportunitie, thinks I to myself. How about an article on all the ways C++ will hose you? Is there an "expert" out there who'd be willing to offer a list of reasons why C++ sucks dead toads, or can point out things that other object-oriented systems do better, or anything like that? Email responses are fine - send them to me and/or GH@no.whe.re   From: DW Date: Mon, 8 Apr 91 11:29:56 PDT Subject: Re: Call For C++ Flames Is there an "expert" out there who'd be willing to offer a list of reasons why C++ sucks dead toads, or can point out things that other object-oriented systems do better, or anything like that? The abstract for the course I am teaching this quarter: Course Announcement: CS342 Programming Language Design, 3 to 6 units. MWF 3:15 200-305 Professor DW Designing the Language that C++ Should Have Been C++, an object oriented extension of C designed to retain C's efficiency, is a very complex language. We believe that the major factor causing the complexity of C++ is a non-reliance on compiler technology. The thesis of this course is that by assuming a smarter compiler, a much simpler language, one that loses very little efficiency, could have been produced. This course will attempt to design an object oriented of C with the efficiency of C++, but without its complexity. The complexity will reside in the compiler, not in the language. We will spend our first two weeks digesting C, C++, and the last 3 years of research on object oriented languages and systems. We will then, based on purity, elegance, and implementation considerations, design the language. We will attempt to implement the language as we design it, and use implementation problems as feedback into the design. I figure that by the time we are done, we'll have a lot of "ammo." BTW, there are published papers on why C++ sucks. Now, for some flaming: From: TS Date: Mon, 8 Apr 91 14:12:51 EDT Subject: Re: call for c++ flames I started to type in a lengthy reply to this, but due to Gnu Emacs's screwy user interface for sending mail, the whole thing got deleted. And its auto-save doesn't apply to mail. Maybe I'll get back the energy to type it in again...   From: GH Date: Tue, 9 Apr 91 20:09:29 edt Subject: Advices For French Newspaper I'm currently working as a correspondent for a french newspaper preparing a special issue for their 25th anniversary. A friend of mine already sent for me on this list a call for C++ flames. The article I have to write aims at giving an overview of what OOL are expected to be in 10 years according to current research. So I'm interested in justified criticisms of C++/ Objective C compared to the Lisp world with CLOS and may be also Smalltalk. It can't be very technical because the audience is very large and includes managers. I'll have to explain everything in clear terms. They plan interviews of people like Brad Cox or Adele Goldberg. Do you know if there is any news list for OOP? Thanks for your help   From: DW Date: Tue, 9 Apr 91 23:23:45 EDT Subject: Re: Advices For French Newspaper Date: Tue, 9 Apr 91 20:09:29 edt From: GH Do you know if there is any news list for OOP? There is comp.object for OOP in general, and comp.lang.c++ for C++ in particular. If you want to get a whole lot of very hot flames, you could send your general queries to those newsgroups, but I'd advise you not to assume that what those people tell you is actually the case.   From: RA Date: Wed, 10 Apr 91 0:22:49 EDT Subject: Stop This Rational Behavior IMMEDIATELY Mr. B's keyboard has been taking a beating lately as he has been debugging unix programs again, so I'll address this for him. The unix-haters list is not for calm, rational discussion of anything, even hatred of unix and C++. If you can't say something pointless, mean, nasty, ugly, or disgusted, send it to alt.unix.sycophant. GH, you don't know any better, so you're excused this time. SS and DW, you do know better. Come up with something vitrolic or we'll put you on the BIND mailing list for a month for inspiration. My unix peeve of the week is the way shared pure "text" files (ie, normal executable programs) work. Here it is 1991 and you still can't debug a binary that somebody else is running or run a binary that somebody else is debugging, because these weenies have the fossilized remains of ancient twinkies where other people have brains and thus have still not figured out about COPY-ON-WRITE shared paging. Unix sucks big hairy moss-covered rocks from the coast of Maine.   From: DW Date: Wed, 10 Apr 91 10:10:00 EDT Subject: Re: Stop This Rational Behavior IMMEDIATELY In fact, just while I was sending the previous mail, another instance of Unix brain-damage arose in mail to me. Apparently there is no way to find out from Unix whether network host "foo" and network host "bar" are the same host or not, without connecting to each one and using some mechanism of your own, assuming that you are in a general internet situation with gateways running around and so on. The way the host tables are organized makes it impossible for them to provide this basic information in a reliable way. I frankly find it hard to see how it would be possible to so misdesign a data structure, but with Unix anything is possible.   From: DW Date: Wed, 10 Apr 91 10:03:46 EDT Subject: Re: Stop This Rational Behavior IMMEDIATELY From: RA Date: Wed, 10 Apr 91 0:22:49 EDT Unix sucks big hairy moss-covered rocks from the coast of Maine. From right off the coast of Walker Point? A recent pet peeve of mine about Unix is that if you have a socket to another Unix process, there is no way to ask whether the process at the other end is alive or not without reading stuff from the socket. This was about to be a major pain in the neck for a daemon program I was writing, until I managed to find a way not to need to know that information ("There Are Some Things Man Was Not Meant To Know!"). Another one is that if your program dies horribly inside various runtime routine (say, inside the guts of "free" it touches unmapped virtual memory), often you can't get any kind of stack trace, presumably because assembly-coded runtime support routines don't bother to leave the registers and stack in consistent states. So your program bombs and you have absolutely no idea where it is. You probably don't even know what it's doing, since the debugger just tells you the name of the most recently defined external assembler symbol "+" a random number, and the name of that symbol often has nothing to do with what you're really running in. The same thing comes up with you do profiles on a Sun 4, and it tells you that your program is spending lots of time in "w4cp" which was called "spontaneously". Sort of like when the government spends lots of money on weird covert projects with incomprehensible names and no hierarchical accountability to anything.   From: MY Date: Thu, 11 Apr 91 0:09:38 EDT Subject: Covert Projects With Incomprehensible Names [...] Sort of like when the government spends lots of money on weird covert projects with incomprhensible names and no hierarchical accountability to anything. You mean names like "Zephyr" and "Kerberos"?   From: IH Date: Thu, 11 Apr 91 14:02:34 EDT Subject: Re: Pain, Death, And Disfigurement One thing which really scares me about unix is that that USED TO WORK WHEN I WAS A SYSADMIN. It's bad enough that things like that are broken, but to have an operating system that moves backward in time is truely terrifying. What's next? Maybe they'll remove virtual memory.   From: NZ Date: Thu, 11 Apr 91 15:41 EDT Subject: Un*x Is The Pits ... While musing over the plethora of options to the 'tar' (tape archive) utility, it suddenly occurred to me that what we really needed was a *permanent*, geologic-time archiver. This would, aptly enough, be dubbed the 'La Brea' version of 'tar'. Fred Brooks' analogy becomes all too clear - mucking sloooowly and clumsily about in the swamps of Un*x, occasionally bumping into the preserved remains of ancient dinosaurs ... Now since La Brea 'tar' files would always have the sticky bit set, they might be difficult to transport. We might want yet another incompatible, hard-to-use, and patented file-compression utility to shorten our 'tar' files before clogging the network with them anyway. For compatibility with 'tar', I'd like to suggest that this new utility be named 'feather' ...   From: MP Date: Fri, 12 Apr 91 16:48:22 EDT Subject: Re: Pain, Death, And Disfigurement Date: Thu, 11 Apr 91 13:00:22 EDT From: SS > You see, newaliases ... report[s] practically no errors > or warnings. How could it? That would require it to > actually comprehend what it reads. I'm sorry, SS. I frequently get error reports from newaliases, they're usually wrong (i.e. the real error they report is that I'm running Unix). The messages say something like: newaliases: insufficient space on device. newaliases: missing ':' on line xxx Where the output device (and in fact every device on the system) has sufficient space and line xxx is NOT SUPPOSED to have a colon. The real error these messages indicate is that the writers of sendmail decided that the expansion of a mailing list should never need more than 1000 characters and that I seem to disagree with this.   From: WW Date: Fri 12 Apr 91 13:27:28-PDT Subject: Re: Un*x Is The Pits ... Stanford had a system called "labrea". It was (is?) a vax 750 with 10 fuji eagles (4.5 Gbytes, which was a lot when it was first around...) Tape handling has always been a real weak point of unix. Any real operating system has much better backup/restore capabilities, and a lot of these are 10s of years old...   From: KP Date: Fri, 12 Apr 1991 18:52-0400 Subject: Re: Pain, Death, And Disfigurement Date: Fri, 12 Apr 1991 16:48 EDT From: MP ... The real error these messages indicate is that the writers of sendmail decided that the expansion of a mailing list should never need more than 1000 characters and that I seem to disagree with this. I wonder if this is because the only truly large list they ever anticipated was one they feared -- unix-haters -- and perhaps it was a subtle attempt to keep us from communicating with one another.   From: NA Date: Fri, 12 Apr 1991 16:16:30 PDT Subject: Re: Pain, Death, And Disfigurement > I wonder if this is because the only truly large list they > ever anticipated was one they feared -- unix-haters -- and > perhaps it was a subtle attempt to keep us from > communicating with one another. Paraphrasing here: Never attribute to malice that which is adequately explained by incompetence.   From: DH Date: Mon, 15 Apr 91 16:52:00 PDT Subject: Do You Remember DEFSYSTEM? This poor user tried to use Unix's poor excuse for DEFSYSTEM. He is immediately sucked into the Unix "group of uncooperative tools" philosophy, with a dash of the usual unix braindead mailer lossage for old times' sake. Of course, used to the usual unix weenie response of "no, the tool's not broken, it was user error" the poor user sadly (and incorrectly) concluded that it was human error, not unix braindamage, which led to his travails. Date: Mon, 15 Apr 91 13:14:38 PDT From: RP To: rich Cc: engineering Subject: CVS Bizarreness (1) Do I really have to cvs co the whole goddamn gdb module just to check in a minor mod to the gdb.texinfo file? I can supply a general case of this problem if you care. (2) After "cvs co gdb" I cd'd to the right subdirectory in my new gdb development tree and did the following. I don't understand most of what I got back. Reproduced session fragment is indented (my prompt is " devito@sirint) "); interlineal comments or questions are flush left and enclosed in brackets. devito@sirint) pwd /work/pesch/devo/gdb devito@sirint) cp $A/gdb/man/gdb.texinfo $A/gdb/man/*.m4 . devito@sirint) for foo in gdb.texinfo *.m4 devito@sirint>> do devito@sirint>> cvs ci $foo devito@sirint>> done cvs ci: WARNING! The following file(s) do not contain an RCS $Id keyword: gdb.texinfo Are you sure you want to continue (y/n) [n] ? y [OK---I've been using just $Revision, I'll put in $Id next time if somebody---like CVS--- cares] emacs: Unknown terminal type I don't know what kind of terminal you are on - all I have is 'emacs'. [Using open mode] "/tmp/cvslog.028513" 5 lines, 194 characters [Yuck. OK, my fault---maybe---since I don't have EDITOR set in my environment, but I wonder whether it'll work any better with it set to "emacs"; I *always* type shell commands, like "cvs ci", from an Emacs shell buffer]. CVS: Modified Files:gdb.texinfo CVS: Modifed Files: CVS: Modifnfo ed Files::q! :q! [OK, I give up trying to use ed. Here, I expect either CVS to abort, or for it to succeed without whatever logging information it was asking for.] cvs: warning: editor session failed Checking in gdb.texinfo; /local/cvsfiles/devo/gdb/gdb.texinfo,v <-- gdb.texinfo new revision: 1.3; previous revision: 1.2 done Unknown command: "ogb@curly" [WHAT!!?? "ogb@curly" is part of the email address of one of my friends. I don't think that string is in gdb.texinfo, or for that matter in any of the m4 files I was also trying to check in. grep agrees it isn't there.] cvs: there is nothing to commit! cvs: there is nothing to commit! cvs: there is nothing to commit! cvs: there is nothing to commit! cvs: there is nothing to commit! cvs: there is nothing to commit! cvs: there is nothing to commit! cvs: there is nothing to commit! cvs: there is nothing to commit! cvs: there is nothing to commit! [Hm, cvs seems awfully excited. But I can't tell what file it's complaining about; it claimed to be "done" with gdb.texinfo before looking up my friend's email address (I wonder what junk mail it sent to my *other* friends?), so I guess chances are this is about the m4 files. I suppose I can write my shell loop with diagnostic output next time (like "echo $foo"), now that I know I'm using a program that doesn't disclose the subject of its error messages.] devito@sirint) Incidentally: the *REAL* revision number of this gdb.texinfo revision, as reflected in the RCS file I've been maintaining religiously in John's current RCS for gdb---and which I will continue to maintain, since so far this is not an encouraging experience---is 2.29, not 1.3. 1.3 happened quite some time ago. It is less than helpful that the gdb somebody checked into CVS is wildly out of date with respect to the source-management system previously in use.   From: DC Date: Mon, 15 Apr 91 17:55:44 -0700 Subject: The 1991 Fairness In Vitriol Act Hey, speaking of cretinous abortions on the lispm, I got totally shafted by the namespace system today; so badly that I actually had to build a new world load from the distribution band. Lost about two and a half hours' work. A real sense of nostalgia, being shafted by an old enemy like that...   From: DC Date: Mon, 15 Apr 91 17:52:49 -0700 Subject: Re: Do you remember DEFSYSTEM? To be evenhanded in our vitriol, it must be said that DEFSYSTEM is one of the worst of the many really bad features of the lispm.   From: JZ Date: Mon, 15 Apr 91 18:10:29 PDT Subject: Re: the 1991 fairness in vitriol act As cretinously abortive as DEFSYSTEM is, I think that 'make' is undeniably worse. At least with DEFSYSTEM the cryptic incantations you had to make were composed of words, instead of random sequences of punctuation characters...   From: AB Date: Tue, 16 Apr 91 15:18:20 EDT Subject: Re: Do you remember DEFSYSTEM? Date: Mon, 15 Apr 91 17:52:49 -0700 From: DC To be evenhanded in our vitriol, it must be said that DEFSYSTEM is one of the worst of the many really bad features of the lispm. You might be interested in knowing that this message was forwarded to the Common Lisp standards committee mailing list, where it certainly decreases the already small likelyhood that a Common Lisp system definition tool might ever become standard. C, for your crime of "evenhandedness" we have reserved a special room in Hell for you where you will spend eternity maintaining a large Lisp program using tools like make(1) and grep(1) instead of defsystem and "Meta-.".   From: OS Date: Tue, 16 Apr 91 16:42:51 EDT Subject: Re: Do You Remember DEFSYSTEM? C, for your crime of "evenhandedness" we have reserved a special room in Hell for you where you will spend eternity maintaining a large Lisp program using tools like make(1) and grep(1) instead of defsystem and "Meta-.". Bummer. That means he'll be right down the hall from all those pathetic assholes getting screwed daily by Make/include file interactions. Of course, that's probably true of where he is right now. P.S. Hell doesn't scare me. After paying dues on this list, I figure when we die and go to Hell, we'll all be offered jobs.   From: JW Date: Tue, 16 Apr 91 14:31:32 PDT Subject: Re: Do You Remember DEFSYSTEM? re: P.S. Hell doesn't scare me. After paying dues on this list, I figure when we die and go to Hell, we'll all be offered jobs. Sure. Converting some Symbolics release 5.x software to run under DOS. Recall that Unix(tm) isn't the world's mfu* Operating System. A: if C's comment *really* does have any effect on X3J13 (which is doubtful in my mind given that body's inertia to outside forces), then the real question to be asked is why he had to raise the issue in a Unix-haters flame list rather than in a Common Lisp forum. * = Most Frequently Used   Date: Tue, 16 Apr 91 14:51:57 -0700 From: DC Subject: Re: Do You Remember DEFSYSTEM? All right, all right, I repent: I once tried to use make(1) and it was MUCH worse.   From: CM Date: Wed, 17 Apr 91 14:48:10 EDT Subject: Jobs In Hell Fool. Don't you watch the Simpsons? They run Appletalk in Hell. Most likely with GatorBoxes connected to NFS servers for location transparent file service across the various circles. When we die, we'll all be cast into the lowest circle to spend eternity unf__king their sendmail configuration using ed while simultaneously dealing with irate system demons who want to know why the POP servers don't work anymore.   From: DW Date: Wed, 17 Apr 91 16:44:53 EDT Subject: Truth in Advertising Sun's latest edition of their third-party software catalog sports a colorful cover, at the center of which is a photo of a Sun workstation with a color screen, displaying some pictures. If you look closely at the screen, it is easy to see that the machine has been halted, and is running in the the bootstrap PROM, which has done several linefeeds, pushing the graphics up about a quarter of the screen, and printing several lines of the usual kind of garbage that it prints.   From: OS Date: Wed, 17 Apr 91 23:07:13 EDT Subject: Re: jobs in hell When we die, we'll all be cast into the lowest circle to spend eternity unf__king their sendmail configuration using ed while simultaneously dealing with irate system demons who want to know why the POP servers don't work anymore. You don't get it. This sort of thing is *punishment*. Punishment, in Hell, is for the "clients" (who, I suppose, we could also refer to as the "users"). To be employed in Hell is to be on the other end of the pitchfork.   From: JA Date: Thu, 18 Apr 91 01:09:53 EDT Subject: IBM And UNIX* Go So Well Together My IBM RS/6000 has an annoying habit. When it runs out of swap space, it looks around for large processes to kill. Of course, since most of the time I am running several lisps, it typically picks one of them (the one with the most state, naturally.) This is a big pain. I did not realize it could get worse. Today it chose to kill my X server in its quest for more free swap space. I had to *reboot the machine* in order to regain access to my console. Fortunately it still allowed me to login through the network or I would have needed to powercycle! I guess that's one way to get more swap space! A better solution, of course, would be to not let those nasty space hogging users log on again. Perhaps it could record the names of the programs it killed and delete those files, so they couldn't be a problem anymore. Free up some diskspace while it was at it. Let's hear it for TEAM IBM: user hostile to the end!