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 (
[email protected] 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
[email protected]... 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: <
[email protected]>
To:
[email protected]
Subject: Boston Combined Schedule
Cannot execute binary file.
Date: Mon, 17 Sep 90 22:13:19 EST
From: RS
Subject: [
[email protected]: 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: [
[email protected]: please add to mailing list]
God, I hate this!
Can someone take care of this guy? He's paid his dues (see below).
From
[email protected] Tue Sep 18 09:29:27 1990
Date: Tue, 18 Sep 90 09:27:20 -0700
From:
[email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Return-Path: <
[email protected]>
Message-Id: <
[email protected]>
To: <
[email protected]>
Status: R
----- Transcript of session follows -----
>>> RCPT To:<
[email protected]>
<<< 550 <
[email protected]>... User unknown
550 <
[email protected]>... User unknown
Date: Tue, 18 Sep 90 09:26:45 PDT
From:
[email protected] (Robert R. Henry)
To:
[email protected]
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
[email protected] < 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 <
[email protected]>
Subject: Defunct user [Re: Subgenius Digest V2 #11]
To:
[email protected]
...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 <
[email protected]>
Subject: Defunct user [Re: Subgenius Digest V2 #11]
To:
[email protected]
...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: <choke>
Return-Path: <
[email protected]>
Date: Sun, 25 Nov 90 20:45:46 EST
From:
[email protected] (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: <choke>
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.<nnn>', where <nnn> 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
[email protected] 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
[email protected] 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:
[email protected]
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 =
[email protected]
From: MC
Subject: Re: the jargon file
Date: 19 Dec 90 17:14:19 GMT
In article <1YqWpR#
[email protected]> 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 <eric@cbmvax!snark.thyrsus.com>?
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: <
[email protected]>
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 <eric@cbmvax!snark.thyrsus.com>
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 =
[email protected]
=========== 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: <
[email protected]>
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 <
[email protected]>; Thu, 20 Dec 90 17:21 EST
Message-Id: <
[email protected]>
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 <
[email protected]>
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 <
[email protected]>
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 =
[email protected]
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: [
[email protected]: 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) <
[email protected]>
Subject: Failed mail (msg.aa07457)
Your message could not be delivered to
'
[email protected]' for the following
reason: ' rthu off for holidays... User unknown'
Date: Sat, 22 Dec 1990 00:17:24 PST
From: ML
To:
[email protected]
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: [
[email protected]: 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 <
[email protected]>
Subject: SWITCH.ARCOM.CH Mail Network -- failed mail
----- Mail failure diagnostics -----
Message Recipients:
[email protected]: MTA congestion
----- Unsent message follows -----
From: SS <
[email protected]>
To:
[email protected]
Cc:
[email protected]
Message-ID: <
[email protected]>
..
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 <
[email protected]>; 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:
[email protected]
In-Reply-To: "ER"'s message of Tue, 1 Jan 91 19:44:17 EST <
[email protected]>
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: <
[email protected]>
Date: Wed, 2 Jan 91 15:18:56 PST
From:
[email protected] (RL USAC/PAL)
To: R
Subject: grammatical error in install script so 631788
Cc:
[email protected]
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 =
[email protected]
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:
[email protected]
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 <uunet!SLCS.SLB.COM!mariner>
Subject:
[email protected] has been added to the security list
To:
[email protected]
Cc:
[email protected],
[email protected]
In-Reply-To: <
[email protected]>
Message-Id: <
[email protected]>
[ . . . ]
=========== 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} ::= <CRLF>
{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<CRLF>", the RUIP on the remote host receives "user<CRLF>",
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 <Postmaster@YALECS>
To: <DRIV-L@TAMVM1>
Subject: Returned mail: Service unavailable
Message-Id: <
[email protected]>
----- Transcript of session follows -----
554
[email protected]... Cannot deliver: ARPA access denied to user "<DRIV-L@TAMV
554
[email protected]... Explanation: user "
[email protected]" does not have a
554
[email protected]... Service unavailable
> (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:
[email protected] (Eric Muller)
Newsgroups: comp.lang.modula3
Subject: Re: optimization and garbage collection
Date: 10 Jan 91 02:43:52 GMT
References: <
[email protected]>, <
[email protected]>, <
[email protected]>, <
[email protected]>
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: <
[email protected]>
Date: Wed, 30 Jan 91 11:19:21 EST
From:
[email protected] (John J. McLaughlin-SunFlash Editor)
To:
[email protected]
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
[email protected].
Subscription requests should be sent to
[email protected].
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,
[email protected]. (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
[email protected] 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 <blarg>, 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:
[email protected] (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 <the thing above>?" 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:
[email protected]
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: [
[email protected]: ]
This is a mysterious error message, to say the least.
From:
[email protected]
Date: Tue, 5 Mar 91 17:05:59 EST
To:
[email protected]
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
[email protected]
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!
