From: JZ
Date: Wed, 17 Apr 91 22:49:49 PDT
Subject: Re: IBM and UNIX* go so well together
> Let's hear it for TEAM IBM: user hostile to the end!
Speaking of the evil empire... almost a year ago my
girlfriend applied for a summer internship at IBM (actually,
she applied for two positions). Since then, she has gotten
at least six rejection letters from various divisions within
the company, most of which she hasn't applied to. So it's
like, they're passing her resume around and generating a
rejection with each stop! Wouldn't it be great if TCP/IP
worked this way?
It's not even clear that she has gotten rejections
corresponding to the positions she has applied for.
From: AB
Date: Thu, 18 Apr 91 12:31:10 EDT
Subject: Getting back on track
Date: Wed, 17 Apr 91 22:49:49 PDT
From: JZ
Speaking of the evil empire...
EXCUSE ME? Lately there has been far to much of this
chit-chat and idle potshots. Let me remind you all that
this is Unix-Haters. Not Defsystem-Loathers, DOS-Detesters,
Common-Lisp-Apologists or even IBM-Bashers. Unix-Haters.
UNIX-Haters! Our business here is the single-minded hatred
of Unix.
Let me supply you with an example. Just today I had the
following dialog with one well known computer manufacturer's
version of Unix:
> rm temp
rm: temp directory
> rmdir temp/
rmdir: temp/: Is a directory
(Of course if I type the name of the directory -without- the
trailing "/", rmdir works just fine.) Now just what the
heck braindamage do you suppose results in this idiotic
error message? "OF COURSE IT'S A DIRECTORY", I shout at my
terminal, "WHY THE HECK DO YOU THINK I'M USING RMDIR?"
Now that's the kind of teeth-grinding experience this
mailing list is all about.
From: AR
Date: Thu, 18 Apr 91 12:43:23 EDT
Subject: Why I Hate Unix (Today)
From "man mh-alias"
To use aliasing in MH, do the following: In your
.mh_profile, choose a name for your primary alias file,
say aliases, and add the following three lines:
ali: -alias aliases
send: -alias aliases
whom: -alias aliases
Create the file aliases in your MH directory. Start adding...
From my mh_profile
Path: Mail
send: -forward
ali: -alias aliases
send: -alias aliases
whom: -alias aliases
From ~/Mail/aliases
me:
[email protected]
Ok... Try sending a message "To: me"
mh responds.
me: loses; [USER] 550 me... User unknown
post: 1 addressee undeliverable
send: message not delivered to anyone
Half an hour later, while composing this message.
Eureka! Perhaps mh can't handle the fact that there are
two lines in my profile that start with "send:".
Naaaahhhhhh.
But YES! Unix has wasted another half hour of my
time. "send -forward -alias aliases" does the trick. (or
maybe it was the other behaviour that was the trick).
From: JW
Date: Thu, 18 Apr 91 13:46:19 PDT
Subject: Re: Getting Back On Track
re: Let me remind you all that this is Unix-Haters. Not
Defsystem-Loathers, DOS-Detesters,
Common-Lisp-Apologists or even IBM-Bashers.
Unix-Haters. UNIX-Haters! Our business here is the
single-minded hatred of Unix.
Oh, come on now A -- being "single-minded" like this is
too Unix-ified an approach to such a fun thing!
But . . . just to re-establish my credentials on this list,
I found myself in the predicament of having to change a
whole slew of files named foo.a into foo.b. Should be a
simple job for the Unix equivalent of LOOP, CONCATENATE,
SUBSEQ, right? Well if SED and AWK weren't scary enough,
the looping facilities for shell scripts are troubling too
-- in particular, it aint anywhere near the same for CSH as
for KSH etc. After half-an-hour of staring at what passes
for shell-script tutorials, I gave up and wrote it in Emacs
-- using keyboard macros -- and then call Unix 'source'
command.
Note that. My Operating System ISN'T Unix or SunOS -- it is
in fact EMACS.
Why, until Sun stuck me with a terminal/console whose
screen-manager is a rom-coded FORTH Program that runs at
1200 baud, I didn't even use SunView, OpenLook, or X. I
only acceeded to the Wonderful World of X/Motif in order to
get my Emacs to run at something more like 9600 baud. (No
kidding! just ask about the Sparcstations primitive console
mode.)
Incidentally, I do know about the :r "subseq" for CSH (but
not their shells?); however under the Aegis shell of Apollo,
note how easy the task above would be:
mvf {?*}.a @1.b #r.e. pattern matching -- standard in Apollo world
So you can see why "worse (Unix) is better" is our motto.
From: CM
Date: Thu, 18 Apr 91 23:24:28 EDT
Subject: One Hand Clapping.
Today the mischievous Unix kami kicked me in the teeth.
Twice.
I should have seen it coming. I walked into my office after
some lecture and stepped around some grey-bearded dude that
was talking to my office mate. "Hi, I'm Brian Kernighan,"
said the grey-bearded dude as I walked by.
I thought quickly, "Hey, this is the guy that helped invent
C, should I kill him now and take revenge for all humanity?"
"Nice to meet you," I replied and shook his hand. A little
voice in the back of my head screamed "Coward!" Now when
the revolution comes and they put Bill Joy and Dennis
Ritchie up against the wall, I'll be shot as a collaborator.
Great...
At this point, I should have known that something terrible
was going to happen. Something so horrifyingly nasty that,
if I had known beforehand, I would have taken the letter
opener out of my top drawer and gladly cut out my heart and
entrails and fed them to my dog to not have to go through
it. But that's not what I came here to talk about...
So, I've been dicking around with BSD kernels lately and
have a set of kernel sources on my workstation. Don't ask
why. I won't tell you. I don't even know. Anyway, I
decided that I didn't need to keep those nasty kernel
sources around anymore since they were four revision letters
old and someone had probably completely rehacked the IPC
code for the sheer hell of it so I cd'ed to the root of the
kernel source tree and typed "rm -rf * &". "Great," I
thought, "the machine can ditch the 20 megs of shite and I
can do something else." Ain't multitasking great?
I forgot that rm is aliased to "rm -i" so now the stupid rm
process is bleating in the background, getting turds all
over my screen, about not being sure if it should delete all
these files. I mean, it's whole purpose in life is to
delete files. You think it would have a little more panache
about it, especially when I go to the trouble to give it the
gd kill-first-and-ask-questions-later flag. But no.
So I fg the process and kill it. Then I unalias rm and
rerun it. No problem. Except that after I ran rm the first
time I cd'ed back to the top of my home directory. Oops.
And this time, rm, starting from the top of my whole
directory tree and freed from its cumbersome wimp complex,
grits its teeth and wipes out those kernel sources and then
some.
"Oh shite," I remarked when I discovered that I had nothing
left but dot-login files. So now I'm hanging out on the
Plains of Limbo waiting for a demo of the whizzy new
backup-n-restore system that they wrote around here. It's
not so bad, I guess. It has a kind of Zen "What is the
listing of an empty directory" quality about it...
From: DW
Date: Fri, 19 Apr 91 11:31:42 EDT
Subject: Flaming
It has been pointed out that there isn't nearly enough
flaming on this mailing list. The following usenet posting
isn't actually about Unix, but in times of flame-famine,
drastic measures may be necessary. What it lacks in
substance I hope it makes up in form.
From:
[email protected]
Newsgroups: comp.object
Subject: Re: Syntax Change Not Paradigm Shift
Date: 17 Apr 91 16:19:02 GMT
Nntp-Posting-Host: happy
In some other article, SG writes:
> In the commercial realm where real computing is done and
> where the vast majority of both the cycles and the dollars
> of computing are found, one doesn't find this mindless
> pursuit of endless transliteration. COBOL is sufficient
> and has been for years. There is, you see, a real job to
> get done.
Yeah, when I was a boy we used to have to toggle switches on
a com panel. Sure the machine was big, slow, cost millions
of dollars, used up enormous amounts of electricity and
generated enough heat to warm a football stadium, but we got
the job done and we LIKED it! None of this namby-pamby RISC
goobledy-floo, where you can wait a few seconds to see your
compile finish.
In my day, we used to go away for WEEKS because we knew the
average turn-around time on a batch day was 3.5 days and the
average availability of the machines was 18 hours out of 24.
Most of us have to wear glasses now because of years
squinting at hex dumps printed by a failing ribbon on a line
printer that we had to keep running with wire and chewing
gum. Most of us have the pallor of albino cave fish from
years spent in climate controlled basements tending machines
that cost 500 times as much as we made in a year.
None of this simpering about how much my portable PC weighs
or how much Sun raised its prices. In my day we used to
thank GOD that we had a tool like COBOL, a language that had
was supposed to be for humans and whose programs looked like
assembly instructions for a Y-12 bidirectional wing-wang
oscillator.
These days you hear these whining wimps going on about
"functional" languages and "logic programming" languages and
"object-oriented" languages. Pfah! We had a real job to do
and we didn't have any choice: we had to use COBOL because
we had spent $50,000 on the compiler and it was the only
language that ran on our ancient, outmoded hardware
supported and we had no money left after trying to maintain
hundreds of thousands of lines of poorly written, poorly
structured, non-portable code that cost us thousands of
hours and dozens of burnt-out programmers. There was a real
job to be done and we did it and WE LIKED IT!!
From: DH
Date: Fri, 19 Apr 91 09:21:41 PDT
Subject: Re: Why I Hate Unix (Today)
When I got your message it had the following structure:
Date: Thu, 18 Apr 91 12:43:23 EDT
From: AR
>From "man mh-alias"
[...]
>From my mh_profile
[...]
>From ~/Mail/aliases
[...]
Of course I have to read my mail on a unix system with a
mailer so lame it has to peek into my message and alter the
text (in a way that cannot be mechanically undone)!
Apparently to unix losers parsing is a black art!
From: MT
Date: Sat, 20 Apr 91 13:30:41 PDT
Subject: Dxterm Is A Total Loser
Here's one reason why performance on ok.cygnus.com sucks
rancid foreskins: dxterm.
markov@ok$ ps gauxw
USER PID %CPU %MEM SZ RSS TT STAT TIME COMMAND
markov 8029 84.6 5.0 3236 976 p0 R N 847:03 /usr/bin/dxterm -ls
markov 15924 38.4 2.4 596 468 p2 R 0:01 ps gauxw
[other process status deleted]
I'd love to kill the program, but it's my gd login shell. I
can't believe that those a**holes built and tried to sell a
machine which spends more CPU cycles trying to m*st*rb*te
than it makes available to me. I guess this is a safety
feature: Ultrix at full speed would just be too dangerous
and disgusting for words.
From: WW
Date: Sat 20 Apr 91 19:32:51-PDT
Subject: Re: Dxterm Is A Total Loser
I can't believe that those a**holes built and tried to
sell a machine which spends more CPU cycles trying to
m*st*rb*te than it makes available to me.
Huh? What are you, in the army? Anyway, everybody does it.
That's why machines theoretically 10s of times faster than
those of 10 years ago end up being able to suppport fewer
users. Unix workstations are sort of the worst offenders -
Altos and Early Macs managed to provide a windowing
environment using much less memory and disk...
From: MT
Date: Mon, 22 Apr 91 14:20:47 PDT
Subject: [
[email protected]: GCC performance]
I was trying to ftp something from another machine this
weekend. The connection always timed out. How pathetic!
Return-Path: <
[email protected]>
Date: Mon, 22 Apr 91 07:56:56 -0600
From: DG
To: RT
Subject: GCC performance
Hmm -- try again. I compiled the new interviews this
last week, and a 'dclock' that I had running was
sucking down the CPU, causing many paged out things to
timeout (like 'rlogind' even). Ultrix is such a funny
OS.
I don't think there's anything funny about Ultrix. It makes
my blood boil to think of all the unsuspecting people in the
world who thought they made a good purchase decision by
buying the machines at 10 cents on the dollar. Hell, even
free, they don't come cheap.
From: KH
Date: Tue, 23 Apr 1991 14:41:57 PDT
Subject: rehash rehashed
Just today someone announced a new program on the SUNs of
our organization, which inspired a flurry of several
messages from our staff. They didn't, of course, talk about
the utility of the program itself -- Unix would never permit
such a rational discussion.
Instead, they were all about advising people to use
"rehash", why some people needed it and others didn't, what
it did, and why it did it, and why that was a Good Thing to
do. (I would explain what this is all about for the benefit
of charmed people who have not (yet) been bitten, but I'm
too depressed right now.)
I feel like I'm trapped in a third world country watching
the natives scramble around trying to fertilize a jeep's
flat tire so it will grow back. Bad. But the really
hideous part is that the last plane out of here is already
on the runway and I'm not on it...
K.H.
(p.s. you don't think I could just blithely send this
message out without being attacked, do you? No sir, my edit
characters all stopped working in the middle of the text --
the kernel misplaced its itty-bitty TTY brains again.
Fortunately MM still recognized the command escape and I
could dump the message out to finish it off with ELLE; when
I finish I'll blow the window away and get another one.
Sigh, I wonder how much longer I can survive before I lose
my agility and become tire fertilizer...)
From: KP
Date: Tue, 23 Apr 1991 21:29-0400
Subject: It's So Bad It's Almost Good...
.. for teaching purposes only, that is. After all,
teaching is often considerably enhanced by negative examples
interspersed with the positive ones. And where else but
unix can the conscientious teacher turn for such concise
examples of now not to do just about anything. Yes, no
matter how hurried the would-be teacher is in preparing a
last-minute lesson plan, he can always rely on trusty old
unix for some fine fodder to fill an hour of instruction
time on how not to design something. Consider this most
recent piece of junk which I found in my mailbox today...
Date: Tue, 23 Apr 1991 16:26 EDT
From:
[email protected] (0000-uucp(0000))
Message-Id: <
[email protected]>
Apparently-To:
[email protected]
remote execution [uucp job uunetCm8d3 (4/23-13:26:04)]
rmail smh jlz hanoch
exited with status 67
Note the abuse of my e-mail address. And why is it only an
"apparently to"? It's sending the message. Does it not
know? It might doubt that this is who it -should- be
sending it to, but there seems no doubt about who it -is-
sending it to. Note, too, the extremely `useful' info in
the "from" field, giving me a clear sense of who I would be
talking to if I wanted to follow up on this piece of
incomprehensibility. Sure am glad it put that `human
readable' part in the parens there since I wouldn't have
been able to understand what "
[email protected]" was without
the additional explanatory version. Note, too, the way it
exposes the protocols and underlying mechanism to users who
don't care. Note the `useful' error code passed straight
through to a (fortunately) non-unix recipient (me) who has
no hope of interpreting it.
Btw, another `clearer' piece of e-mail came later which
unraveled the mystery. Apparently my original error was
trying to send mail to one of these people at the wrong
host--in effect, from this machine's point of view, there is
no such user. Of course, that didn't stop it from informing
me that I'd attempted a `Socket operation on non-socket',
but who's keeping score...
From: DL
Date: Wed, 24 Apr 1991 12:16-0400
Subject: Unix: The Festering Spreads...
Yesterday I was shafted by Unix. No big suprise there.
The sick part was, I WAS NOT EVEN USING UNIX AT THE TIME.
We're working on supporting Lisp on DOS, I guess a good
comparison would be painting the Mona Lisa onto Astroturf.
Or maybe building a bridge out of corn starch. Anyway, one
of the tools we use provides some Unix style commands, like
our buddy mv. It seemed a little bit smarter than DOS's
rename. So I use it.
Now our studio audience can obviously guess what's coming
up. God forbid you try to mv a file to a name already used
by another file. With amazing style and grace, I instantly
wipe out a file it took two hours to build. I don't know
this until later, after it's too late for any DOS Futilities
program to recover it. DOS may be a flaming abomination,
but at least it will mention that another file already has
that name.
What to do to avoid this in the future? I can do the weenie
approach of overloading the mv command to first check to see
if the file exists, and then call the idiot savant mv
command. But instead I choose to purge all the Unix style
commands on my DOS machine and live with an honest simpleton
system versus a stillborn schizophrenic psychopath system.
Amen
From: DW
Date: Wed, 24 Apr 91 13:50:41 EDT
Subject: More Unix Leakover
A friend of mine who uses PC's says:
Even better is the Microsoft rm, which is buried in
their C compiler distribution, so you don't even know
you have it. When you accidentally type "rm foo"
instead of "del foo" it just works, and you don't even
notice that you've typed the wrong thing. That is, you
don't notice until you run out of disk space, and can't
find the files that are eating up that space. After a
few hours of futility, you might discover that "rm"
creates a subdirectory called DELETED, sets the
"hidden" attribute bit so you can't see it, and then
places the "deleted" files there.
Whoever wrote the Microsoft "rm" clearly understands how to
write code that is compatible not only with the letter but
also the spirit of Unix.
From: DM
Date: Wed, 24 Apr 91 11:07:29
Subject: Re: It's So Bad It's Almost Good...
> Date: Tue, 23 Apr 1991 21:29-0400
> From: KP
> .... but who's keeping score...
Not me. I'm not a typewriter.
From: JZ
Date: Thu, 25 Apr 91 02:32:59 PDT
Subject: The Wonders Of tar...
I was trying to tar up a directory structure with the
eventual intention of FTPing it to another machine
(peripheral hatred: why can't FTP transfer directories?) so
I was doing this:
tar -cf foo.tar .
After about four minutes, I got the error message
tar: ./foo.tar: file changed size
Hmm. What's this? `df' tells me that the partition is 99%
full. Maybe this is tar's adorable little way of telling me
it's out of room. I could believe that. Ok,
rm foo.tar ; compress */* */*/* */*/*/* */*/*/*/* */*/*/*/*/*
(nice incantation, no? easier than remembering the syntax
of `find'...) Ten minutes later, I try tar again. Same
error. df says plenty of room this time. finally it occurs
to me -- tar is creating the damn foo.tar file before
listing the directory, and is considering recursively
including itself... Of course, it's OBVIOUS that I should
have done
tar -cf foo.tar *
instead. But of course
tar -cf - * > foo.tar
wouldn't have worked either...
From: PB
Date: Thu, 25 Apr 91 09:46:50 MDT
Subject: Re: The Wonders Of tar...
Date: Thu, 25 Apr 91 02:32:59 PDT
From: JZ
...
Of course, it's OBVIOUS that I should have done
tar -cf foo.tar *
This will also probably lose in a subtle way too. You lose
all those cute little .foo files the top directory. You
really have to do
tar -cf ~/random-directory/foo.tar .
All of this will of course be obvious to you since unix is
self documenting.
From: IH
Date: Thu, 25 Apr 91 12:10:51 EDT
Subject: Re: The Wonders Of tar...
Date: Thu, 25 Apr 91 09:46:50 MDT
From: PB
This will also probably lose in a subtle way too. You
lose all those cute little .foo files the top directory.
You really have to do
tar -cf ~/random-directory/foo.tar .
NO, NO, NO. You use
tar -cf foo.tar * .??*
It's COMPLETELY OBVIOUS.
Of course, here at AI, the ? key have been locally rebound
to do filename completion querying ala TOP-20 without being
documented as such so that the real incantation is:
tar -cf foo.tar * .^V?^V?*
From: SS
Date: Mon, 29 Apr 91 20:48:38 EDT
Subject: Going Potty
OK, so unix isn't toilet-trained. At least you can forget
about its diaper for weeks at a time before you get a
"surprise".
------------------------------------------------------------------------------
Date: Mon, 29 Apr 91 20:38:57 EDT
From: VB
Subject: Up Too Darn Long
I have never known a Unix implementation that was clean
enough in its resource allocation and deallocation to stay
up for more than a couple of weeks without major performance
degradation.
Media-lab has now been up for over a month (if ``uptime'' is
to be trusted), and has among other things over 400 sleeping
processes, and probably fragmentation up the wazoo. Isn't it
likely about time for a preventive reboot?
From: AD
Date: Tue, 30 Apr 91 00:41:23 EDT
Subject: Losing Fast
MIT has a nice Cray-II on which we can use as a
computron server (the people "administring" the machine
aren't so nice, but that is a different kind of hatred).
This machine, call it Ed -- MIT decided to, runs UNICOS, a
close cousin to unix. We use the Cray remotely through a
LISPM front end, so we shouldn't have to see the hideousies
of the underlying unix operating system, right?
<you guessed it> wrong!
First I was told that I would have to name my
circuits with properly terse (<14 character) names since
UNICOS can't deal with full-size filenames. A bit of an
annoyance, but having been warned about this limitation, I
renamed the circuits which I was "sharing" with Ed so he
didn't choke.
Now, after running moderately-successfully for days
(well, that parts of days in which the machine was up...but
that's another matter), the stream which was reading from
the cray blew out on my LISPM and complained about an out of
bound array index. Henry, noticing that the file had
ended, thought perhaps the reader code had failed to
properly identify EOF and patched the code accordingly. This
didn't help. For several more runs, the return stream would
blow out and the results returned would be truncated.
Finally (after wasting many hours of both mine and
Ed's), we took a longer look at one of the ~1Mbyte files of
nonsense it actually produced. Hidden somewhere in the
middle of several streams of numbers was some terse comment
about running out of inodes. We promptly deleted all the
files we had on Ed and reran the job -- this time with no
complaints.
Why does it matter how many inodes we use? In what
sense is quitely truncating a file a reasonable response to
such an occurrence? Why is the only indication of this
lossage mode burried in a file too large for any sane human
to read? -- but alas, I guess we all know the answer to
these questions -- because its unix.
sigh
From: IH
Date: Tue, 30 Apr 91 11:10:46 EDT
Subject: Losing Fast
Flame off.
Sorry to be constructive, but I have some friends at Cray
who are in charge of doing things like breaking UNICOS and
sending it back to be fixed. Who would probably love to
hear your story and see the files if you run into the
problem again.
They're not too happy about UNIX either. Sufficiently so
that they rewrote most of the kernel from scratch so that
they could get decent performance and reliability. It also
knows what mag tapes and off-line files are.
As for 14 character file names, I think that COS, a rewrite
of the CDC operating NOS, formerly called KRONOS, and which
was what existed before UNICOS, only allowed seven character
file names.
We now return you to our regularly scheduled flamage.
Flame on.
Query: if sendmail is such a dog, has been universally
recognized as being a dog, even by Sun, even by its AUTHOR,
why isn't Sun writing something usable? But then, they
admitted that YP was a dog long ago too, and they don't seem
to be doing anything about that either.
From: DW
Date: Tue, 30 Apr 91 09:18:50 PDT
Subject: Re: Unix And Parsing - Like Dan Quayle And Quantum Mechanics
Date: Tue, 30 Apr 91 02:11:58 EDT
From: SS
...
Sure enough, when I sent her a message, it
disappeared. No barf, no error, just gone. I round up
the usual suspects, but after an hour between the man
pages for sendmail and other bullshite, I just give up.
Hours later, solving another unrelated unix problem ...
^^^^^^^^^^^^^^^^^^^^^^
Surely, this is an oxymoron! One of the major problems, of
course, is that there is no such thing as unrelated Unix
problems: what do you think the terms "fragile," "unrobust,"
and "flimsy" mean?
From: JZ
Date: Tue, 30 Apr 91 12:36:15 PDT
Subject: Re: Losing Fast
In a message IH wrote:
>
> But then, they admitted that YP was a dog long ago too,
> and they don't seem to be doing anything about that
> either.
Sure they did. They changed it's name. Kinda like the
witness relocation program, I guess.
From: AB
Date: Tue, 30 Apr 91 15:07:20 EDT
Subject: Re: Unix And Parsing - Like Dan Quayle And Quantum Mechanics
Date: Tue, 30 Apr 91 02:11:58 EDT
From: SS
... I said it. A blank line. ...
Oh sure, Unix just loves blank lines. Why even Unix-Haters
itself isn't immune to blank line disease. If you ask MC's
SMTP server to show you the expansion of the Unix-Haters
mailing list you get:
220 MC.LCS.MIT.EDU Server SMTP (Complaints/bugs to:
[email protected])
EXPN Unix-Haters
250-<
[email protected]>
...
250-<
[email protected]>
250- (Unknown address)
250-<
[email protected]>
...
Took me a while to catch on that the line that says "
(Unknown Address)" is really trying to tell me that the
-empty- -string- is an unknown address, and the reason for
that was that it found a blank line in the mailing list
file.
From: HM
Date: Tue, 30 Apr 91 17:51:41 EDT
Subject: Stop Whining About The Mailer.
>From what I can tell, the unix mailer is quite
reasonable. I dont know where you are
>From but where I come
>From we are taught not to
criticize ingeniously crafted system software, especially when it is comes
>From talented and dedicated individuals and corporations.
From: LK
Date: Tue, 30 Apr 1991 15:49:21 PDT
Subject: Re: Stop Whining About The Mailer.
---sendmail fodder---
H,
The mailer ate the first line of your message. Could you
send it again?
L.
From: MR
Date: Tue, 30 Apr 91 19:42:29 EDT
Subject: Syntax Error: Not A Typewriter
There I was, happily hacking away on some T (i.e., Scheme)
code, defining a procedure to translate characters in a
certain special way. I shovel the definition into the T
process that I have running under Emacs, and I'm told that
the tiny case expression
(case c
((#\-) #\_)
(else (char-downcase c)))
is ill-formed. (The T expression #\x denotes the character
constant for the character x.) The error message says:
** Syntax error: bad syntax for special form
(CASE C (-) _)
Huh? The structure of the case expression in the message
doesn't match that of the expression in the source. I start
up another T under a shell and load the file in; it works
just fine. I switch back to the interactive T buffer in
Emacs and type (eq? #\x #\x), which yields
** Error: variable EQ?\x\x is unbound
It appears that spaces are spontaneously disappearing when
they occur before '#' characters. I start poking around at
the T readtable, wondering how it could possibly be
different for a T running under Emacs as compared to a T
running under a shell, when it dawns on me: '#' is the
default erase character, dating back to at least Version 6
Unix.
Now remember that in the dark days of v6 the error message
"Not a typewriter" always made sense, since video terminals,
pseudo-ttys, and network connections hadn't been invented
yet. So at the time it was at least somewhat logical to
have character deletion echo in a way appropriate to such
devices. And in the true Unix spirit of cast-in-stone
backwards compatibility with design decisions made in the
context of hardware that was common two decades ago, this
behavior has been maintained to the present day.
Thus the "line discipline" that has helpfully installed
itself on the pseudo-tty that Emacs is using to talk to the
T process is dutifully interpreting '#' to mean "please
delete the preceding character, if any". Never mind that
all the line editing is really going on in Emacs.
This is Unix-Haters, so I won't explain why the T running
under the shell was working correctly. (Er, at least
correctly in this regard; does anything run completely
correctly under Unix?) Or how I fixed the problem. But I
will note that '@', which is the default kill (=
line-delete) character under v6, was behaving in a similarly
losing fashion.
Argh.
From: PB
Date: Wed, 1 May 91 00:48:23 EDT
Subject: Re: Stop Whining About The Mailer.
>From what I can tell, the unix mailer is quite
reasonable.
This reminds me of a favorite one; If you redirect an alias
into a file, the "From" lines aren't "quoted" (or should I
say broken) unless some arcane incantation is whispered over
your sendmail.cf (which is of course neither the default,
nor was it present in distributed files) so "mail -f file"
screws your file over big time.
From: SS
Date: Thu, 2 May 91 03:49:42 EDT
Subject: It Could Be Worse
Just keep telling yourself, it could be worse. You could be
using Object-Oriented Cobol. *
* Document 00CTG 9004P.01 (1990), Object-Oriented COBOL Task Group,
Donald Nelson, CODASYL, Palo Alto, CA.
From: SG
Date: Thu, 2 May 91 13:26:30 EDT
Subject: [Can You Believe It? TECO for the PC!]
Begin forwarded message:
From:
[email protected] (Henry Mensch)
Date: Thu, 2 May 1991 09:13:37 PDT
Subject: can you believe it? TECO for the PC!
comp.os.msdos.misc #1947 (0 + 27 more) [1]
From: Mark H. North
[1] TECO -- Request for beta testers
Date: Wed May 1 17:43:06 1991
Organization: Naval Ocean Systems Center, San Diego
Lines: 22
A net god suggested I post this request in your group. Sorry
if it's not apropos.
I have a full blown implementation of TECO ready for beta
testing. I have been through it thoroughly but many bugs
remain. I need experienced TECO users to play with it so I
can work out the glitches. Any help appreciated. This
should be fun for oldtimers and instructive for others. (I'm
an other. How could I be an oldtimer at 44? 8^).
On the off chance there is any interest please dust off your
old TECO manuals because I haven't written the instructions
yet, though if you know TECO you should be OK. In any case,
if you have any TECO macros you can conveniently email to me
please do so -- I'm trying to build a good library.
(The package I will send has an extensive .DOC file to get
you started and includes a couple macros of my own).
Thanks
Mark
From: TM
Date: Thu, 2 May 91 13:55:47 -0400 (EDT)
Subject: Re: Can You Believe It? TECO for the PC!
TECO's available for the Amiga, too.
From: RS
Date: Fri, 3 May 91 23:11:02 EDT
Subject: How To Go From Bad To Worse With One Prom Upgrade.
For some reason, on Sparcs, Sun didn't think that the
scsi device numbers on the drives were good enough, so they
dreamed up their own. When you're hacking the hardware you
have to remember that 3 is 0 and 0 is 3 and 4 is your tape
drive. Well, at least they got 1, 2, 5, 6 and 7 ok.
Now I have this external disk cabled up to it and the
drive ID is set at 0, which means it's drive 3, and I want
to boot from tape so I can install sunos on it. So,
following the instructions in the install manual, I type "b
st()" to boot from scsi tape.
Bzzt. The new roms don't support that syntax for
booting from tape, and in a 5 or 6 line error message,
inform me that the new proper syntax for booting from tape
is "b tape". Well gee, isn't that nice and user-friendly.
So I type "b tape" and install unix on sd3 (which is
actually disk 0), carefully avoiding scribbling on sd0
(which is actually disk 3) and proceed to reboot.
Bzzt. That "b sd(0,3,0)" syntax isn't supported anymore
either. Nowadays, you're supposed to say "boot disk".
Well, gee, that's nice, but don't want to boot off of disk 3
(sd0), I want to boot off disk 0 (sd3). So I open the
manual. Nothing. I try to call Sun but they won't help me
'cause my boss's name is on the support contract and he
isn't around to tell them it's OK to talk to me.
So I played around with it for a while, and finally got
it to boot. For reasons that leave me somewhat puzzled, Sun
has decided to change their "b sd(0,3,0)" syntax to "b
/sbus/esp@0,800000/sd@0,0". Isn't that cute, a little Unix
filesystem right there in your prom monitor!
It's reassuring to know that my disks are on the sbus
too - I was worried that they had ripped me off there for a
while. You gotta give these guys credit, though - they
finally fixed the scsi-vs-disk number discrepancy. At least
in the prom monitor they did. No sooner had I booted from
sd@0,0 than the Sparcstation started happily fscking away on
its root partition on (you guessed it), sd3.
We shipped that monstrousity off to Japan the other day,
so with luck I won't have to deal with one again for a
while.
From: RA
Date: Sat, 4 May 91 3:19:47 EDT
Subject: How To Write A Valid Modern Null Program
Date: 2 Apr 91 00:56:20 GMT
From: DD
Subject: "Invalid null command"
Bourne shell users, accustomed to creating or emptying a
file with a command like:
>splot
or rewinding a tape with:
</dev/mt0
are occasionally annoyed to find that csh rejects this
syntax with the confusing message "Invalid null command".
(It is confusing because there is no such thing as a *valid*
null command; attempts to find one will only end in
frustration.)
This can be solved as follows:
touch /bin/IEFBR14
chmod 755 IEFBR14
The name is chosen for historical relevance, since most of
us who still use the Bourne shell are Luddites or
recidivists anyway. Of course,
IEFBR14 >splot
seems a bit naked without some slashes and an EXEC PGM=, but
that's the way these modern systems are...
Some folks may note a more-than-coincidental resemblance
between this version of IEFBR14 and older versions of
/bin/true. So it is, but our example lacks the
sophistication of the modern System V "true" command, which
is now 9 lines long and includes
- an entirely superfluous :
- five lines of copyright notice (so don't y'all go
trying to use empty files any more; AT&T owns the
copyright)
- a #ident--which, of course, is meaningless to the
shell, but reveals the interesting fact that we're
now up to version 2.3 of a formerly-empty file
However, the preceding was only for illustration anyway.
Nobody wants a dirty old shell script for the null command;
it should of course be a C program for efficiency. So here
we have the first cut at IEFBR14.c:
main()
{
}
This also serves only for illustration; it is historically
accurate in that it contains the same bug as IBM's original
IEFBR14. (It may be of some interest that IEFBR14 proved
the old CS aphorism "Every program contains at least one bug
and can be shortened by one instruction" at the inductive
limit: It was a single instruction which didn't work...but I
digress...) Here's the first correction:
main()
{
exit(0);
}
But to make this proper in today's brave new world, we need
<stdlib.h>. Also, for formality's sake and international
propriety, we should add the normally-obligatory setlocale()
call (actually not necessary--this may be the *only* program
for which that's true--but it's hard to pass up poking fun
at a requirement to set a default explicitly), and this in
turn requires <locale.h>. OK, so here's the penultimate
version of IEFBR14.c, our properly ANSI and
internationalized (unless I screwed up) program-to-
do-nothing:
#include <stdlib.h>
#include <locale.h>
#ifndef lint
static char *sccsid = "%W% - %E%";
#endif
/*ARGSUSED*/
main(argc,argv)
int argc;
char **argv;
{
setlocale(LC_ALL, "");
exit(0);
}
To create the final version, all you need is your local
Draconian corporate screenful of copyright notice and
disclaimer.
From: PB
Date: Wed, 15 May 91 21:27:08 EDT
Subject: Re: Virulence
I think flaming sendmail on un*x-haters should be considered
passe' it's just too easy!
Anyway I thought I heard the most successful vector for the
Morris worm was that fingerd used "gets()"
From: AR
Date: Thu, 16 May 91 14:20:05 EDT
Subject: Seen On comp.compression
/*uncompress.c by James A. Woods and Paul Eggert*/
#include<stdio.h>
#define G getchar()
#define H (w=g())
#define K [69001]
#define P putchar
#define Q 256
#define W while
#define X return 0
#define Z w=Q;W(w--)t[w]=0
long c,f,m,o,w;int O,S,e,i,k,n,q,t K;char D K,h K;long
g(){char*p;if(m<f&n<k&&(m=(1l<<++n)-1)||O>=S){O=0;S=fread(D,1,n,stdin)*8;if(S<8
)X-1;S-=n-1;}p=D+O/8;q=O&7;O+=n;X,(1<<8-q)-1&*p>>q|m&((15<n+q)*p[2]*Q|p[1]&255)
<<8-q;}main(){char*p=D+Q;G;G;k=G;e=k>>7&1;k&=31;if(k>16)X,perror("uncompress"),
1;Z,h[w]=w;n=8;f=Q+e;i=o=H;if(o<0)X,1;P(i);W(H+1){if(w==Q&e){Z;m=n=8;f=Q;if(H<0
)X;}c=w;if(w>=f)*p++=i,w=o;W(w>=Q)*p++=h[w],w=t[w];P(i=h[w]);W(p>D+Q)P(*--p);if
((w=f)<1l<<k)t[w]=o,h[f++]=i;o=c;}X;}
Not too much worse than the typical unix source....
From: RS
Date: Sat, 18 May 91 12:24:44 EDT
Subject: Pyramid Brain Death
In the berkeley universe on a pyramid, /usr/ucb is by
default *not* on your path. AT&T and BSD unixes on the same
box is like eating brussels sprouts with liver gravy on
them.
From: HM
Date: Sat, 18 May 91 17:47:56 EDT
Subject: Software That'S Easy To Use AND Reliable
This article is indicative of the UNIX methodology; if
your daemon process stays up for 24 hours straight without
coredumping or just vanishing into a puff of smoke, you're
doing great! And if not, here's an elegant solution:
No really, this is the way all system software will work
in the future; No one can REALLY debug software, even if
they did have access the sources. I mean, why did the the
Lisp Machine go to all the trouble of signalling and
catching exceptional conditions, and so on (condition-case),
when it's so much simpler to wait and see if your process
dies, oh every 60 seconds or so, and start another one? Of
course what if your process which is watching your other
process dies mysteriously? Well, start another one!
From: AB
Date: Tue, 21 May 91 02:02:05 EDT
Subject: Is Anything More Than The LF Missing?
Seems everybody has his own pet peeve about Unix:
Newsgroups: comp.lang.scheme
From:
[email protected] (Chris Hanson)
Date: 21 May 91 04:29:58 GMT
Date: 21 May 91 01:43:27 GMT
From: "Richard A. O'Keefe" <
[email protected]>
[...]
The thing that really worries me is that the last line
of the file that I picked up was incomplete. It read
" (case-3)))))"
(minus the quotes), and the file just *stopped* at
that point without even the LF that one expects to
terminate every line. Is anything more than the LF
missing?
There's nothing else missing. I never add a final
newline to a Scheme source file, because Scheme doesn't
require it. I refuse to give in to the short-sighted
unix designers who have decided that every file should
end in a newline.
[...]
From: JW
Date: Tue, 21 May 91 09:04:07 PDT
Subject: Is Anything More Than The LF Missing?
I have an automaton inside emacs that inserts the LF when
missing.
Recall that "my" operating system is emacs, not unix; but of
course there has to be some "Foreign Operating System
Interface" since most emacses sit on top of the dreaded
harlot.
From: MT
Date: Tue, 21 May 91 15:53:37 EDT
Subject: Circle of Poison
We dump pesticides and dangerous pharmaceuticals on other,
less developed countries, so why not Unix?
From: DM
Date: Tue, 21 May 91 15:00:34 EDT
Subject: Disinformatics
Article 13379 (1 more) in comp.sys.att:
From:
[email protected] (Sergey Ryzhkov)
Date: 21 May 91 12:34:32 GMT
Subject: What is ATT UNIX PC?
Dear netpeoples!
Pleas answer the question of the programmers from the
Souviet Union.
Are there anybody knows what is a computer ATT UNIX PC?
Some ammount of this computers appears in Moscow (USSR) now,
and nobody knows what is it. Off cause, there is some
ammount of documentations, but it is not for programmers...
As far as I can understand this computer prodused (or
designed) in 1985. Is it usable anywhere in the world now?
I am not regulary news reader, so if it is not hard for you
answer me to my address
[email protected] or
[email protected].
Sergey Ryzhkow, Moscow, Russia, USSR
From: MY
Date: Tue, 28 May 91 23:32:39 EDT
Subject: Don't worry about hardware reliability -- the software will crash first anyway!
From: HS
Newsgroups: comp.sys.next,comp.arch
Date: Wed, 22 May 1991 15:58:18 GMT
Subject: Re: parity is for farmers?
[...]
> Does only ECC give a strong enough guarantee - and that is
> too expensive...
ECC is more painful in all the above ways, and tends to be
used only for server-class machines where availability
sells. In practice, with current error rates, unless the
application is one where crashes are utterly unacceptable,
parity is amply sufficient. It's nice to be able to repair
the error, but relatively unimportant: most parity errors
will not bring the system down if intelligently managed, and
most systems crash more often than that for other reasons
anyway.
From: DC
Date: Wed, 29 May 91 12:56:11 -0700
Subject: Mixed Up Mail
I cannot think of a comment to add that could possibly
top what follows.
I can. Isn't it typical that unix weenies would blame
hardware for this problem? Can you imagine a hardware fault
that would explain this snafu? Not a chance. This is the
Great Satan Sendmail feeding its dark energy on the mail
files of innocents.
From: PB
Date: Thu, 30 May 91 18:15:42 EDT
Subject: Re: Mixed Up Mail
> From: DC
> Date: Wed, 29 May 91 12:56:11 -0700
>
> I cannot think of a comment to add that could possibly
> top what follows. -gz
>
> I can. Isn't it typical that unix weenies would blame
> hardware for this problem? Can you imagine a hardware
> fault that would explain this snafu? Not a chance. This
> is the Great Satan Sendmail feeding its dark energy on the
> mail files of innocents.
It need not be blamed on sendmail! Never underestimate the
ability of the Berkeley Fast (and loose) File System to
create poopage that it expects fsck to clean up!
Of course my favorate disk misbehavior is that files from
the outgoing mail queue seem to surface in the "message of
the day" file after crashes on Suns with alarming frequency!
From: DM
Date: Sat, 1 Jun 91 21:53:43 EDT
Cc:
[email protected], weeks'@iss.iss.ipp,
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected]
Subject: Incredible Lossage
Incredible lossage. Sendmail won't create inbox. On GH
movemail was owned by nobody, on AG it was owned by root.
Moving to AG thus broke my inbox. Please put
[email protected] back on the list!
From: JZ
Date: Sat, 1 Jun 91 19:13:19 PDT
DM wrote:
>
> Cc:
[email protected], weeks'@iss.iss.ipp,
>
[email protected],
[email protected],
>
[email protected],
[email protected],
>
[email protected],
[email protected],
>
[email protected],
[email protected],
>
[email protected]
Very nice, a meta-flame!
From: AB
Date: Sat, 1 Jun 91 23:17:42 EDT
Subject: 666
From: DM
Date: Sat, 1 Jun 91 21:53:43 EDT
Incredible lossage. Sendmail won't create inbox. On GH
movemail was owned by nobody, on AG it was owned by root.
Moving to AG thus broke my inbox. Please put
[email protected] back on the list!
Will do. And don't forget that your inbox should have it's
protection set to be -exactly- 666, else sendmail won't
touch it!
From: DM
Date: Wed, 05 Jun 91 10:30:05
Subject: Re: Oh, If This Were Only True
Reminds me of the headline:
GREAT WAR A TRAGIC MISTAKE
Franz Ferdinand found alive in Vienna
From: DM
Date: Sun, 9 Jun 91 13:23:21 EDT
Subject: 666, Except On Tuesdays...
Files in /usr/spool/mail/ are an exception. (Hell,
sendmail is also willing to -create- a mailbox there.)
Ah, the mysteries... But nay, sendmail will not create
a mailbox there except if the file name is a user name.
Well, unix doesn't *REALLY* have user names, y'know, so I
created a fake entry in /etc/passwd called devlin-j with the
same UID as devlin...
OH NO! Someone (or some demonic thing) SORTED the file,
and by some special unix magic "devlin-j" < "devlin"
(conversely in C "devlin-j" > "devlin" and "devlin\000j" =
"devlin" but I digress) and now my uname is wrong. I'm lucky
I could log in at all. Or am I? Ugh. Yech. Ptooey.
From: AB
Date: Mon, 10 Jun 91 13:52:13 EDT
Subject: 666, Except On Tuesdays..., When You Should Use "_" Instead Of "-"
From: DM
Date: Sun, 9 Jun 91 13:23:21 EDT
..., so I created a fake entry in /etc/passwd called
devlin-j with the same UID as devlin...
OH NO! Someone (or some demonic thing) SORTED the file,
and by some special unix magic "devlin-j" < "devlin"
(conversely in C "devlin-j" > "devlin" ...)...
Ah, but "devlin-" < "devlin:". You don't think that someone
sorted that file using a tool that actually -understood- its
format do you?
From: PC
Date: Thu, 13 Jun 1991 10:23:43 PDT
Subject: Scheduled Crash Time
The following note appeared recently in my mailbox, sent to
all Macintosh users around here. TOPS is a file server for
Macs, running on UNIX.
Subject: TOPS Server crash schedule
Paddington, the Sun TOPS server, wants to crash roughly
every 11 hours. We have not yet found a solution to this
problem, so this workaround is now in place:
Paddington will automatically crash at 4:03 am, 12:03 pm,
and 8:03 pm.
You should close all files and unmount all volumes
associated with Paddington before each crash.
From: DH
Date: Wed, 19 Jun 91 14:05:46 PDT
Subject: The Toxic Avenger
Date: 19 Jun 91 03:40:23 GMT
From: ES
UNIX is a scrawny kid from New Jersey who became something
of a local hero, but is now middle-aged with a beer gut.
Mach tries to turn modern UNIX into RoboCop; POSIX is an
attempt to make UNIX more attractive to corporate America
with silicone implants and Tammy Fay Bakker's double-parked
Maybelline truck.
From: AB
Date: Mon, 24 Jun 91 18:04:55 EDT
Subject: Perhaps if I was a typewriter?
An amusing little dialog I just had with the "leave"
program:
> leave 630
leave: You are not logged in
Huh? I'm not? Better check:
> f
Login Name TTY Idle When Where
ts TS co 41 Mon 16:43
mb MB p4 4:10 Sun 15:14 keiter:0.0
omega AB *p5 Mon 13:34 terminus
ac AC p7 25 Mon 14:51 lammert
Sure looks like I am logged in. Admittedly, I am using
the "uw" program, so perhaps "leave" isn't able to unravel
the maze of ptys, ttys and processes that "uw" creates.
(Using "uw" is kind of like using "x", except completely
different.) Isn't it great that unix process/terminal
control is so simple and easy to use?
From: PB
Date: Mon, 24 Jun 91 18:32:02 EDT
Subject: Re: Perhaps If I Was A Typewriter?
Reminds me of all those great folk songs;
"If I were a Typewriter"
And who can forget
"If I had a Typewriter"
No doubt "who am i" would generate amusing results in your
situation!
Of course the real problem is that your system
administration thought that keeping /etc/utmp offered an
iota of security. That, and the foolish idea that the
system shouldn't keep any info that could possibly be kept
by almost every utility program (once made suid).
I always get a charge when I head "Secure Unix". A
contradiction in terms if EVER I heard one...
From: NC
Date: Mon, 24 Jun 91 19:59:36 EDT
Subject: Re: Perhaps If I Was A Typewriter?
>From: PB
>Date: Mon, 24 Jun 91 18:32:02 EDT
>Subject: Re: Perhaps If I Was A Typewriter?
>
>Reminds me of all those great folk songs;
> "If I were a Typewriter"
Is this:
"If I were a Typewriter,
and you were 9600baud modem
Would you marry me any way
would download my data..."
or:
"If I were a Typewriter,
didel-didel-didel-didel-didel-didel-didel-dum..."
N "Godillbegladwhenthisreleaseisover" C
From: PB
Date: Tue, 25 Jun 91 14:57:51 EDT
Subject: Re: Perhaps If I Was A Typewriter?
I was thinking of the former.
In trying to force my Sun to generate the charming "Not a
Typewriter" message, I found this;
Orchid% stty >/dev/null
stty: No such device
but;
Orchid% tty </dev/null
not a tty
No doubt it all makes sense if you read the code. No doubt
the availability of source code is one of the reasons for
Un*x's virulence (and TOPS-10's for that matter)! I have no
explanation for why people run VMS.
P.S. It turns out that sys_errlist[ENOTTY] is now
"Inappropriate ioctl for device", nothing to do with
Typewriters at all! Yow! Should I be sad?
From: PA
Date: Fri, 26 Jul 91 15:47:24 pdt
Subject: "bogosity"
This isn't really about unix, but this seems like a likely
group of people for this question. I'm looking for a
lexicon that someone wrote up as a hack once upon a time, of
the various versions of the word "bogus" that circulated in
hacker jargon, or were at least somehow generative
possibilities of that jargon, e.g., "bogosity" as the
quality of being bogus. Has anyone got a copy? tx.
From: DH
Date: Thu, 8 Aug 91 19:11:43 PDT
Subject: [Simple Unix Weenie Question]
Date: Thu, 8 Aug 91 18:20:00 PDT
From: DH
Subject: Simple Unix Weenie Question
Date: Thu, 8 Aug 91 20:50:26 EDT
From: J
> =+= Gee, I can't seem to convince a shell script or a
> program to change my working directory. This makes some
> sense, given how Unix handles programs (as separate
> processes). But when I put "cd" in a shell script, it
> works for the duration of the shell script, and then
> reverts back to where I was before.
So, what's wrong with that? running a shell script
forks off another shell, and when it terminates, you are
returned to where your parent shell left you. If you
want to end up in another directory, use an alias.
The elegant approach is for the subshell to open /dev/mem
and change the directory of its parent process
directly. Another popular approach is for both shells to
open connections to the X server, select for property notify
events on screen 0, and negotiate an incremental selection
transfer in a manner acceptable to both the parent process,
child process, and the X Consortium Office of Management and
Budget, falling back on the system wide default directory
(which you must be running automounter to access) in case
the server returns a BadAlloc error.
From: DH
Date: Thu, 8 Aug 91 19:07:55 PDT
Subject: Simple Unix Weenie Question
Oh yeah, in case you were wondering how to open an X
connection from the shell, you have to be running
"xperlsh". But since it runs your .xperlshrc file through
the C preprocessor first, you have to make sure you have an
ANSII cpp in your path supporting ## style macro
concatination, but other than that it's pretty much like you
would expect.
(But of course you have to set your path up right first, so
you need to set the "SkipAheadOnErrorsAndTryAgainSomeOtherTime"
option to xperlsh in your .xperlshinit file, which is
sourced by your session manager (so naturally you have to
restart the window system before it takes effect.).)
From: JL
Date: Fri, 9 Aug 91 07:24:56 EDT
Subject: One Way To Improve C ...
The thing that's scary is that these represent such a HUGE
improvement - and not in humor! - over your typical Unix C
compiler.
(On the other hand, the second one bothers me a bit, since
there is nothing illegal about the situation described. I
wonder just what triggers it.)
[Forwarding removed]
From: AC
These are some of the error messages produced by
Apple's MPW C compiler. These are all real. (If you must
know I was bored one afternoon and decompiled the String
resources for the compiler.) The compiler is 324k in size
so these are just an excerpt I hope. I'm not sure where I
stand on the copyright issue.
"String literal too long (I let you have 512 characters,
that's 3 more than ANSI said I should)"
"...And the lord said, 'lo, there shall only be case or
default labels inside a switch statement'"
"a typedef name was a complete surprise to me at this point
in your program"
"'Volatile' and 'Register' are not miscible"
"You can't modify a constant, float upstream, win an
argument with the IRS, or satisfy this compiler"
"This struct already has a perfectly good definition"
"This onion already has a perfectly good definition"
"type in (cast) must be scalar; ANSI 3.3.4; page 39, lines
10-11 (I know you don't care, I'm just trying to annoy you)"
"Can't cast a void type to type void (because the ANSI
spec. says so, that's why)"
"Huh ?"
"can't go mucking with a 'void *'"
"we already did this function"
"This label is the target of a goto from outside of the block containing this label AND this block has an automatic variable with an initializer AND your window wasn't wide enough to read this whole error message"
"Call me paranoid but finding '/*' inside this comment makes
me suspicious"
"Too many errors on one line (make fewer)"
"Symbol table full - fatal heap error; please go buy a RAM
upgrade from your local Apple dealer"
From: CM
Date: Tue, 13 Aug 91 15:19:14 EDT
Subject: @begin(flame), Unix Weenie style
>mknod /dev/sarcasm
>
>[...sarcastic comment deleted...]
>
>rm -rf /dev/sarcasm
Ugh. I hope this is not a new trend. I can just see a
whole subcult of pimply sysadmin-wannabe twinks embellishing
this idea:
>su
>mknod /dev/stupidity
>[...stupid comment deleted...]
>rm -rf /dev/stupidity
>exit
And so on...
From: BM
Date: Thu, 22 Aug 91 16:27:16 EDT
Subject: tar cvf -
From: BM
Newsgroups: comp.unix.questions
Subject: Re: Tar To Remote Tape
In some article AL writes:
>> AL writes
>> >
>> > tar cvf - /etc | tar tvf -
>> > [ doesn't work]
>Many people pointed out that the "v" was included in the
>stdout; thus messing up the tape.
I've always assumed that "tar cvf -" would put the "v"
output on stderr, since it would be really stupid to send it
to the same stream as the tar data. But never let it be
said that something was too stupid to prevent its inclusion
in Unix....
From: JM
Date: Thu, 22 Aug 91 18:56:17 PDT
Subject: tar cvf -
From: BM
Date: Thu, 22 Aug 91 16:27:16 EDT
From: BM
Newsgroups: comp.unix.questions
Subject: Re: Tar to remote tape
In some article AL writes:
>> AL writes
>> >
>> > tar cvf - /etc | tar tvf -
>> > [ doesn't work]
>Many people pointed out that the "v" was included in the
>stdout; thus messing up the tape.
I've always assumed that "tar cvf -" would put the "v"
output on stderr, since it would be really stupid to
send it to the same stream as the tar data. But never
let it be said that something was too stupid to prevent
its inclusion in Unix....
But why bother when there are simple alternative solutions?
Just do:
tar cvf - /etc | sed 's/#$*&$/$#%&$*%/g/\\{P/\$!3/t:w/dev/null\\}' | \
awk '{print $56 $23}' | tar tvf -
Well, maybe I've got some the $'s and #'s reversed, and I think you
need to put some linebreaks in there somehow, but you get the idea...
P.S. Oh yeah, don't run that if you're reading to an NFS
partition mounted with the 'intr gelid' option--it
seems to hang the network.
From: AR
Date: Mon, 26 Aug 91 13:38:27 EDT
Subject: Is A Piece Of Shite
% ls -l dollyII
-rw-rw-rw- 1 ar 362141 Aug 26 13:24 dollyII
% uudecode dollyII
Is a directory
%
From: BH
Cc: loonies <
[email protected]>
Date: Tue, 27 Aug 91 2:01:00 EDT
Subject: Please Add
I was going to shorten this and edit out the earlier
portions of our exchange but who am I to revise that which
has happened? History shall remain immutable and rightly
should so as the lessons of the past week in the (former?)
USSR have demonstrated...
--- snip snip snip ---
Date: Sun, 25 Aug 91 19:03:08 -0400
From: PB
Subject: Please Add
We apologize for the delay in dealing with your obviously
worthy request. You are now added. We also find your
explanation for your request, enclosed below, a brilliant
example of an anti-unix rant, and we urge you in the
strongest terms to send it along to the unix-haters list,
that it may be savored by other connoisseurs.
- Unix-Haters-Request@fsf
From: BH
Date: Wed, 5 Jun 91 14:13:38 EDT
Subject: Re: Please Add
> From: BH
> To: unix-haters-request@fsf
> Date: Thu, 14 Mar 91 17:42 EST
> Subject: Please Add
> Please Add:
>
[email protected]
> to unix-haters@fsf thanks!
> bh
> Our state-of-the-art Un*x mailer prevents us from simply
> sending unix-haters to anyone who asks; the load would
> make it impossible to use the machine for anything else.
> (Actually, Un*x makes it difficult to use the machine for
> anything as it is now ...) Accordingly, we can only
> include people who have unambiguously demonstrated a real
> need for the psychological outlet unix-haters provides.
> -- Unix-Haters-Request@fsf
Date: Mon, 02 Sep 91 16:24:29 EST
From: SS
To:
[email protected]
Subject: Major Pot Decries Excess Carbon Deposits On Fellow Utensils
Computergram via First! -- Peter Norton, founder of Peter
Norton Computing, now subsumed into Symantec Corp, sounded
off about current industry developments when he delivered
the keynote address at the Fed Micro '91 conference in
Washington DC last week. Norton is sceptical that the IBM-
Apple Computer alliance will work, and he doesn't care for
Unix at all.
..
As for Unix, he was uncompromising. "I don't like it," he
said. "But's it's here, especially in government, and being
used. It's here to stay, for better or worse - I think
worse. It has an important role to play. It's heavily
mandated in Europe. [In this country] it's more used in
engineering departments and government offices. We don't
need a proliferation of operating systems. The good part is
that it offers compatibility across hardware. That's an
illusion but better than nothing. It's a necessary evil,
like OS/2."
[08-29-91 at 13:33 EDT, Copyright 1991, Apt Data Services.,
File: g0829184.920]
From: JZ
Date: Mon, 2 Sep 91 21:35:21 PDT
To:
[email protected]
Subject: Once You've Mastered Xt, Think How Much Fun
Your Next Visit To The Proctologist Will Be!
So I was playing XTetris, and I got to thinking,
wouldn't a two-player version of this be cool to have, like
the one on the Explorers. So I glance at the code; it's
pretty modular, shouldn't be too hard.
And I've got the thing in my head, it's all nice and
organized and clean and beautiful: there's this top level
constraint frame, with some children which are buttons and
status and so on, and a pair of other children which are
tetris playfield widgets. Ok, the code's using global
variables for everything, but it'll be simple to just make
those slots in the playfield structure. Fine.
So like I said, I've got this pretty little hierarchy in
my head, I could draw it on paper in ten pen strokes, I
could write an Explorer program to toss the windows on the
screen in the appropriate relationships in like a minute.
So I go and look at XBiff, another program I've screwed
around with a lot, to remind myself of the customary way to
do this shite under X. Well, that comes down to two .h files
and one .c file for each widget-type; a lot of fooling
around with global arrays which the resource manager uses in
some seriously arcane way; and a whole lot of smelly glue to
hold the whole thing together, in the form of
FunctionsWithReallyLongNamesWithMixedCaseSoThatWordBased-
CommandsAreUselessToYou.
I start getting intimidated by this, and then I remember
that we've got this interface builder thing called XDesigner
(that I think we actually paid money for). Well, I've seen
people use it, and it lets you specify all kinds of
constraints and shite, and then generates C code. The code
it generates looks like hell, uses lots of global variables
and gensymed names, but at least it generates the calls you
need to make. I think.
Well simple and intuitive are two words which spring
immediately away from mind when using this program. After
ten minutes of using the monster, my fingernails were
starting to bleed, and there were these strange mouse-grey
plastic growths peeling their way through the back of my
hand, just like the flesh-gun in Videodrome, so I gave up,
deciding that doing it by hand would be easier. Thirty more
seconds of that and I was considering starting up XDesigner
again.
At this point I reached enlightenment: first a flame,
and then I go to read some comic books, putting thoughts of
"recreational" X hacking as far behind me as possible.
From: NZ
Date: Wed, 4 Sep 91 12:45 EDT
Subject: How Many Errors This Week?
A recent posting to nntp-managers from MM had the
following header line, which I think is a wonderful comment
on the state of Un*x Mailerdom ...
Errors-To:
[email protected]
From: JA
Date: Thu, 5 Sep 91 18:36:20 EDT
Subject: Love That Portable Code!
Here's something you can try at home. Better yet, try
it on vacation. Take a gnuemacs distribution. Build it.
Write it on a tape. (We won't go into how wonderful unix
tape handling tools are in this flame. Remember: One topic
per letter!) Travel to some far distant land in another
timezone. Read that tape. Run that emacs. Type meta-x
display-time. Voila! You get to know what time it is in
your originating timezone. Very important when you're
traveling and need to call home, you don't want to wake up
your housemates.
Here's the bug: ctime() doesn't call tzset because it
thinks tzset has already been called in the current process
(it was: during the build cycle before emacs was dumped).
Ugly! This is not a problem with traditional C
programs, because of couse *they* don't try to do something
hairy when creating their a.out files; they just let 'ld' do
all the work, and therefore they haven't been apparently
invoked already...
From: RM
Date: Sun, 8 Sep 91 19:56:48 EDT
Subject: Flabby Geology
From: JK
Newsgroups: comp.arch
Date: 5 Sep 91 20:31:22 GMT
Subject: Re: User Settable Address Size.
CP writes:
> BTW even the earth has more than 10**38 atoms
What bloat! What incredible waste! Anybody who knows
how to do planet design could build a perfectly usable
planet with a fraction of that. Why, when I started out in
planet science, the whole system fit into 10**16 atoms and
supported hundreds of life forms. I agree that such
restrictions are not necessary today, but using large land
masses as an excuse for proper geological formation is just
bad design!
From: CM
Date: Tue, 10 Sep 91 15:44:48 EDT
Subject: What Does The "a" Stand For
I just found out how to modify executable files with
adb. What a truly advanced program! [Quiz: does the "a" in
adb stand for "advanced" or "autistic"?]
I'm sorry to report that I don't have any stories of how
I spent 12 hours tearing my hair out because of some
undocumented bug in the program. I'm scared to try anything
more complex than writing a variable. Ahh, Unix has taught
me caution *and* time management skills.
?
^D
From: JD
Date: Wed, 11 Sep 91 07:39:00 EDT
Subject: The Wisdom of the Library of Congress
On a trip to the musty basement of the library here, in
section Z, I noticed that the books on Unix word processing
are shelved immediately adjacent to the books on Cryptology.
The taxonomy speaks for itself.
From: DM
Date: Wed, 18 Sep 91 18:21:14 EDT
Subject: Serendipity
This morning I needed a, well, actually, a doorstop in my office.
Or maybe I mean a boat anchor. Something heavy and square to hold
something in place.
Not having anything suitable on hand, I looked around in
the library until I found an unlabelled cardboard box that
seemed the right size and heavy enough to do the job. Fine,
it worked great. Just now, when I was done with it and
putting it back where I found it, just for the heck of it I
opened the box to see what was in it. It turned out to be a
copy of A/UX (manuals and CD-ROM). I've discovered the
application for which Unix is best suited!
From: SS
Date: Tue, 24 Sep 91 12:05:14 EST
Subject: How many TLA people will race to send THIS one in first?
From: PS
Date: Tue, 24 Sep 91 11:46:49 EDT
Subject: Mail Problems
The mail spool directory got screwed up sometime during
the night so that mail files were renamed to the names of
other users (i.e., the name table was somehow permuted).
Then the mailer continued delivering mail, placing mail to
the user whose name was (improperly) on the file in that
file, so that there were some messages to one user, and some
messages to another user in some files. This doesn't apply
in all cases; many people did not receive mail after the
screw-up and before the fix, for example.
What we have done is rename the files to the name of the
original owner. In most cases this solves the entire
problem; but for people who received mail this morning, it
doesn't -- your mail of this morning is in somebody else's
mail file.
We cannot fix this. But we can tell you who this other
person is, and whose mail is at the end of your mail file.
Then you can forward it to the person in question, or prompt
the other person to send you the mail.
Here is the list of people who have some of other people's mail:
clay might have some of beymer's mail
bvhs might have some of cath's mail
ccooper might have some of catherine's mail
dampier might have some of cdr's mail
jlj might have some of chaney's mail
cdr might have some of clay's mail
beymer might have some of djberker's mail
jtw might have some of doughty's mail
ira might have some of ehrlich's mail
spr might have some of es's mail
jvb might have some of gideon's mail
ehrlich might have some of gld's mail
nsing might have some of glr's mail
lethin might have some of harris's mail
lina might have some of gunter's mail
maja might have some of ira's mail
glr might have some of ivan's mail
malone might have some of jfc's mail
jongon might have some of jhc's mail
jin might have some of jimb's mail
jhc might have some of jlj's mail
chaney might have some of jls's mail
wps might have some of jongon's mail
doughty might have some of jti's mail
thier might have some of jtw's mail
tut might have some of jvb's mail
ivan might have some of lethin's mail
jti might have some of lina's mail
cath might have some of malone's mail
gld might have some of may's mail
robertso might have some of milesc's mail
noakes might have some of milos's mail
tlong might have some of noakes's mail
miked might have some of nsing's mail
may might have some of quisp's mail
brooks might have some of rab's mail
zoubin might have some of robertso's mail
andyc might have some of ruth's mail
nita might have some of skeckler's mail
nhca might have some of stf's mail
thier might have some of sw's mail
jimb might have some of thier's mail
foley might have some of tlong's mail
jfc might have some of toddh's mail
gillett might have some of tony's mail
suomi might have some of tut's mail
alan might have some of vetter's mail
leigh might have some of wleigh's mail
jls might have some of wojo's mail
ruth might have some of wps's mail
wojo might have some of zoubin's mail
From: PS
Date: Tue, 24 Sep 91 12:50:28 EDT
Subject: Re: How many TLA people will race to send THIS one in first?
Gee, I was going to send that in.
You know, I can't easily imagine how Unix manages to
permute the names of a subset of the files in a directory.
I mean, if it walked over a table of pointers to filenames,
why aren't the filenames just random trash? Of course, I
have successfully protected myself from learning about the
data structures used in the Unix file system, so I can only
conjecture here.
I asked Ian, who knows something about the data
structures used in the Berkeley Unix file system, and he
couldn't see just how it could do this, either. It seems to
me that you would really have to try to lose exactly like
this.
From: IH
Date: Tue, 24 Sep 91 16:36:11 EDT
Subject: Re: How many TLA people will race to send THIS one in first?
For me, the most frustrating thing about unix is
watching people complain about bugs which were fixed when I
was an undergraduate but which have been intentionally
reintroduced.
For example, and this may be totally inaccurate since I
have avoided leaning what's going on with unix these days,
but from the descriptions I've heard, it seems that the
interlocking on the aliases database has been intentionally
removed because it takes a long time to recompile the
database, too too long to have all mail delivery stop while
the database is recompiled.
So we just turn off the interlocking and let the
mailinglists disappear for a few minutes. Mailing lists
certainly do disappear regularly at tla-arg, but only for a
few minutes at a time.
From: DC
Date: Tue, 24 Sep 91 14:15:45 -0700
Subject: Decay
What I find totally incredible is that the general level
of systems seems to be lower in almost every respect than it
was ten years ago -- the exception being that the machines
run ten times faster. (Well, mine doesn't; it's a straight
3600 and thoroughly canine. But everyone else's does.)
I maintain a couple of large mailing lists, one of which
has a nine-year history. Nine years ago it ran perfectly on
ITS, and then for another five years on OZ. Then we moved
it to Reagan (a bolix) which really didn't work well, but
was tolerable, but got more and more broken. We've left it
there, despite lost mail and infinite maintenance
aggravation because *we can't find any machine that we have
access to that has more reliable mailing list service*.
``We'' here is a group of five mildly famous AI PhDs at
five different labs, each among the most famous in the
world.
I have some friends who work at Anon MPCSL. MPCSL is
probably the most prestigious computer science laboratory in
the world. It is the place where LANs and printers and
email and such were made practical (if not invented). They
run Sun unix now, and it is totally broken, and no one can
fix it. Their expensive PhD researchers regularly waste
*days* trying to get files to come out of a printer or
sitting around waiting for NFS to get fixed so their machine
will unwedge. It's officially acknowledged both that this
is a disaster and that it won't get fixed.
Along with the degraded level of systems support has
come an extraordinary decrease in access that might let one
fix things for one's self. When I was 17, in 1978, I was a
``tourist'' at the MIT AI lab -- in other words, I used
their PDP-10 although I had no affiliation whatsoever with
the lab. When the system crashed, I would wander into the
machine room, figure out what had gone wrong, and toggle the
relevant boot sequence into the front panel of this $1e6
mainframe.
Here in the future, at most CS labs, you can't get
access to the machine room no matter who you are. If the
file server goes down at 5:01 Friday afternoon, it stays
down until 9:00 Monday when the authorized person comes in.
So a lot of famous expensive computer science PhDs, many of
them capable of designing the file server in their sleep,
grunt in disgust and go home and get nothing done for the
weekend.
I can't understand how this has been allowed to happen.
Besides being fantastically annoying for users, it's
fantastically wasteful for companies. I can't understand
why the CEO of Anon doesn't say ``God DAMN it! We are
going to have reliable mail service around here, or HEADS
ARE GOING TO ROLL!'' I can't understand why people don't
just fix things that are broken, the way they used to ten
years ago. I just can't figure out how it can have gotten
this bad.
From: MM
Date: Tue, 24 Sep 91 17:39:01 PDT
Subject: Designing The File Server In Their Sleep
In a restrained and polite note to Unix-Haters, DC
claimed that when his site's file server (locked in a room
somewhere) crashes at 5:01 PM,
> ... a lot of famous expensive computer science PhDs, many
> of them capable of designing the file server in their
> sleep, grunt in disgust and go home and get nothing done
> for the weekend.
I sometimes wonder whether the problem with Unix might
stem from the fact that it much of the post-Thompson/Ritchie
software was indeed designed by famous expensive computer
science PhD's (while they were under-paid and
over-caffienated graduate students). Certainly, much of it
appears to have designed by people who, if they weren't
already asleep, ought to have been.
We have progressed far from the days when Unix came on
two RK05's (10 Mb total for you children who weren't born
then), and the magic number in the boot sequence was passed
down in unbroken oral tradition from Ken to you.
However, I'm not sure if all the progress has been in
the right direction.
From: DM
Date: Wed, 25 Sep 91 10:56:41 EDT
Subject: Re: decay
> Date: Tue, 24 Sep 91 14:15:45 -0700
> From: DC
> ....
> I can't understand how this has been allowed to happen.
> Besides being fantastically annoying for users, it's
> fantastically wasteful for companies. I can't understand
> why the CEO of Anon doesn't say ``God DAMN it! We are
> going to have reliable mail service around here, or HEADS
> ARE GOING TO ROLL!'' I can't understand why people don't
> just fix things that are broken, the way they used to ten
> years ago. I just can't figure out how it can have gotten
> this bad.
It's not the only part of the national infrastructure
that has been allowed to turn to rust, rot, and dust. In my
more paranoid moments I think that it's all one big
conspiracy to soften us up by a sinister force. It's a
little more subtle than bombing us back into the stone age,
but perhaps in the end has the same effect.
Unix in its current form can be tied to the CIA and Army
Intelligence through the Berkeley connection and the
intelligence community's covert experimentation with
administration of drugs to civilians. These are the same
moments when I feel that every president from Nixon to Bush
has actually been an alien in a rubber full-head mask. No
genuine, human, American president would do the stuff they
do.
From: MY
Date: Wed, 25 Sep 91 11:53:47 EDT
Subject: Designing The File Server In Their Sleep
Date: Tue, 24 Sep 91 17:39:01 PDT
From: MM
[...]
I sometimes wonder whether the problem with Unix might
stem from the fact that it much of the
post-Thompson/Ritchie software was indeed designed by
famous expensive computer science PhD's (while they were
under-paid and over-caffienated graduate students).
Certainly, much of it appears to have designed by people
who, if they weren't already asleep, ought to have been.
We have progressed far from the days when Unix came on
two RK05's (10 Mb total for you children who weren't
born then), and the magic number in the boot sequence
was passed down in unbroken oral tradition from Ken to
you.
However, I'm not sure if all the progress has been in the
right direction.
I don't know if Minow is committing the hagiolatry one
associates with the typical weenix unie, but I really feel
that any further mention of the reputed tear-inspiring
beauty, simplicity, symmetry, economy, etc of "V7" (or
whatever) Unix should be cause for immediate and permanent
expulsion from present company.
I've seen quite a number of allusions to some downward
fall of unix even in this forum. Let's get this straight
once an for all: Unix was flawed from conception. Its
entire New-Jerseyist philosophy is flawed. In fact, its
entire "philosophy" is a Source of Evil in the Modern World.
THERE WAS AND IS NO FALLING-OFF FROM A WORLD OF
UNDIVIDED LIGHT. THERE WAS NO GREAT PURE, PRIMORDIAL,
PRELAPSARIAN UNIX. The Unix you see, with which you
struggle, which you curse, is not a diseased and reduced
remnant, but is itself the agent of disease and reduction.
How can one lose sight of that?
From: IH
Date: Wed, 25 Sep 91 14:02:28 EDT
Subject: Re: decay
From: DC
Date: Tue, 24 Sep 91 14:15:45 -0700
What I find totally incredible is that the general level
of systems seems to be lower in almost every respect
than it was ten years ago -- the exception being that
the machines run ten times faster. (Well, mine doesn't;
it's a straight 3600 and thoroughly canine. But
everyone else's does.)
I think that there are a bunch of reasons for this. In
"the good old days", things were smaller, administered by a
small number of very highly qualified people, and largely
confined to research.
Nowadays, all this stuff is "standardized" by committees
with divergent goals and widely varying talent and
knowledge, forced to be upward, downward, and sideways
compatible, is much larger, much more widely distributed,
implemented by people fresh out of college who've never
written a large program in their life and never will because
now they're doing their own little part of a "software
engineering" effort the totality of which they do not
understand and have never seen a good large system, in fact
have never seen or tried to understand all of any large
system whatsoever.
Here in the future, at most CS labs, you can't get
access to the machine room no matter who you are. If
the file server goes down at 5:01 Friday afternoon, it
stays down until 9:00 Monday when the authorized person
comes in. So a lot of famous expensive computer science
PhDs, many of them capable of designing the file server
in their sleep, grunt in disgust and go home and get
nothing done for the weekend.
Right. Well there's this weird professionalization of
computing facilities going on, perhaps because unix is a
sort of scared text which you have to study continuously to
understand. That professionalization has the inevitable
result that you won't be able to fix things yourself when
they break.
That's why I use a macintosh now. I use it partly
because it has a good lisp, etc., but largely for the
specific reason that other people don't use it. My lab has
200 people in it. Either (a) lots of people hack the system
or (b) they don't.
In case (a), most of them won't know what they're doing
because for the most part we don't hire people because
they're hackers anymore and we actively discourage them from
becoming hackers when they get here. Having 200 people
wantonly hacking unix would be really bad. So with
alternative b, a lot of things don't get done because things
are just so much more complex than they used to be (e.g. we
now have so many disk drives that statistically one should
fail every two weeks, thus causing major pains).
So I use a mac. There are lots of things I can't do
with it and so I log into unix for that. But on the other
hand, things are simpler, more stable, there is a smaller
user community, and I'm the only one changing things so I
know what's going on and whose fault it is when something
breaks.
From: RS
Date: Sat, 28 Sep 91 22:21:33 EDT
Subject: [Re: rm pst *]
Oh, THIS is spiffy. How to avoid totally f__king
yourself with RM by creating a file. Kind of like copying
files with tape manipulation facilities, you know?
From: DW
Date: Sat, 28 Sep 91 17:35:22 EDT
Another thing some people do is to put a file called
something like ' AREYOUSURE' or something like that in every
directory. This file is given permission 444. If you type
rm * in the directory, that file is the first file that will
get selected (unlses you have really weird file names)
because of the leading space. If you type rm * then, the
first thing you will see will be:
rm: override protection 444 for AREYOUSURE?
This should be enough of a clue....
-D
PS This doesn't work if you use the -f flag.
From: RC
Date: Tue, 1 Oct 91 16:53:16 EDT
Subject: Fun With "make"
Recently I was working on a fairly small program in C.
It took about two or three hours to write and test. I had
been trying to push for higher standards in the group I was
working with (some users tended to avoid using any of the
development tools), so even though there was only one source
file involved I wrote a makefile. Also in the interest of
promoting standards I wrote a manual page for it.
Local man page files end in ".l"
This is more than just a convention. Man not only
insists that these files be located in the right directory
but they must have the correct extension or they will not be
displayed. After I finished the man page I figured it was
time to install the program. Just to make sure everything
was ok I ran "make clean" followed by "make".
The man page file was newer than the C source code file
so make dutifully fired off a lex job to update the .c file,
blowing away the morning's work. It is always nice to have
default rules for creating source files in case you forget
how to do it yourself.
$ make
rm -f tickfix.c
lex -t tickfix.l > tickfix.c
"tickfix.l", line 1: syntax error
...
P.S. It is probably worth noting that the first time I
started to write this note I was interrupted by the message:
Panic: Assertion failed
and got to wait 10 minutes for my Sun to reboot before I
could continue.
From: CG
Date: Tue, 1 Oct 91 15:31:49 PDT
Subject: Re: Whois And SunOS 4.1.1
In some article TR writes:
>hilbert% uname -a
>SunOS hilbert 4.1.1 3 sun4
>
>hilbert% whois \!tar13
>
>When we understand knowledge-based systems, it will be as before --
>except our fingertips will have been singed.
> -- Epigrams in Programming, ACM SIGPLAN Sept. 1982
>----------------------------------------------------------------------
>Hi! You have attempted to contact a whois server at SRI-NIC.ARPA.
>Your WHOIS client program is either extremely old or your software
>vendor is really out of it. Please complain to them.
>To contact the current DDN NIC WHOIS server, it will be
>necessary to either:
>
> a) Use a command-line option to tell your WHOIS client
> to connect to a different host (NIC.DDN.MIL),
>
> b) Or, recompile WHOIS with the CORRECT name for the DDN NIC,
> NIC.DDN.MIL, in place of the ancient SRI-NIC.ARPA.
>
>For further information about the DDN NIC, please contact the new
>contractor, SGI. Thank You.
>--------------------------------------------------------[caw 91/09/24]
>
>I guess it's official. Sun is really out of it. :-)
>
>(time to recompile whois)
>
>--
From: JZ
Date: Wed, 2 Oct 91 03:16:39 PDT
Subject: [Fwd: An amusing piece of email that I got]
---------- Begin forwarded message
From: BY
Date: Tue, 01 Oct 91 13:55:13 -0400
Subject: An amusing piece of email that I got
Well, I can see that it's gonna be a good day. This is
the second piece of email in my maildrop today. Since it is
amusing and was generated by automated software (no privacy
issues, I presume), I'll post it here for your amusement:
- ------- Forwarded Message
Return-Path: <
[email protected]>
Received: from paranoid.fsf.cs.tla.edu by PLAY.FSF.CS.TLA.EDU idB aa16655;
1 Oct 91 3:46:04 EDT
Date: Tue, 1 Oct 91 3:45:33 EDT
From: "PARANOID.FSF.TLA Mail System" (MMDF) <
[email protected]>
Sender:
[email protected]
Subject: Failed mail (msg.aa06545)
To:
[email protected]
After 225 days (5385 hours), your message could not be
fully delivered.
It failed to be received by the following address(es):
(none)
Problems usually are due to service interruptions at the
receiving machine. Less often, they are caused by the
communication system.
Your message follows:
- ------- End of Forwarded Message
---------- End forwarded message
From: CS
Date: Wed, 2 Oct 1991 11:03-0400
Subject: Panic
Panic: Assertion failed
This must be the UNIX kernel's way of desperately trying
to warn people about the hype associated with buying into a
certain kind of technology.
From: KP
Date: Wed, 2 Oct 1991 10:56:17 PDT
Subject: UNIX hatred - initial foray
On Tue, 24 Sep 1991 14:15:45 PDT, DC wrote:
Subject: Decay
What I find totally incredible is that the general
level of systems seems to be lower in almost every
respect than it was ten years ago -- the exception
being that the machines run ten times faster. (Well,
mine doesn't; it's a straight 3600 and thoroughly
canine. But everyone else's does.)
I maintain a couple of large mailing lists, one of
which has a nine-year history. Nine years ago it ran
perfectly on ITS, and then for another five years on
OZ. Then we moved it to Reagan (a bolix) which really
didn't work well, but was tolerable, but got more and
more broken. We've left it there, despite lost mail
and infinite maintenance aggravation because *we can't
find any machine that we have access to that has more
reliable mailing list service*. ``We'' here is a group
of five mildly famous AI PhDs at five different labs,
each among the most famous in the world.
I have some friends who work at Anon MPCSL. MPCSL is
probably the most prestigious computer science
laboratory in the world. It is the place where LANs
and printers and email and such were made practical (if
not invented). They run Sun unix now, and it is
totally broken, and no one can fix it. Their expensive
PhD researchers regularly waste *days* trying to get
files to come out of a printer or sitting around
waiting for NFS to get fixed so their machine will
unwedge. It's officially acknowledged both that this
is a disaster and that it won't get fixed.
Along with the degraded level of systems support has
come an extraordinary decrease in access that might let
one fix things for one's self. When I was 17, in 1978,
I was a ``tourist'' at the MIT AI lab -- in other
words, I used their PDP-10 although I had no
affiliation whatsoever with the lab. When the system
crashed, I would wander into the machine room, figure
out what had gone wrong, and toggle the relevant boot
sequence into the front panel of this $1e6 mainframe.
Here in the future, at most CS labs, you can't get
access to the machine room no matter who you are. If
the file server goes down at 5:01 Friday afternoon, it
stays down until 9:00 Monday when the authorized person
comes in. So a lot of famous expensive computer
science PhDs, many of them capable of designing the
file server in their sleep, grunt in disgust and go
home and get nothing done for the weekend.
I can't understand how this has been allowed to happen.
Besides being fantastically annoying for users, it's
fantastically wasteful for companies. I can't
understand why the CEO of Anon doesn't say ``God DAMN
it! We are going to have reliable mail service around
here, or HEADS ARE GOING TO ROLL!'' I can't understand
why people don't just fix things that are broken, the
way they used to ten years ago. I just can't figure
out how it can have gotten this bad.
------- End of message -------
Dear DC-
Your message to unix-haters of Tue, 24 Sep 1991
14:15:45 PDT was forwarded to all members of the
computer research staff at MPCSL. I thought I would
send you some comments. I have been a UNIX-hater for
15 years, which is how long I have been at MPCSL. I
avoided the UNIX revolution until it was recently
foisted on me. At MPCSL, we formerly had three
completely incompatible programming environments:
InterLISP, Smalltalk, and Cedar. This was viewed by
the new powers as very bad and in need of fixing. So
we moved to commercial UNIX-based platforms. So now we
have about 30 incompatible systems (text editors and
formatters, mail systems, versions of the OS, file
formats, programming languages, window systems, window
managers, toolkits, ... ). instead of three, with more
being added every day. Top this with the incredible
morass that is SunOS and it is no wonder that you are
wondering.
Up until recently, we owned everything from the
hardware to the microcode to the applications. We
could fix anything that broke at any level; we could
evolve wonderful new systems. How do we "fix" the X11
releases or the SMTP protocol or SunRPC??
In my opinion, things got the way they are because
market forces completely overwhelmed technological
forces. Because UNIX was free (or nominally licensed)
it came into wide use, first in CS and EE departments
and later in the world. To some, moving from MS-DOS or
worse, it seemed like a win. To those of us who have
been around for a while and are aware of the
alternatives, it seemed like a nightmare. We thought
it would go away when users came to their senses. We
were naive. Sigh. Meanwhile, thanks to BSD, UNIX grew
like Topsy, or more like barnacles encrusting a sunken
ship. Ultimately, UNIX began to be viewed by decision
makers who were not technically competent as a panacea
for competing technologies.
To take your example literally, the reason that Head
Guy, CEO of Anon, doesn't say ``God DAMN it! We are
going to have reliable mail service around here, or
HEADS ARE GOING TO ROLL!'' is that HE HAS RELIABLE
MAIL SERVICE. Anon mail is based on the RELA protocol
suite and it runs on the Anon corporate internet; SMTP
mail is handled at the periphery of the corporate
internet by gateways, tortuously written and maintained
by wizards. Head doesn't know or care that UNIX is
lurking underneath all this. At MPCSL we have had
reliable mail for years, based first on the Grapevine
mail transport and storage system and then, more
recently, on RELAMail.
I have requested to join unix-haters. I look forward
to more exchanges on this mailing list.
KP
Anon MPCSL (still proud)
(This exchange has been retransmitted at the suggestion
of the unix-haters-request central committee.)
From: JL
Date: Wed, 2 Oct 91 22:51:30 EDT
Subject: The elegance and simplicity of leaving things out
I spent the better part of this afternoon trying to link
a program together. Linking with the cc command (the only
"correct" way to link a C program) produced some complaint
about not being able to find a function I'd never heard of,
some __sbuf kind of thing (the exact name escapes me). Now,
the program I was trying to link isn't mine; it's quite old,
and while not very large, was written in a modular fashion,
so there are quite a number of files involved.
You'd think that tracking this down would be quick and
easy. On any 1960's system, you'd simply get a linker map,
and immediately learn where the references to __name were
occuring. (Actually, many linkers would tell you as part of
the error message.) Given that, a quick look at the
offending code would usually be enough to resolve the issue.
Unix, however, believes in the "one tool, one job"
philosophy. A linker should link. (So why do I call the C
compiler to link my program? Oh, well.) Producing a link
map is a job best left to someone else. For that matter,
even producing an intelligible error message is best left to
someone else.
Unfortunately, that someone's never made an appearance.
Maybe next year, after X support is done.
The problem? Turned out the system, which is generally
carefully written, still had to run on Unix, so did have to
descend to some of standard Unix techniques - like assuming
that, if it referred to _sbuf, it would get access to a
particular object within the guts of the implementation of
the standard I/O package. At the time the code was written
(Unix V7 and even earlier), not only was this the right
name, but this was the only way to accomplish the prosaic
task of making sure that output to stdout was fully
buffered. These days, _sbuf no long exists, or its name has
changed, or something.
Now, if I'd used one of those horrible old '60's systems
- or even many modern operating systems - I would have found
all this out from my link maps or error messages within a
couple of minutes. Then I would have had to spend the
afternoon debugging the Segmentation Fault that followed
once I got past this roadblock. It should be obvious to
everyone that the Unix philosophy of staying small and
simple has shown its true value again: Clearly, the _sbuf
bug was much smaller, simpler, and more elegant than a nasty
Segmentation Fault. Much better that I spend the afternoon
on the former than the latter.
Oh, yes: If the same program is linked directly with ld,
instead of with cc, no error message at all results. Right
tool for the job? Well, no; when you try to run the
resulting program, it bombs immediately with a bus error.
(Gee, are those buses really so unrealiable?)
From: RA
Date: Thu, 3 Oct 91 02:39:20 -0400 (EDT)
Subject: He Told Us So
As I was sitting here reading my unix-haters mail on a
unix box smaller than a KS-10's power supply, the following
two facts began to seem like less of a coincidence:
UNIVAC was introduced in 1950. Note suspicious name.
Arthur C. Clarke's story "Superiority" was published in 1951.
Hmmm.
Date: Thu, 3 Oct 91 22:50:28 -0400
From: JW
Subject: Re: The Advantage Of Standards.
Bad: I just spent the better part of two days debugging a
Mach kernel which turned out to be broken because
"cc" on DEC's Mips-CPU based machines thinks
characters are signed, while "cc" on Mips' own
Mips-CPU based machines thinks characters are
unsigned.
Worse: For one brief shining moment this seemed reasonable.
From: AW
Date: Fri, 4 Oct 1991 10:34-0400
Subject: The advantage of standards.
Date: Thu, 3 Oct 1991 22:50 EDT
From: JW
Bad: I just spent the better part of two days
debugging a Mach kernel which turned out to be
broken because "cc" on DEC's Mips-CPU based
machines thinks characters are signed, while
"cc" on Mips' own Mips-CPU based machines
thinks characters are unsigned.
Worse: For one brief shining moment this seemed
reasonable.
This sounds very Dostoyevskian. If I were you, I'd suspect
an epileptic seizure.
From: KP
Date: Fri, 4 Oct 1991 11:29:36 PDT
Subject: Re: The Advantage Of Standards.
I always assume characters are spoken rather than signed.
Now, that's a standard.
Date: Fri, 4 Oct 91 13:35:34 PDT
From: KH
Subject: Re: The Advantage Of Standards.
I always assume characters are spoken rather than
signed. Now, that's a standard.
Oh, I don't know about that. I prefer them signed, myself.
Now, that's more understandable...
From: RS
Date: Sat, 5 Oct 91 21:40:55 EDT
Subject: No Comment Necessary
rs@lacrosse [1] % telnet nic.ddn.mil
Trying 192.112.36.5 ...
Connected to nic.ddn.mil.
Escape character is '^]'.
SunOS UNIX (nic)
* -- DDN Network Information Center --
*
* For TAC news, type: TACNEWS <return>
* For user and host information, type: WHOIS <return>
* For NIC information, type: NIC <return>
*
* For user assistance call (800) 365-3642 or (800) 365-DNIC or (703) 802-4535
* Please report system problems to
[email protected]
NIC, SunOS Release 4.1.1 (NIC) #1:
Sat Oct 5 21:29:47 1991 EST
@ systat
9:29pm up 1 day, 5:34, 5 users, load average: 2.82, 2.07, 1.50
User tty login@ idle JCPU PCPU what
nicguest ttyp0 9:22pm whois
nicguest ttyp1 8:58pm 22 whois
nicguest ttyp2 9:25pm whois
nicguest ttyp3 9:26pm 1 whois
nicguest ttyp4 9:29pm systat
@ logout
Sat Oct 5 21:30:56 1991 EST
Connection closed by foreign host.
rs@lacrosse [2] %
From: JA
Date: Mon, 7 Oct 91 13:15:40 EDT
Subject: AT&T Breakup Caused Phone Service To Become Worse...
Emulating it, its bastard child, the Yellow Pages, is a
major source of lossage.
It seems that when a site cannot talk to its nameserver
(e.g. because the network is down, some intervening computer
is down is down, or the nameserver computer is wedged
somehow or not running the server) that the yellow pages
gets completely wedged. Then lookup of hostnames,
usernames, mail aliases, and so on hangs *forever*. The
underlying problem is that the cretinous yellow-pages server
doesn't have a timeout when trying to use the domain system
for host name lookup, so it gets wedged forever.
I discovered this quite dramatically when my slip line
died the other day and I happened to try rebooting during
the outage. You can't start many of the daemons either so
you never come up!
Ah, the wonders of having a sun at home. You can lose
24 hours a day!
From: EW
Date: Mon, 7 Oct 91 11:04:10 PDT
Subject: AT&T Breakup Caused Phone Service To Become Worse...
"The Network Is The Computer" is a bit inaccurate.
It's more like: The Server Is Every Other Computer.
When the server's "down," every other computer is down.
Organic subsistance farming looks better all the time.
From: TM
Date: Mon, 07 Oct 91 09:48:21 -0700
Subject: Much Ado About Nothing
The following message shows how null and void the C language
(and its derivatives) can be.
------- Forwarded Message
From: rd
Date: Sun, 6 Oct 91 21:30:42 EST
Subject: (void*)0
To: X3J16 committee
Message x3j16-all-111
Regarding (void*)0
To Bjarne, a thank-you for that gentle reprimand. I
apologize for making unwarranted assumptions. I shall try
to state clearly what I do know, and to ask intelligent
questions for the rest.
Bjarne's note provided some interesting technical
clarifications. I happen to agree with the request at the
end of Bjarne's note:
| I think that we also need to look into
|
| X* p = ~-1;
|
| and its cousins to see if they could be disallowed, thus
| bringing C++ into the 80es. Naturally, disallowing
|
| X* p = ~-1;
|
| would be a C/C++ incompatibility and the issue would be to
| determine if it was gratuitous.
I think there is some uncertainty in C as to whether the
definition of "null pointer constant" can require that
constant-folding take place prior to syntactic type
identification, but no formal interpretation has been
requested to J11. I will say this: I am quite willing to
defend to the C committees a change in C++ from "constant
expression that evaluates to zero" to "integral constant
whose value is zero". This incompatibility can at least be
defended upon the grounds of infrequent usage, if none
other.
Having said this, I still think that it is worth discussing
the status of
X* p = (void*)0;
or, as it more frequently appears in C, of
X *p = NULL;
Bjarne's note gives a consistency argument for disallowing p
= (void*)0:
| It would add yet another wart to the language that the
| compiler would have to test for. It is a fundamental rule of
| all typed languages that the legality of an expression is
| checked based on it type and not its value. C violates this
| by allowing constructs such as
|
| X* p = ~-1;
|
| while disallowing
|
| X* p = 1;
One might add that allowing p = 0 is also allowed based upon
the value and not the type, but it is, admittedly, much less
"warty" than p = ~-1 . Given then that we cannot reduce the
"wart count" completely to zero, might we not at least
consider eliminating the p = ~-1 wart (which, to my
knowledge, no one uses) while allowing p = (void*)0 (which,
I believe, is often used in C).
While the syntactic details can be fairly simply stated, the
overall configuration issues are not simple. Nor are the
issues raised by the interactions between (a) existing
bodies of application code, (b) existing libraries for C,
and (c) C++ implementations. Here is a brief survey of the
problem:
Many existing bodies of C applications use the macro NULL,
defined in <stdio.h> and other headers. A strictly
conforming C program assumes that NULL may be defined in the
C-vendor's headers as 0, 0L, or (void*)0. It is the
responsibility of the library vendor to provide the
definition for NULL which will properly reflect the demands
of the underlying hardware, software, and library. As Tom
MacDonald has pointed out, there are some architectures in
which (void*)0 has a representation different from either 0
or 0L. More commonly, on segmented architectures such the
80x86, there is the (lamentable) dependence of the size of
pointers upon the memory model which is selected at compile
time. To be sure, in many architectures this dependence can
be circumvented in the C-vendor's header by old-fashioned C
conditional-compilation techniques such as
#if _VENDOR_FLAG_FOR_SMALL_POINTERS
#define NULL 0
#else
#define NULL 0L
#endif
This technique, however, makes the program dependent upon
conditional compilation; the source after translation by the
preprocessor is no longer portable source. And not all
architectures will support this technique.
Attempting to eliminate the conditional-compilation with a
constant expression such as
(_VENDOR_FLAG_FOR_SMALL_POINTERS ? 0 : 0L) // misleading!
will, of course, fail because the int 0 is promoted to long
0 inside the conditional.
Thus, for these and other reasons, many C vendors have
chosen to use (void*)0 as the definition for the macro NULL.
This creates the strange situation in which the user's
strictly-conforming C program is invalid in C++ because of a
decision made by the C-library vendor. For a specific
example:
#include <stdio.h>
int main(int argc, char *argv[])
{
if (argv[1] == NULL)
return 0;
else
return 1;
}
This program is valid in C++ if NULL is 0 or 0L, and invalid
if NULL is (void*)0 .
Such simple examples, however, do not get to the heart of
the problem, namely "ellipsis" functions.
In order to be valid as C++, a C program must provide
prototypes for all function calls. This is essential for
type-safety and will not be further justified here. This
means that (actual) argument values being passed to (formal)
parameter types specified by prototypes will be properly
converted to the expected parameter type. C programs used
to need the name NULL for passing the null-pointer value to
pointer arguments of un-prototyped functions. This need is
eliminated in C++. Now the only use for a null-pointer
symbol is for calling an ellipsis function. Example:
#include <stdio.h>
#include <stdarg.h>
void prp(void* p1, ...)
{
va_list ap;
void* p;
int i = 0;
va_start(ap, p1);
p = p1;
while (p != 0)
{
printf("pointer #%d = %p\n", i, p);
++i;
p = va_arg(ap, void*);
}
va_end(ap);
}
int main(int argc, char* argv[])
{
prp(argv[0], NULL);
return 0;
}
If the manager responsible for maintaining existing C simply
replaces all uses of NULL with integer 0's, he or she will
introduce a portability bug into the strictly-conforming
example shown above.
However, this just scratches the surface of the problem. It
is not my intention to be an apologist for all the
historical warts of "old C". There are a number of good
reasons why the old typical uses of NULL should be
discouraged.
First of all, ellipsis functions are themselves a hole in
type-safety. For this reason alone, it is commonly
suggested that the programmer should consider eliminating
the definition or use of an ellipsis function.
Secondly, and more serious in this context, many of the uses
of NULL in conjunction with ellipsis functions actually
created undefined behaviors even in ANSI C. Here is the
problem: If the type specified on the va_arg invocation is
not "compatible" with the type of the actual next argument
(after promotions), the behavior is undefined. In ANSI C
the types char* and void* are required to have the "same
representation", but they are not "compatible" types. And
the integer value 0 (or 0L) certainly is not of compatible
type to any pointer. Therefore, many of the common uses of
NULL to terminate variable-length lists of pointers will be
passing values that create undefined behaviors. With the
example function prp shown above, an undefined behavior
would result from invoking
prp(argv[0], argv[1], NULL)
because argv[1] is a char* and va_arg is expecting a void* .
If the va_arg call is changed to look for a char* , then the
argument NULL itself produces an undefined behavior.
If a programmer really does need an ellipsis function that
accepts a varying number of pointers, one could suggest that
the proper way to terminate the argument list (either in C
or in C++) is to cast 0 to the same pointer type as the
other arguments; e.g.
prp(argv[0], argv[1], (char*)0);
The va_arg invocations in the calling function should
specify the proper type for the pointer arguments, namely
char* in this case. And only when all the arguments are of
type void* should the terminator be (void*)0 .
Having thus argued that NULL should not be used to terminate
pointer-argument lists for ellipsis functions (in either C
or C++), I would still suggest that this does not provide
justification for flagging p = (void*)0 or p == (void*)0 in
C++.
I am reminded by the email discussion that we must all keep
an open mind to alternative views. Certainly there is much
interest in the arguments that might indicate that p =
(void*)0 presents a problem that is not present in p = 0 .
If, however, investigation determines that the real danger
is in passing (void*)0 to ellipsis functions, then we would
have the curious asymmetry that the current rules prohibit
p = (void*)0;
and sometimes (depending upon definitions in headers)
prohibit
p = NULL;
as compile-time syntax errors, but invocations where real
problems might lurk, such as
prp(argv[0], argv[1], (void*)0);
or
prp(argv[0], argv[1], NULL);
are not diagnosed.
I have taken the time to outline the question in this
fashion to indicate that there is a sincere and
well-intentioned question being addressed here. Both the
original query and the subsequent discussion are really C
compatibility questions, so I would suggest that the
x3j16-compat reflector is the appropriate place for
subsequent discussion, but of course that is a judgement for
each contributor to make.
TP
------- End of Forwarded Message
From: TB
Date: Mon, 07 Oct 91 14:23:55 PDT
Subject: Re: AT&T Breakup Caused Phone Service To Become Worse...
>> From: EW
>> Date: Mon, 7 Oct 91 11:04:10 PDT
>> Subject: AT&T breakup caused phone service to become worse...
>>
>> "The Network Is The Computer" is a bit inaccurate.
>>
>> It's more like: The Server Is Every Other Computer.
>>
>> When the server's "down," every other computer is down.
>> Organic subsistance farming looks better all the time.
I think this one comes from DEC in response to SUN:
The Network Is The Network
The Computer Is The Computer
.. sorry for the confusion
From: SS
Date: Tue, 08 Oct 91 15:34:05 EST
Subject: How Do You Cry For Help In Unix?
It's almost too easy to retransmit anything sent to Risks to
unix-haters.
This item, however, gives me a small ray of hope: perhaps if
police departments everywhere agreed to ignore desperate 911
calls from weenix lusers, the world would be a better
place. Maybe we could give lists of all their home addresses
to local crime lords, and declare open season.
-------------------------------------------
Date: Sat, 5 Oct 91 02:38:29 PDT
From: GK
In: RISKS DIGEST 12.44
Subject: Risks of owning a modem
As you may notice from the header of this message, it is
about 2:30 A.M. on Saturday morning (or Friday night, if you
prefer). I just got a knock on my door, which was
astounding in itself. It turned out to be a couple of cops.
They asked me if I owned a certain phone number, which is
the one I use for my modem (and nothing else). Apparently
it had dialed 911.
In itself, this is nothing unusual. I have seen similar
reports on RISKS before. But my L.sys file has no number
containing the sequence 911! A check of my uucp logs showed
successful calls at 2:01 and 2:08, followed by a failure at
2:23. Presumably this last was the cause of the 911 call
(we have good police response times here). There are two
numbers for the 2:23 call, both of which contain the
sequence "166". Now how did that get turned into 911?
Maybe my dyslexic modem turned the digits upside down, then
got confused about what was repeated :-)? Seems moderately
unlikely.
For what it's worth, it's a Telebit T-2500. The cops said
it happens fairly often. Personally, I'm upset. Those guys
have better things to do than chase spurious calls from
modems. But I have no idea what I can do to prevent a
recurrence. I've only had the thing a couple of months. I
sure hope this isn't a "feature". If so, perhaps the police
department has a way for me to tell them to ignore 911 calls
on that line.
[We have had several items on this topic before, but the
problem does not seem to go away. PGN]
From: AB
Date: Tue, 8 Oct 91 21:47:17 EDT
Subject: How Do You Cry For Help In Unix?
Date: Tue, 08 Oct 91 15:34:05 EST
From: SS
It's almost too easy to retransmit anything sent to Risks to
unix-haters....
-------------------------------------------
Date: Sat, 5 Oct 91 02:38:29 PDT
From: GK
In: RISKS DIGEST 12.44
Subject: Risks of owning a modem
... For what it's worth, it's a Telebit T-2500. The cops said it
happens fairly often....
Having recently wasted an evening learning about a different
model of modem made by the same manufacturer, I can easily
imagine how it can misbehave in almost arbitrary fashion.
The model I am familiar with comes with a manual that is
approximately the size of my Tops-20 Monitor Calls handbook.
It doesn't run Unix, but it wouldn't suprise me if in a few
years you will be able to buy a modem that does.
From: RM
Date: Thu, 10 Oct 91 13:56:46 EDT
Subject:
[email protected]
It is great to see that the DDN NIC has moved out of the
dark ages of twenex (and from west coast mall-land to east
coast mall-land) and that we now have a
[email protected] which is happy to shite all over
the TCP-IP mailing list.
Plus ca change, plus c'est merde.
From: DH
Date: Mon, 14 Oct 91 17:19:37 PDT
Subject: SunLS
-------------------------------------------------------------------------
The following announcement was made Tuesday, October 8, 1991.
SunLS, a new Sun Microsystems, Inc. business, was formally
introduced today in a press release issued by SunLS, which
is attached for your reference.
-----------------------------------------------------------------
SMCC currently resells and offers complete support for all
of the SunLS products. Users should expect to be able to
take full advantage of SunLS products through the SMCC price
list and world-wide customer service, although each product
decision will be made on a case-by-case basis.
If you have questions about this announcement or other
questions about SMCC's networking product portfolio,
contact:
Don Directory
SMCC Software Marketing
[email protected]
US (666) 666-6666
-------------------------------------------------------------
SUN LAUNCHES SUNLS TO CONSOLIDATE UNIX SYSTEM DIRECTORY LISTINGS
New Business Will Leverage and Build Upon Sun's Expertise in
Filesystems In Heterogeneous Environments
MOUNTAIN VIEW, Calif. -- October 8, 1991 -- Sun
Microsystems, Inc., today formally introduced SunLS(TM), a
business unit dedicated to providing software for showing
contents of both local and remote directories in homogeneous
or heterogeneous environments.
SunLS leverages the expertise of Sun Microsystems, Inc. in
the UNIX(R) data storage marketplace. Since its founding in
1983, Sun has consistently led the industry in integrating
computer equipment from multiple vendors into powerful data
storage engines. Sun pioneered the concept of distributed
computing and networked filesystems, in which all of an
organization's diverse computer resources can be accessed
through the user's desktop workstation. SunLS now builds
upon that expertise as it focuses on delivering the highest
quality listings of files and directories throughout
enterprise-wide networks.
SunLS offers a product for enterprise-wide, PC, and LAN/WAN
filesystem listings, as well as a product for local
filesystems. Both flat and recursive listing options are
available. The SunLS product is based on industry
standards, allowing customers to introduce the technology
into their existing systems, providing an upward migration
path to future technologies while protecting previous
computer investments.
To complement its product line, SunLS has initiated a
partnership program in which third-party vendors work with
SunLS to custom-tailor solutions to each customer's
particular requirements. The aim of the SunLS Partners
Program is to provide customers with the widest possible
range of choices.
"As a new business venture, SunLS has the agility,
entrepreneurial drive and market focus of a start-up," said
Scott McNealy, president and chief executive officer of Sun
Microsystems, Inc. "Yet with financial backing from
$3-billion Sun Microsystems, Inc., the company has the
resources -- including engineering, manufacturing, technical
support, sales and marketing -- to establish itself as the
undisputed leader in listing UNIX files." Cheryl Vedoe,
vice president and general manager of SunLS, will have
responsibility for day-to-day operations of the
business. SunLS will maintain its headquarters in Mountain
View, Calif.
SunLS Product Overview
Product Applicability
ls All filesystems
Net-ls NFS Filesystems
ls-R Filesystems with directories
Net-ls-R NFS Filesystems with directories
ls-a Filesystems with dot files
Net-ls-a NFS Filesystems with dot files
ls-aR Filesystems with dot files and directories
Net-ls-aR NFS Filesystems with dot files and directories
Other products to be announced soon.
SunLS products are distributed through local Sun
Microsystems Computer Corp. sales offices, SunExpress, and
selected SunLS resellers. The products are also available
through the Sun Microsystems Computer Corp. professional
services business, which provides network installation and
management services.
Sun Microsystems, Inc., headquartered in Mountain View,
Calif., is a leading worldwide supplier of network-based
distributed computing solutions, including professional
workstations, servers and UNIX operating system and
productivity software.
(c)1991 Sun Microsystems, Inc. Sun Microsystems, Sun, the
Sun logo, SunLS, the SunLS logo, SunLS Partners Program, and
SunExpress are trademarks or registered trademarks of Sun
Microsystems, Inc. UNIX is a registered trademark of UNIX
System Laboratory, Inc. All other products or services
mentioned herein are trademarks of their respective owners.
Press Information:
SunLS
Fred Filesystem (415) 666-6666
From: DH
Date: Mon, 14 Oct 91 18:01:14 PDT
Subject: I Love Working At Sun ...
-- Customers are really stupid: if you dump on them they
quit buying your product ;-/
- Author's name withheld (not me).
From: DH
Date: Mon, 21 Oct 91 14:18:19 PDT
Subject: dr on Deskset
Date: Wed, 31 Oct 90 09:39:51 PST
From: OD
To: tt
Subject: fyi
Hmmm...
----- Begin Included Message -----
>From kh
From: kh
To: ws
Subject: dr on Deskset
From: DR
Date: 18 Oct 90 17:02:39 GMT
Newsgroups: sun.open-windows
Subject: Re: Deskset environment
[NS replied to me directly. Her reply illustrates the
reasons why I sent out yesterday's mail so perfectly that
I'm taking the liberty of copying my reply to
openwindows-interest]
> When we give standard Deskset presentations, a couple of
> things tend to "dazzle" the audience ...
>
> 1. Use the MT Calendar template to generate an
> appointment. Mail it to yourself, then
> drop it onto CM which will schedule it. The
> template is totally hokey (we're working on
> it) but it works and is wizzy.
>
> 2. Build a small application with GUIDE and make it
> on the spot. Show it up and running on XView
> in minutes. You can talk to BW about that
>
Thank you, but you have completely missed the point. I
don't want to show people how whizzy the standard default
desktop environment is. That's your job.
I want to give a talk about a quite different subject. I
merely want to *use* the desktop environment to achieve my
own ends. And as soon as I try to actually *use* it for
something instead of merely showing off the glitz, it falls
to pieces in my hands. Unfortunately, this is becoming all
too common in Sun products these days, because we no longer
*use* the things we build for anything but whizzy demos.
Have you ever actually tried to *use* the desktop for
anything? Like, say, printing a PostScript file? The
answer has to be no - because dropping a PostScript file on
the print tool doesn't work. Or binding a shell command to
a pattern? Again no, because doing so depends on
undocumented features of /etc/filetype. Even trying to
create a new icon from the standard set causes the icon
editor to dump core. I'm not joking when I say that I've
been filing a bug report every couple of hours of trying to
use the desktop. Its this kind of fragility that shows me
that I'm treading on fresh snow. No-one else has walked
this way.
And that is a truly sad commentary on the state of Sun -
no-one has been this way because no-one believes that
there's anything worth doing over this way. The reason Unix
was such an advance over previous operating systems was that
you could customize your environment in arbitrary ways.
With just a few shell scripts, for example. Its just like
the cold war - in our anxiety to compete with the enemy
we've ended up losing the things that made our way of life
worth defending in the first place. Like the freedom to
disagree with the authorities.
> I believe you're correct in saying that most people live
> with the default environment, but I think it's only partly
> because they don't know how to customize it. We've done
> some user testing and, surprisingly, people either prefer
> the default environment or just don't want to take the
> time to make it special. This is particularly true of
> people like admins, marketing, etc.
Testing whether people actually do customize their
environment is beside the point. Of course they don't. In
order to do it, I have to write C code using bizarre
features of Xview, exercise all my shell wizardry, and
dredge up undocumented features of the system from the
source. And you're suprised when admins can't do this? I
don't expect admins to do it. But I do expect ISVs and
Sun's SEs to be able to do it, and right now they can't.
PS - I notice that someone filed a bug today pointing out
that even your example of dropping a mail message on CM
doesn't work if CM is closed. That's a symptom of the kind
of arrogance that all the deskset tools seem to show -
they're so whizzy and important that they deserve acres of
screen real estate. Why can't they just shut up and do
their job efficiently and inconspicuously? Why do they have
to shove their bells and whistles in my face all the time?
They're like 50's American cars - huge and covered with
fins. What I want is more like a BMW, small, efficient,
elegant and understated. Your focus on the whizzy demos may
look great at trade shows, but who wants to have their tools
screaming at them for attention all the time? It's like
having a Roy Lichtenstein painting on your bedroom wall.
----- End Included Message -----
----- End Included Message -----
From: PS
Date: Mon, 21 Oct 91 17:36:16 EDT
Subject: dr on Deskset
What do you think the chances are that, in forwarding this
message outside of Sun, you just got this poor guy fired?
From: DC
Date: Mon, 21 Oct 91 15:37:47 -0700
Subject: Getting People Fired
Speaking of which, forwarding the message I sent unix-haters
which mentioned Anon MPCSL to everyone at that institution
seems to have made me some enemies there, which is
unfortunate in as much as I might someday want a job there.
Obviously it was careless of me to mention MPCSL by name,
but perhaps we'd all well to be more careful about this sort
of thing.
From: RA
Date: Tue, 22 Oct 91 01:23:36 -0400 (EDT)
Subject: He Told Us So
Per request by someone who didn't get the Arthur C. Clarke
reference: SUPERIORITY is an account of how superior
technology lost an interstellar war, by the
commander-in-chief of the losing side.
From: DM
Date: Tue, 22 Oct 91 12:15:27 EDT
Subject: Re: How Do You Cry For Help In Unix?
> Date: Tue, 8 Oct 91 21:47:17 EDT
> From: AB
> Subject: Risks Of Owning A Modem
> ... For what it's worth, it's a Telebit T-2500. The cops said it
> happens fairly often....
>
> Having recently wasted an evening learning about a
> different model of modem made by the same manufacturer, I
> can easily imagine how it can misbehave in almost
> arbitrary fashion. The model I am familiar with comes
> with a manual that is approximately the size of my Tops-20
> Monitor Calls handbook. It doesn't run Unix, but it
> wouldn't suprise me if in a few years you will be able to
> buy a modem that does.
Computer Envy is a terrible thing.
Not quite as terrible as Unix, though.
From: DH
Date: Tue, 22 Oct 91 10:10:42 PDT
Subject: dr on Deskset
Low.
Date: Tue, 22 Oct 1991 10:05:33 -0700
From: MW
Subject: Re: Getting People Fired
Subject: Getting People Fired
Date: Mon, 21 Oct 1991 15:37:47 -0700
Speaking of which, forwarding the message I sent
unix-haters which mentioned Anon MPCSL to everyone at
that institution seems to have made me some enemies
there, which is unfortunate in as much as I might
someday want a job there. Obviously it was careless of
me to mention MPCSL by name, but perhaps we'd all well
to be more careful about this sort of thing.
Well, it also made you some friends here.
From: PS
Date: Tue, 22 Oct 91 14:15:13 EDT
Subject: Re: Getting People Fired
My point is that the development groups of many companies
are not run like research labs, and the people who run them
do not typically have the same priorities with respect to
peer criticism and free speech and inquiry that people at
research labs do. For example, I consider it very likely
that the Deskset product manager (if he or she knew what you
had done) would want very much to take action to ensure that
you or Mr. dshr couldn't embarrass the Deskset group and Sun
again. It may be that this is impossible, due to the nature
of power relationships in the company. It may be that,
because I raised the issue, people will be careful about
whom they forward the message to. But for a marketing
weenie, the image of the product is what has to be
preserved, and bad press from someone who is supposed to be
playing for the same team is not going to be suffered
gladly.
I don't like the business-weenie culture; I think it's based
in the very lowest instincts and is part of what brings us
inferior products like the Chevy Vega and SunOS. Maybe you
don't like it either, and so you might choose to ignore it.
Good for you. But if my fortunes were ever to sink to such
a nadir that I found myself developing Unix(TM) software, it
would probably be because I needed the money really badly,
and I would be mightily pissed at you if I got hauled into
some vice president's office because you, in your blithe
ignorance of business-weenie culture, forwarded a sensitive
message of mine outside of the company.
From: AW
Date: Tue, 22 Oct 1991 14:32-0400
Subject: Re: How Do You Cry For Help In Unix?
Date: Tue, 22 Oct 1991 12:15 EDT
From: DM
> Date: Tue, 8 Oct 91 21:47:17 EDT
> From: AB
> Subject: Risks of owning a modem
> ... For what it's worth, it's a Telebit T-2500. The
> cops said it happens fairly often....
>
> Having recently wasted an evening learning about a
> different model of modem made by the same
> manufacturer, I can easily imagine how it can
> misbehave in almost arbitrary fashion. The model I am
> familiar with comes with a manual that is
> approximately the size of my Tops-20 Monitor Calls
> handbook. It doesn't run Unix, but it wouldn't
> suprise me if in a few years you will be able to buy a
> modem that does.
Computer Envy is a terrible thing.
Not quite as terrible as Unix, though.
I don't know why I have to say this, but I do. Bear with
me.
My stapler doesn't wish it were a computer, because it's not
smart enough to wish it were a computer. If it _were_ smart
enough to wish it were a computer, it would already _be_ a
computer.
I don't know if this generalizes to modems.
From: DH
Date: Tue, 22 Oct 91 12:43:59 PDT
Subject: Forwarding Messages
Please don't forward that message about the deskset around.
It is only for the enjoyment of people who truly hate Unix.
Since the incredible bogosity of Unix is one of the best
kept "open secrets" of the industry, I assumed that this was
a relativly private mailing list.
From: DC
Date: Tue, 22 Oct 91 12:53:32 -0700
Subject: Getting People Fired
Well, it also made you some friends here.
Yes; apparently quite a number of them. Perhaps in fact it
was a net gain!
From: DC
Date: Wed, 23 Oct 91 15:31:46 -0700
Subject: Words Fail Me Department
This isn't about unix. Shoot me.
I've just waded through the programming manual for a
pipetting machine: that is, a machine that sits on a bio lab
bench and sucks and spits liquids. The programming language
for this machine is, with the probable exception of ITS
TECO, the most bizarre I have ever seen. A program is
called a method. A method is divided into subroutines. A
subroutine is divided into functions. A method may not call
functions; a subroutine may not call a subroutine; a
function may not call anything. So every program must have
exactly three levels of call depth!
Where it really gets interesting is in its looping feature.
There are two looping functions, LOOP and NEXT, which
correspond to the beginning and end of a loop. Now loops
can (and, for other reasons, almost always must) cross
subroutine boundaries. So a method calls subroutine A,
which calls LOOP, does some stuff, and exits; then the
method calls subroutine B, which does some stuff and calls
NEXT. So that makes control return to the step in
subroutine A just after the call on LOOP (after incrementing
the counter). So we do the rest of A, return to the top
level, call B again, hit the NEXT, and jump back into A.
The following I quote from the manual:
``There is no harm done by using unmatched LOOPs or NEXTs.
LOOPs establish conditions for the NEXT to test against,
as well as establishing the point to pass control to.
Since unmatched LOOPs have no NEXT, control is never
passed back to the LOOP. Thus, the extra LOOP is
ignored, and the system proceeds with the following
function. Unmatched NEXTs have no conditions to test and
always pass control to the following function.''
Words fail me.
From: BB
Date: Thu, 24 Oct 91 11:17:29 PDT
To:
[email protected]
So I'm using this X window system on a UNIX system and
I'm (relatively) happy. Then I switch to a X terminal and
I'm happier because my X terminal has no fan noise. Then I
notice that my Gnu Emacs windows have this funny behavior:
the sub-shell command no longer seems to work. Why not?
But if I start Emacs from an xterm window, it works fine.
Ah, consistency, that's what I like about Unix,
consistency. So then I do a little hackery and I discover
that the former Emacs processes have no "controlling
terminal" but that the later ones do. Hey, now I'm getting
somewhere, but what the heck is a "controlling terminal"?
And how do I convince my Emacs processes to have one?
Nothing in the man pages about controlling terminals.
There is a system call to remove a controlling terminal, but
none to add one, so writing a program is out. Apparently,
this magic controlling terminal is inherited from the parent
process and thus the problem is that the window manager
process doesn't have one. And the window manager process is
created by the .xsession file. Next I decide to try having
the .xsession file create an xterm which will then execute
my startup csh which will then create the window manager and
then, finally, I'll have controlling terminals.
But I'm foiled again! Apparently, the UNIX wizards have
decided that you can run the csh as an interactive process
or you can give it a command to execute, but you can't do
both. I can't say "run this command (i.e., execute the
startup script) and then be interactive". Argh! Oh, but
wait, I forgot that one process can mutate into another one
using exec. Let's try this incantation: "/bin/csh -c
'source .startup ; exec /bin/csh'" Yep, it works. Now why
didn't I think of that in the first place? Isn't it as
obvious as motherhood and apple pie? And what the heck is a
"controlling terminal" anyway?
From: MT
Date: Thu, 24 Oct 91 13:33:17 PDT
Subject: what ever happened to LISP?
Q. How many typographers does it take to type LISP?
A. One, and I'm not a typographer.
In case you didn't think that joke was funny, consider this:
in the past week there have been about a dozen messages
about how to format C++ in TeX (or LaTeX) so it doesn't come
out looking any stupider than it already is. Here's the
latest constructive contribution:
% To print C++ way use \C++
\def\C++{\leavevmode\rm{\hbox{C\hskip -0.1ex\raise 0.5ex\hbox{\tiny ++}}}}
As Terri F__kwitt (a character from VIZ) would say, "f__k
me!".
From: DH
Date: Fri, 25 Oct 91 05:22:11 PDT
Date: Thu, 24 Oct 91 11:17:29 PDT
From: BB
So I'm using this X window system on a UNIX system and
I'm (relatively) happy.
Here's your problem. If you're happy with unix you're
probably too far gone for help.
Perhaps the "controlling terminal" you seek is a subliminal
device designed to brainwash you into finding unix
acceptable? Or perhaps it's some arcane bit of bondage
equipment used by the kinds of folks who discuss bondage on
unix "newsgroups."
From: JW
Date: Fri, 25 Oct 91 20:14:53 -0400
Subject: Computers Unclear On The Concept.
root@pmws>/etc/shutdown NOW
That must be tomorrow
Can't you wait till then?
root@pmws>^D
script done on Fri Oct 25 20:11:15 1991
Date: Mon, 28 Oct 91 08:50:04 PST
From: DW
Subject: Computers unclear on the concept.
Date: Fri, 25 Oct 91 20:14:53 -0400
From: JW
root@pmws>/etc/shutdown NOW
That must be tomorrow
Can't you wait till then?
root@pmws>^D
script done on Fri Oct 25 20:11:15 1991
I first read your prompt as "root@pms," and thought how
appropriate, to name a unix machine "premenstrual syndrome."
From: AD
Date: Tue, 29 Oct 91 10:47:48 EST
Subject: [Re: talk]
Here in the future, compatiblity means we all use exactly
the same machines?
------- Forwarded Message
Also, gleaned this little piece of info from "man talkd"....
are the loki machines non-suns, like DECs or HPs?
BUGS
The protocol is architecture dependent, and can not be
relied upon to work between Sun systems and other
machines.
------- End Forwarded Message
From: JZ
Date: Tue, 29 Oct 91 10:35:20 PST
Subject: Re: [Re: talk]
In a message AD wrote:
>
> BUGS
> The protocol is architecture dependent, and can not
> be relied upon to work between Sun systems and other
> machines.
This seems to imply that there are byte-order dependencies
in the protocol or something, which may be true, but an even
more incredibly frustrating aspect than that is that Suns
use an arbitrarily different talk protocol than anything
else! Sun, in their infinite wisdom, decided to roll their
own, because why would anyone on a Sun want to talk to
someone who wasn't? The network being the computer and all.
For a laugh, do "man 5 bar" -- another archive-file standard
that Sun is trying to foist on the world. The format is
*exactly* like tar, except for like three differences:
there's a bit saying whether each file has been piped
through compress; there's a string saying whether this file
is a continuation of a multi-part archive; and they have
RANDOMLY PERMUTED the fields!! Normal tar would be able to
read bar files, except for the fact that Sun decided to
reorder everything for no discernable reason.
Not that I don't think tar isn't a steaming pile of shite,
mind you. The only good thing about tar is that it's not
shar.
From: CM
Date: Tue, 29 Oct 91 14:06:25 EST
Subject: Re: [Re: talk]
From: AD
Date: Tue, 29 Oct 91 10:47:48 EST
Here in the future, compatiblity means we all use exactly
the same machines?
BUGS
The protocol is architecture dependent, and can not
be relied upon to work between Sun systems and other
machines.
It probably means some loki droid doesn't know what
the words "byte order" mean.
From: DK
Date: Tue, 29 Oct 1991 13:40-0500
Subject: [Re: talk]
Date: Tue, 29 Oct 1991 10:47 EST
From: AD
Here in the future, compatiblity means we all use
exactly the same machines?
This isn't strictly UNIX hate, but to the best of my
knowledge the only implementation of the talk protocol
(so-called) that compensates for the architecture (actually
byte-ordering) dependencies inherent in the protocols (see
below), and so can interoperate with all other talk
implementations, is written in Lisp, and does not run on
UNIX.
By the way, there's a revised (I hesitate to say "fixed")
version of the talk protocol that removes the byte-ordering
dependencies. It's incompatible with the previous protocol,
and assumes that the OS on the other end is a BSD-derived
UNIX with the same "sockaddr" structure as is used in 4.3
BSD. So here in the future, there are at least three
mutually incompatible versions of this standard.
It must be the users that are compatible, not the software.
------- Forwarded Message
Also, gleaned this little piece of info from "man talkd"....
are the loki machines non-suns, like DECs or HPs?
BUGS
The protocol is architecture dependent, and can not
be relied upon to work between Sun systems and
other machines.
------- End Forwarded Message
From: NZ
Date: Tue, 29 Oct 91 16:27 EST
Subject: Rooting Around In The Dark ...
I was having trouble mounting my server machine,
mintaka, on this sun box called snark (which is registered
in the namespace as a SNARCSTATION-2. But I digress ...)
Everytime I invoked mount, it said:
> mount: mintaka:/ server not responding: RPC:
> Authentication error; why = Invalid client credential
> mount: giving up on:
> /tmp/mnt-tmp
I tried rinsing. I tried soaking. I even tried
nfsc and nfsauth. But still:
> mount: mintaka:/ server not responding: RPC:
> Authentication error; why = Invalid client credential
So then I fiddled /etc/hosts and uppercased various
things since I had been told that maybe there was some old
code that cared. I pushed NIS maps. Quoth the mountd:
> RPC: Authentication error; why = Invalid client [ you get
> the idea ...]
And then someone mentioned that there was this
gratuitous change between versions of NFS involving groups
and how many you were allowed to have and was root, per
chance, in more than 8 groups?
> snark# groups
> staff wheel daemon kmem operator sources guest users im
Hmmm.
Note the elegant care with which the error message
concisely and completely avoided mentioning anything even
remotely concerning what the problem really was.
Note the amount of time it would probably have taken
me to track down this particular difficulty had the
aforementioned well-informed gentlemen not been available.
Note the ease and grace with which this godforsaken
skum-sucking son-of-a virus-breeding diseased-whore
poor-excuse-for-a network-file "system" has completely
penetrated the industry, wreaking havoc with the lives of
innocents, rendering hopeless the lives of thousands of
system administrators, and acidly consuming millions and
millions of miles of hapless intestine contained within the
above innocents and system administrators.
Note that I am not ruling out the possibility that
the system adminstrators are innocent as well - I merely
assume that they have a *lot* more intestine. At least
before they became administrators.
But I digress.
I want a *real* job.
(Extreme thanks to CM and KJ, without whose timely
intervention my sanity would be considerably less ... than
it is today.)
From: JW
Date: Tue, 29 Oct 91 16:30:57 -0500
Subject: [Re: talk]
From: CM
Date: Tue, 29 Oct 91 14:06:25 EST
It probably means some loki droid doesn't know what
the words "byte order" mean.
"Berkeley droid", please; lets keep our coasts straight,
shall we? Here on the east coast, we-all use "Zeypher", the
only system which requires eight separate programs to let
you send an interactive message to someone.
From: DC
Date: Tue, 29 Oct 91 15:38:21 -0800
My sys admin explains that the reason I can't telnet to MIT
is that it is in the wrong time zone.
I'm not making this up.
From: CM
Date: Tue, 29 Oct 91 19:52:15 EST
Subject: Droids
Date: Tue, 29 Oct 91 16:30:57 -0500
From: JW
From: CM
Date: Tue, 29 Oct 91 14:06:25 EST
It probably means some loki droid doesn't know what
the words "byte order" mean.
"Berkeley droid", please; lets keep our coasts straight,
shall we? Here on the east coast, we-all use "Zeypher",
the only system which requires eight separate programs
to let you send an interactive message to someone.
Feh. A droid is a droid no matter which coast it loses on.
*8* separate programs?!?! Hell, that's nothing, boy.
Around here, zephyr requires at least *32* separate programs
to be running for you to send a message. 8 programs at each
end point plus the zephyr server and a backup zephyr server
and a Kerberos key server and a backup kerberos key server.
Good thing computers are so cheap these days or we'd be
stuck using the telephone.
From: CM
Date: Tue, 29 Oct 91 20:34:50 EST
Subject: I Have Seen The Future Of The Future And It Sucks Too.
So I figured I was better than your average unix-haters
reader since, hey, I hack Mach kernels; I'm not just
bitching about how bad things are, I'm actually doing
something about it, damn it!
Well, it all started with when my research version of Mach
went down in flames and took bits and pieces of the file
system with it. In hindsight, I suppose I should have just
lived with things like not being able to print to certain
printers. Well anyway, I had the Facilities people "add 10
megs or so to the root partition, oh and while you're at it,
why don't you rebuild the disk since the filesystem's been
kind of flaky since that, uh, big kernel crash last week..."
So anyway, I came in today and found a brand spankin new
filesystem. All I had to do was replace the v2.5 production
kernel with a v3.0 research kernel. Yep, just replace a
couple files on the root partition and reboot, no problem.
Well, it's a little more complicated than that. For some
unknown reason, mach machines have a "root" directory ("/")
and a "superroot" directory ("/../.."). Once someone tried
to explain why but I didn't quite get it.
Anyway, you have to have hard links to your kernel file in
both root directories. Then since mach is not a kernel but
a microkernel (the micro kernel binary with symbol tables,
debugger, etc is a svelte 950k on a MIPS box, unix emulation
is only another 1500k; I actually *needed* the extra 10 megs
on the root partition) you have to create a mach_servers
directory and populate it with various programs that mach
uses to emulate unix.
Now the tricky part is that since you have two root
directories you can put the mach_servers directory in the
root directory and then put a symlink in the superroot or
you can put the mach_servers directory in the superroot and
put a symlink in the root directory.
The documentation says you can do it either way.
Unfortunately, the documentation doesn't say that it only
works when you put mach_servers in the superroot with a
symlink in root. This also happened to be the second case
given in the documentation and I had the misfortune to use
the first case given in the documentation. Silly me.
So I proceeded to boot my machine 10 or 12 times only to
crash into the kernel debugger every time. I stared at
stack traces and read code and read code and stared at stack
traces. The error messages were no help, they said "init
died". Thanks a lot.
So I finally figured that one out and redid the mach_servers
directory and rebooted once more. It crashed again at about
the same place complaining about "error 6000". Now the
annoying thing about mach is that since your operating
system is spread out over 69 different address spaces, you
never really know for sure who is generating an error code.
You just have to memorize a mapping from error code ranges
to subsystems. Eg errors in the 2500's are from the
device-independent device routines (go figure), -300's are
arg checking errors in an IPC stub routine, you get the
idea. Well anyway, I never ran across 6000 before. So I
hit the source code again... Oh. Error 6000 means some
file is not executable.
One of those damn programs in mach_servers was trying to
exec another of those damn programs in mach_servers which
unfortunately didn't have it's execute bit set so naturally
the exec function, in it's penultimate moment of existence,
exclaimed "6000!" before it crashed the whole show.
I guess the moral is that Mach looks like unix on the
outside but does totally different stuff internally.
However, when you strip away the tasks, threads, ports,
messages, and memory objects, when you get down to the very
essence of the system, the thing is still unix. There is no
hope.
From: DK
Date: Tue, 29 Oct 1991 21:43-0500
Subject: Re: [Re: talk]
Date: Tue, 29 Oct 1991 13:35 EST
From: JZ
In message <9110291547.AA05491@doctor-pepper> Andre' DeHon wrote:
>
> BUGS
> The protocol is architecture dependent, and can not be
> relied upon to work between Sun systems and other machines.
> This seems to imply that there are byte-order
> dependencies in the protocol or something, which may be
> true, but an even more incredibly frustrating aspect
> than that is that Suns use an arbitrarily different
> talk protocol than anything else! Sun, in their
> infinite wisdom, decided to roll their own, because why
> would anyone on a Sun want to talk to someone who
> wasn't? The network being the computer and all.
No, I think you've missed the full horror of the situation.
You see, Sun is shipping THE SAME CODE that Berkeley foisted
off on the computing world. The "Berkeley droids", to
borrow a term, who wrote this code screwed up in the
standard Unix way (not only is everything Unix, but it's all
exactly the same as this-here paperweight on my desk).
Later on, Berkeley "fixed" their mistake by propagating
another implementation of the program that's incompatible
with both the big-endian and little-endian versions of their
previous mistake. The upshot is that few of the commercial
UNIX vendors are willing to be gratuitously incompatible
with their previous releases, so they remain gratuitously
incompatible with other hardware AND the latest, most
grate-like software from Berkeley.
When, in a fit of insanity from which I have only recently
recovered, I wrote the aforementioned Lisp implementation of
this crud, I was able with only slight mental effort to
write code that not only interoperates with all three
versions of Berkeley's insane mutterings, but I was also
able to do it without any burden on the users. I can
understand why this wasn't done in the UNIX implementations,
though: UNIX programmers expend so much effort being
compatible with their environment, they can be forgiven for
not having much energy left for writing responsible
software.
This is all another proof of Brooks' Law: You *will* write a
throw-away implementation; you *may* choose to ship it.
[By the way, and not to contradict my good friend from
tech^2, in *my* part of the east coast we use an
interactive-message protocol that thinks it's a sneaker; if
it weren't for a propensity to try to talk to Texas every
other time I send a message down the hall, I'd be happy. Of
course, we also use computers that don't force us to use
punctuation characters as a substitute for the typographical
variations that Gutenberg invented, back at the end of a
previous Dark Age.]
For a laugh, do "man 5 bar" -- another archive-file
standard that Sun is trying to foist on the world. The
format is *exactly* like tar, except for like three
differences: there's a bit saying whether each file has
been piped through compress; there's a string saying
whether this file is a continuation of a multi-part
archive; and they have RANDOMLY PERMUTED the fields!!
Normal tar would be able to read bar files, except for
the fact that Sun decided to reorder everything for no
discernable reason.
Not that I don't think tar isn't a steaming pile of
shite, mind you. The only good thing about tar is that
it's not shar.
From: DH
Date: Wed, 30 Oct 91 16:42:36 PST
Subject: XanaDOMF
The following announcement was made October 29, 1991 by
SunSoft, a Sun Microsystems, Inc. subsidiary.
SUNSOFT AND HP TO DEVELOP FOUNDATION PLATFORM FOR
DISTRIBUTED OBJECT APPLICATIONS
Both Companies Endorse OMG Object Request Broker
NEW YORK -- Oct. 29, 1991 -- Two of the world's leading
vendors of distributed computing solutions, Hewlett-Packard
Company and SunSoft Inc., today announced a program to
implement and license an object-oriented application
framework that will accelerate the growth of distributed
computing. This application framework will allow third-party
software developers to build next-generation distributed
applications.
The announcement today continues a joint-development pact
announced by SunSoft and HP in February 1991. At that time,
the companies submitted a Distributed Object Management
Facility (DOMF) to the Object Management Group (OMG), a
standards organization founded to promote the theory and
practice of object-management technology in the development
of software. In a related announcement today, the OMG
announced its standard specification for the Object Request
Broker (ORB), which includes the merged submissions of HP,
SunSoft, NCR, Object Design, HyperDesk and DEC and
incorporates the DOMF functionality.
The ORB is a mechanism by which objects transparently make
requests and receive responses across a network. For
example, two financial analysts in different countries could
simultaneously view and interact with a spreadsheet
object. SunSoft and HP are scheduled to offer to
original-equipment manufacturers (OEMs) a 100 percent OMG
ORB-compliant DOMF product in the second half of 1992. This
functionality also will be included with HP's systems
products and with SunSoft's Solaris distributed computing
solution. Early access source code is scheduled to be
offered to OEMs for initial porting work in the second
quarter of 1992.
"A key goal in the HP/SunSoft collaboration is to preserve
user investment in existing software" said Robert
J. Frankenberg, HP vice president and general manager of the
Personal Information Products Group. "The DOMF is designed
to work on a UNIX operating system or a non-UNIX system that
supports distributed operations. Customers don't have to
wait years for the development of totally new software
environments."
"The work of SunSoft, HP and others in conjunction with the
OMG has defined the industry's first standard for object
management on networks," said Steve MacKay, vice president
of user environment software at SunSoft. "Our continued
collaboration on an application frame work will bring object
technology to the volume marketplace faster than ever
anticipated."
The application framework, which includes the DOMF, enables
the development and use of distributed applications. The
application framework will make platform differences and
networking issues transparent to users. Software developers
will write to common interfaces rather than create different
implementations that are tied to the underlying system
software. This permits the creation of a single, highly
portable source code that can run on different vendors'
systems. For end users the application framework will
facilitate the integration of applications and data no
matter where they may be located on a network -- in the next
room or around the world.
"The beauty of this new solution is that it allows
interoperability without changing the system software,"
added MacKay. "Customers can invest in solutions like
Solaris and HP-UX today and know that they will support
distributed object applications as they become available."
Ease of use -- for application developers and end users --
is a prime focus of HP and SunSoft. This is achieved through
object-oriented technology, considered by experts to the
next significant advance in computing. Objects are modules
that contain data as well as instructions that work upon
that data. Object-oriented technology shields users from the
complex computer processes, such as the tasks a system must
perform to access information located on a different
network.
SunSoft, Inc., headquartered in Mountain View, Calif., is a subsidiary
of Sun Microsystems, Inc. The company is a leading worldwide supplier
of system software for distributed computing. SunSoft's products are
targeted at software developers, system administrators and end users,
and are licensed by SunSoft and sold through major computer system
manufacturers and value-added resellers (VARs) worldwide.
Hewlett-Packard Company is an international manufacturer of
measurement and computation products and systems recognized
for excellence in quality and support. The company's
products and services are used in industry, business,
engineering, science, medicine and education in
approximately 100 countries. HP is a leading supplier of
object-oriented systems and software. HP has 93,000
employees and had revenues of $13.2 billion in its 1990
fiscal year.
###
HP-UX is based on and is compatible with USL's UNIX
operating system. It also complies with X/Open's XPG3,
POSIX 1003.1, FIPS 151-1 and SVID2 interface specifications.
1991 Sun Microsystems, Inc., Sun Microsystems, the Sun logo,
SunSoft and Solaris are trademarks or registered trademarks
of Sun Microsystems Inc. UNIX is a registered trademark of
Unix Systems Laboratories, Inc. in the U.S.A. and other
countries. X/Open is a trademark in the UK and other
countries. All other products or service names mentioned
herein are trademarks of their respective owners.
From: DC
Date: Wed, 30 Oct 91 18:38:51 -0800
Subject: For The Record
Apropos the no-telnet-due-to-wrong-timezone message, I was
out to lunch. My sysadmin wasn't. Sorry.
From: KH
Date: Wed, 30 Oct 91 21:40:20 PST
Subject: Re: For The Record
Apropos the no-telnet-due-to-wrong-timezone message, I
was out to lunch. My sysadmin wasn't. Sorry.
The most reasonable interpretation I can make of this is
that your sysadmin was absolutely correct, i.e. it really
*IS* true that the reason you can't telnet to MIT is because
it's in the wrong time zone.
That, at least, would be most consistent with our existing
corpus of Unix experience.
From: RS
Date: Thu, 31 Oct 91 01:10:06 EST
Subject: For The Record
Apropos the no-telnet-due-to-wrong-timezone message, I
was out to lunch. My sysadmin wasn't. Sorry.
Why were you trying to telnet to a Unix system while you
were out to lunch? Were you trying to dull your appetite?
If so, I urge caution. The danger of embarassing yourself
by throwing up at the wrong moment is quite real.
WRT your sysadmin not being out to lunch, well, I can
sympathize. I work through lunch quite often, and not by
choice either. Sometimes I feel like Hans Brinker, with my
finger in the dike, keeping our organization from getting
completely inundated with Unix lossage.
From: NC
Date: Thu, 31 Oct 91 14:49:13 EST
Subject: Re: Words Fail Me Department
This isn't about unix either. Shoot Madonna.
I must say this message has done a great service. I was most
of the way toward concluding that university computer
science departments contain large numbers of brain-defected
individuals who poison poor gullible students' minds with
whatever monstrous pile of rotten drivel they coerced some
halfwit incompetent thesis committee into accepting as their
thesis. They also generally teach them to use Unix. (There,
got it in!) In any case, we'd generally be better off if we
just ripped their lungs or printers out or something.
I now realize that, bad as it is, It Could Be Worse.
From: DH
Date: Thu, 31 Oct 91 13:19:47 PST
Subject: Re: For The Record
Date: Wed, 30 Oct 91 18:38:51 -0800
From: DC
> Apropos the no-telnet-due-to-wrong-timezone message, I
> was out to lunch. My sysadmin wasn't. Sorry.
So, is this some message generated by a sendmail bug?
Or perhaps this is a stalinesque "public recantation"
designed to protect future employment prospects?
From: RM
Date: Mon, 4 Nov 91 13:41:13 EST
Subject: C++ Is Good For Fertilizer
This message is in reply to a "discussion" spurred by the
"observation" that (I quote roughly and from memory)
"Computers are used by 50% of the people in the world, and C
is used by 50% of all programs, therefore improving C [ie
incrementing it and discarding the result] will potentially
make the world a 25% better place to live." I am not making
this up.
The original subject line for the discussion was "C++ is
good for the world."
From: PS
Date: Tue, 5 Nov 91 11:02:18 EST
Subject: Re: [Apple Direction Statement on Unix/Open Systems]]
Apple and IBM have seen the future, and they bet that it is
Unix.
Now how does that go? Lasciate ogni speranza, or something
like that.
Apple Direction Statement on Unix/Open Systems------------------------
MOVED OVER PR NEWSWIRE AT 8:16 AM, EST, WEDNESDAY, OCTOBER 30, 1991.
Contact:
Jackie Promes
Apple Computer, Inc.
(408) 974-3609
Apple Announces Roadmap for UNIX/Open Systems; A/UX 3.0 Paves the Way
UNIX Expo, New York--October 30, 1991--Apple Computer,
Inc. today defined a roadmap for its future UNIX
directions, enabling customers and developers to easily
migrate to the future, industry-standard UNIX
environment--PowerOpen. A/UX 3.0, Apple's new version of
its industry-standard UNIX for the Macintosh computer,
was also announced today as the next step in providing
smooth migration to this environment.
PowerOpen, a new open-systems environment created by
Apple and IBM's recent alliance, will offer customers and
developers an easy-to-use, standards-based,
high-performance system. Through the integration of A/UX
and IBM's AIX, customers will have access to the
thousands of Macintosh productivity applications and the
thousands of AIX technical applications.
...
I have elided the rest to spare your sensitivities.
From: DH
Date: Tue, 5 Nov 91 12:37:40 PST
Subject: Re: Power Open
From: PS
Date: Tue, 5 Nov 91 11:02:18 EST
UNIX Expo, New York--October 30, 1991--Apple Computer,
Inc. today defined a roadmap for its future UNIX
directions, enabling customers and developers to
easily migrate to the future, industry-standard UNIX
environment--PowerOpen.
"PowerOpen" sounds like something you use while wearing red
braces while attending a business breakfast.
Shouldn't they have called it KinderGentlerOpen?
From: PS
Date: Wed, 6 Nov 91 09:44:56 EST
Subject: Re: Power Open
Date: Tue, 5 Nov 91 12:37:40 PST
From: DH
From: PS
Date: Tue, 5 Nov 91 11:02:18 EST
UNIX Expo, New York--October 30, 1991--Apple
Computer, Inc. today defined a roadmap for its
future UNIX directions, enabling customers and
developers to easily migrate to the future,
industry-standard UNIX environment--PowerOpen.
"PowerOpen" sounds like something you use while wearing
red braces while attending a business breakfast.
Shouldn't they have called it KinderGentlerOpen?
This may actually be an indication of how long they expect
it will take them to get the product to market. Perhaps by
the time they manage to start selling PowerOpen, they expect
the business and social cycles to have come back to the
point where they were in early 1986, and the name will
connote exactly the sort of ambition and power-lust -- I'm
sorry, I really meant to say hard-driving business acumen --
that will be fashionable again by then.
From: CM
Date: Wed, 6 Nov 91 10:53:46 EST
Subject: Re: Power Open
Date: Tue, 5 Nov 91 12:37:40 PST
From: DH
"PowerOpen" sounds like something you use while wearing
red braces while attending a business breakfast.
Shouldn't they have called it KinderGentlerOpen?
As part of my research on the Mach project at CMU, I've been
working on a program that generates names for future
versions of the unix operating system. Version 0.1 of this
program will take a list of words and generate a random
permutation of those words. Examples are as follows:
input> { power, open, open-systems, desktop }
output>
open power desktop
open open-systems
power desktop
desktop open-systems
etc.
Perhaps I'll add kinder-gentler to the word list. Maybe
kinder-gentler power desktop will be the unix of the
future...
From: DW
Date: Wed, 6 Nov 91 11:06:24 EST
Subject: Re: Power Open
Or maybe it's just the name of the operating system that
runs in the Advanced Unix Solution (TM) that controls the
glass store door that opens by itself when you walk through
it. ("Attention K-mart shoppers: Stale NFS file handle!")
From: MF
Date: Wed, 6 Nov 91 14:42:39 -0500
Subject: Re: Power Open
>> As part of my research on the Mach project at CMU, I've
>> been working on a program that generates names for future
>> versions of the unix operating system. Version 0.1 of
>> this program will take a list of words and generate a
>> random permutation of those words. Examples are as
>> follows:
>>
>> input> { power, open, open-systems, desktop }
>>
>> output>
>> open power desktop
>> open open-systems
>> power desktop
>> desktop open-systems
>> etc.
The should also be a subtitle composed of a random
permutation of at least the following: "object-oriented",
"distributed", "parallel", "standards-compliant", "secure",
"user-friendly", "portable" and worst of all
"backward-compatible". The permutation should then be
suffixed with a string generated by the unixoid regular
expression "[A-Z]+-?IX".
So now we get things like:
open power desktop: a secure distributed portable HI-IX
desktop open-systems: a parallel standards-compliant
user-friendly MOKIX.
From: NZ
Date: Wed, 6 Nov 91 17:56 EST
Subject: The OpSys Of The Future ...
> Through the integration of A/UX and IBM's AIX, customers
> will have ...
I know what I'd call a merger of these two: ANUX .
From: CM
Date: Thu, 7 Nov 91 11:16:23 EST
Subject: Re: Power Open
Date: Wed, 6 Nov 91 14:42:39 -0500
From: MF
>> As part of my research on the Mach project at CMU, I've
>> been working on a program that generates names for future
>> versions of the unix operating system.
The should also be a subtitle composed of a random
permutation of at least the following:
"object-oriented", "distributed", "parallel",
"standards-compliant", "secure", "user-friendly",
"portable" and worst of all "backward-compatible". The
permutation should then be suffixed with a string
generated by the unixoid regular expression
"[A-Z]+-?IX".
So now we get things like:
open power desktop: a secure distributed portable HI-IX
desktop open-systems: a parallel standards-compliant
user-friendly MOKIX.
Ah, yes. The next version of the program will have
something like this. I hadn't been able to think of any
words for the second list except object-oriented. I also
plan on adding suffixes like "micro-kernel" to any of the
names with n% probability. eg:
open power desktop: a secure distributed portable HI-IX
micro-kernel desktop open-systems: a prallel
standards-compliant user-friendly MOKIX micro-kernel
I suppose I should add "kernelized" to the second list as
well.
From: CM
Date: Thu, 7 Nov 91 11:19:56 EST
Subject: [US Version US43]
At least the sender didn't talk about paradigm shifts...
Date: Wed, 6 Nov 91 17:01:02 -0500 (EST)
From: [deleted]
Subject: US Version US43
New features:
--- --------
The mach3 multi-server world has moved. This version, us43,
is the first C++ release of the system. It includes:
[...]
From: MB
Date: Thu, 7 Nov 91 13:20:48 EST
Subject: Re: Power Open
>>>>> On Thu, 7 Nov 91 11:16:23 EST, CM said:
CM> open power desktop: a secure distributed portable HI-IX
CM> micro-kernel
CM> desktop open-systems: a prallel standards-compliant
CM> user-friendly MOKIX micro-kernel
CM>
CM> I suppose I should add "kernelized" to the second list
CM> as well.
What!? Is the sainted expression "seamlessly integrated"
doomed to neglect?
From: CM
Date: Thu, 7 Nov 91 18:05:23 EST
Subject: Re: Power Open
Date: Thu, 7 Nov 91 12:12:51 PST
From: SR
MMDF-Warning: Parse error in original version of
preceding line at <some-site>
And "dynamically". Let's not forget "dynamically".
Shall we go for "custom-blended" and "Viennese roasted" as well?
Oh, I don't know. This is starting to get silly.
On the other hand, custom-blended may very well be a selling
point for users of the gnu hurd or the mach multi-server.
Date: Fri, 8 Nov 91 08:43:07 EST
From: JD
Subject: The Future Of Documents
I was reading about a new system (called HyTime) and ran
across a reference to a feature called a "projectr" [sic].
Later on I saw the following footnote:
"The missing o is not a spelling error...[because] the
Reference Concrete Syntax defined by ISO 8879-1986 allows
a maximum of only eight characters for each identifier.
Since the Reference Concrete Syntax constitutes the
minimum set of requirements which all SGML systems must
meet, all HyTime identifiers have been limited to eight
characters for the sake of minimally conforming parsers."
Pretty non-non heinous. So just because the designers of
SGML wanted to be able to award a certificate of merit to
boneheaded implementations that can't handle names longer
than EIGHT characters, anything built on top of SGML
inherits the same restriction.
Well maybe I can't blame this on Unix. SGML itself comes
from IBM via ISO. But the attitude is the same. Grrr.
p.s. For what it's worth, SGML is the Standard Generalized
Markup Language, it is sort of like Scribe meets Ada; and
HyTime is suppoed to be a hypertext and multimedia package
on top of SGML, it was originally intended to be a standard
language for describing music, but the authors decided to
generalize it. And the article is in the current CACM.
From: GR
Date: Fri, 8 Nov 91 10:41:50 est
Subject: Re: The Future Of Documents
Date: Fri, 8 Nov 91 08:43:07 EST
From: JD
...
Pretty non-non heinous. So just because the designers
of SGML wanted to be able to award a certificate of
merit to boneheaded implementations that can't handle
names longer than EIGHT characters, anything built on
top of SGML inherits the same restriction.
Well maybe I can't blame this on Unix. SGML itself
comes from IBM via ISO. But the attitude is the same.
Grrr.
...
You are right. You can't blame it on Unix. C/Unix only
guarantees 7.
From: DM
Date: Fri, 08 Nov 91 11:06:19 EST
Subject: Re: Power Open
> Date: Wed, 6 Nov 91 11:06:24 EST
> From: DW
> ...
> Advanced Unix Solution (TM) that controls the glass store
> door that opens by itself when you walk through it.
> ("Attention K-mart shoppers: Stale NFS file handle!")
Oh is that what an AUSsie is? I've been confused for years,
then.
From: RM
Date: Sun, 10 Nov 91 08:27:22 EST
Subject: Paradigm shifts
This is all derivative of the "New Genericity Substrate
Protocol Subsystem System" of circa 1989 (from the people
who brought you "SmartAss"). Their failure was due to the
fact that they did not include the essential
"object-oriented" and "integrated" and "threaded" words into
the Market-O-Matic, thinking that these things were too
mundane to bother mentioning.
From: DW
Date: Mon, 11 Nov 91 11:37:49 EST
Subject: [os bashing]
Passing this along for those of you who haven't had it
forwarded to you yet...
Date: Mon, 11 Nov 91 06:43:24 PST
From: gnomes from Alaska 11-Nov-1991 0942
[Copied w/o permission from 9/24/91 PC Magazine]
John C Dvorak's Great Operating System Quiz
Finding the right operating system is as simple as ordering
a pizza and answering some easy questions.
In the months (and perhaps years) ahead, many of us will be
confronted by a decision: What operating system to choose?
DOS? Unix? DOS with windows?
As I watch more and more users choose sides, it's apparent
that there are aspects of individual personalities that work
into the decision. So I did some arduous research to
develop one of my famous tests to help people determine
which operating system is best for them. I examine a
combination of both computing needs and personal habits.
Circle either the DOS, OS/2, W (for Windows), or Unix choice
next to your favorite answer. Count up the number of
answers for each choice. Whichever one dominates should be
the right operating system for you. If there is a mismatch
of answers, then you should probably wait a year.
Dvorak's Operating System Quiz
1. What application do you expect to use the most?
DOS) Spreadsheet
OS/2) Large complex database
W) Solitaire
Unix) GREP
2. What is your favorite TV show?
DOS) "Nova"
OS/2) "The MacNeil-Lehrer Report"
W) Woody Woodpecker
Unix) The 3 A.M. test pattern
3. What is your favorite hobby?
DOS) Stamp Collecting
OS/2) Bird Watching
W) Snail Racing
Unix) Button Collecting
4. What kind of clothes do you prefer?
DOS) Sports suit, no tie.
OS/2) Suit and tie.
W) Sweater and jeans.
Unix) Nerdy T-shirt, jeans, and no underpants.
5. What kind of music do you like?
DOS) The Beatles
OS/2) Classical
W) New Age fusion music
Unix) Tuba solos
6. What's your favorite color?
DOS) Modern beige
OS/2) Blue
W) Stark white
Unix) Pizza-stain red
7. What's your favorite car?
DOS) Ford
OS/2) Lexus
W) Fake Bugatti
Unix) Borgward
8. Who is your favorite artist?
DOS) Rembrandt
OS/2) Pollack
W) Dali
Unix) Gary Larsen
9. Who is your favorite author?
DOS) Robert Heinlein
OS/2) Tom Wolfe
W) John Madden
Unix) Walt Disney
10. Who is your favorite actor?
DOS) Rod Steiger
OS/2) John Wayne
W) Leonard Nimoy
Unix) Richard Simmons
11. Who was your favorite president?
DOS) Abe Lincoln
OS/2) Ronald Reagan
W) Jack Kennedy
Unix) Hubert Humphrey
12. What's your preferred breakfast food?
DOS) Cereal
OS/2) Steak and eggs
W) Softboiled egg
Unix) Pizza
13. If time wasn't important, how would you prefer to travel?
DOS) Walk
OS/2) Steam train
W) Hot air balloon
Unix) Pogo stick
14. (to be answered by men) If you were stuck on a desert island
with only one woman, whom would you choose?
DOS) Kim Basinger
OS/2) Meryl Streep
W) Dr. Ruth Westheimer
Unix) a photo of Kim Basinger
15. (to be answered by women) If you were stuck on a desert island
with only one man, whom would you choose?
DOS) Kevin Costner
OS/2) Arnold Schwarzenegger
W) Bill Gates
Unix) a photo of Kim Basinger
16. When you get up in the morning, what is the first thing you do?
DOS) Shower
OS/2) Brush teeth
W) Gargle
Unix) Pick off food stuck to body from sleeping with pizza
17. What's the last thing you do before going to bed?
DOS) Let out cat, turn off lights
OS/2) Brush teeth
W) Pray
Unix) Check to see if there is a pizza in the bed
Tally your score and don't waste a minute finding pleasure
in the operating system that suits you best. One disclaimer
I have to make: Anyone scoring 17 straight "Unix" answers
should seek counseling immediately.
From: DH
Date: Mon, 11 Nov 91 12:11:40 EST
Subject: Re: Paradigm shifts
From: RM
Date: Sun, 10 Nov 91 08:27:22 EST
This is all derivative of the "New Genericity Substrate
Protocol Subsystem System" of circa 1989 (from the
people who brought you "SmartAss"). Their failure was
due to the fact that they did not include the essential
"object-oriented" and "integrated" and "threaded" words
into the Market-O-Matic, thinking that these things were
too mundane to bother mentioning.
Are you implying that Unix is no longer stuck in the '60s
but has now caught up with where the Lisp Machine was in
1984?
Will C++ and X11R5 do for Unix what Dynamic Windows did for
Symbolics?
From: NC
Date: Tue, 12 Nov 91 13:41:58 EST
Subject: Stupid 'RM'
Ever try to get rid of a file named '-'? Since we no
longer have the wonderful 'dsw' command, which was great for
those nasty file names with the meta bits set, you gotta do
it the hard way; 'rm -' won't work since rm looks for the
flag.
However, plain 'rm -i *' doesn't hack it, since a
file called '-' is at the start of the sorted list, and rm
*still* thinks it's a flag. Solution? Create a file called
'+' (which is ahead of - in the ASCII sort sequence) and
Bob's yer uncle.
Yech. I damn near thought I was going to have to
write a program to do it. (Did anyone ever create file names
with '>'s in them on Multics?)
Date: Tue, 12 Nov 1991 16:52-0500
From: DK
Subject: Re: Stupid 'RM'
Date: Tue, 12 Nov 1991 13:41 EST
From: NC
Ever try to get rid of a file named '-'? Since we
no longer have the wonderful 'dsw' command, which was
great for those nasty file names with the meta bits
set, you gotta do it the hard way; 'rm -' won't work
since rm looks for the flag.
However, plain 'rm -i *' doesn't hack it, since a
file called '-' is at the start of the sorted list, and
rm *still* thinks it's a flag. Solution? Create a file
called '+' (which is ahead of - in the ASCII sort
sequence) and Bob's yer uncle.
Yech. I damn near thought I was going to have to
write a program to do it. (Did anyone ever create file
names with '>'s in them on Multics?)
rm ./-
Isn't it awful how UNIX gets you thinking like a UNIX
weenie, even when it isn't necessary?
From: DE
Date: Tue, 12 Nov 1991 14:45-0800
Subject: Random Unix similes
> From: MF
> Yep, Unix can sure handle text. It can also handle
> text. Oh, by the way, did I mention that Unix is good at
> handling text.
Text ... text ... oh yeah ... you mean VI, right?
From: SS
Date: Tue, 12 Nov 91 19:10:26 EST
Subject: Re: Stupid 'RM'
Date: Tue, 12 Nov 1991 16:52-0500
From: DK
rm ./-
That's a pathname? I thought that was the usenet smileygram
for Bill the Cat.
From: DM
Date: Wed, 13 Nov 91 11:12:26 EST
Subject: Re: Stupid 'RM'
Please bear in mind that the unix-haters mailing list is
not to be used for disseminating useful information that
might actually help someone get a job done. Thanks.
(Although I admit that the three copies of the answer to
Noel's question did succeed in making me vomit at least
twice.)
From: KP
Date: Wed, 13 Nov 1991 18:24-0500
Subject: unknown users, known lossage
The following message, included in its entirety except
for the Received and Return-Path fields, pretty much speaks
for itself. (In fact, the message body pretty much includes
all of the accumulated wisdom of Unix systems.) [The name
"acme" has been substituted to protect the...uh... other
victim.]
-----
Date: Wed, 13 Nov 1991 17:58 EST
From:
[email protected]
From: EW
Date: Wed, 13 Nov 91 17:11:46 PST
Subject: Don't Tell Me About Curses
BTW, The very concept of providing a "free" version of U***
(so that, presumably, all the more people may choke on their
own emeses) is SO utterly antisocial and disgusting that FSF
is just about up there with the National Security Council,
the Carnegie Fdn. for the Advancement of Teaching, the
Trilateral Commission, and <fill in your favorite source of
conspiratorial action here>.
The price of U*** should be very high indeed...
From: SG
Date: Thu, 14 Nov 91 10:40:54 PST
Subject: Re: Don't Tell Me About Curses
> Begin forwarded message:
>
> Date: Wed, 13 Nov 91 17:11:46 PST
> From: EW
> Subject: Don't Tell Me About Curses
>
> The price of U*** should be very high indeed...
>
>
The price of UNIX is very high. Expensive to support. Hard
to move away from. But like any highly dependency forming
drug, it doesn't cost much to get hooked.
From: AB
Date: Thu, 14 Nov 91 21:04:41 EST
Subject: Signatures
This message appeared in the most recent RISKS digest:
To:
[email protected]
Date: Fri, 8 Nov 91 15:30:16 CST
Subject: I DEMAND AN APOLOGY FOR THIS LIBEL!
[This is a copy of letter to <someone else> from WG.]
Sir:
In your UNSIGNED post in RISKS-12.62 you utter and
publish a number of spurious, gratuitous libels against
myself...
[ Here I have edited out the details of the alleged libel. ]
It was obviously your intent to commit libel against me
by the manner in which you sent this post. It was
unsigned....
[ More details omitted. ]
I DEMAND A PUBLIC APOLOGY AND RETRACTION, SINCE YOU
CHOSE TO MAKE THIS LIBEL A PUBLIC AFFAIR IN THE FIRST
PLACE!
Signed: WG
[ And finally the RISKS moderator remarks: ]
[... I hesitate to add that WKG's original note was
also UNSIGNED. I wish all of you -- and especially
BITNET folks -- would at least sign your EMail! PGN]
Now the thing that I find incomprehensible is the notion
that a "signature" has become something it is anti-social
not to have.
I've been sending and receiving electronic mail for -years-
and I've always felt that the "From:" field in the header
was perfectly adequate at identifying the author of a
message. The ancients who designed the format of a header
(as set forth in the venerable RFC822) clearly intended that
the "From:" field would serve this purpose. Witness the
fact that they also gave us "Sender:" and "Reply-To:", so
that "From:" could serve purely as author identification.
I would guess that the reason we now have people who are
unwilling to rely on the "From:" field to identify the
author of a message has a lot to do with the mail tools that
people have been given. Tools that make it hard for the
author to control the contents of his "From:" field, tools
that alter its contents unnecessarily during transmission,
and tools that hide its contents from the recipient. And
you all know which popular operating system promoted the
development of many of those tools...
From: CM
Date: Thu, 14 Nov 91 22:54:50 EST
Subject: lpr-n-tell
Well, this makes a lot of sense.
----------
13-Nov-91 19:27
[email protected] lpr -vs- tell(1)
Every time I print something, I get messages of the form:
*** 18:36 *** Printing Service (
[email protected]) :
[beryl] (netisr.h, etc) completed successfully
The lpr man page purports that this should only occur in the
presence of -S:
-S Use the tell(1) program for notification about
errors or completion. The tell program only works
for clients with a SIX-SCS modified talk(1)
daemon.
But I never use -S and get the msgs regardless. I prefer
only zephyr notification. How do I shut off the silly
tell(1) msgs?
----------
13-Nov-91 20:32
[email protected] Re: lpr -vs- tell(1)
I wrote:
How do I shut off the silly tell(1) msgs?
As a couple of people have now pointed out, lpr uses the
obsolete OPR variable and assumes -S as a result.
Annihilating my $OPR takes care of the problem.
Thanx for the responses.
----------
13-Nov-91 20:37 SD Re: lpr -vs- tell(1)
From: SD
try
unsetenv OPR
--
Date: Fri, 15 Nov 91 10:03:48 EST
From: DH
Subject: Signatures
Date: Thu, 14 Nov 91 21:04:41 EST
From: AB
Now the thing that I find incomprehensible is the notion
that a "signature" has become something it is
anti-social not to have.
As was discussed in unix-haters several years ago, I think
"unsigned" is some sort of weenie obscenity (perhaps they
secretly share my dislike of numerical code). See how much
sense this note makes if I substitute a common obscenity:
To:
[email protected]
Date: Fri, 8 Nov 91 15:30:16 CST
From: WG
Subject: I DEMAND AN APOLOGY FOR THIS LIBEL!
[This is a copy of letter to: <someone-else> from WG.]
Sir:
In your BULLSHITE post in RISKS-12.62 you utter and
publish a number of spurious, gratuitous libels
against myself...
[ Here I have edited out the details of the alleged libel. ]
It was obviously your intent to commit libel against
me by the manner in which you sent this post. It was
bullshite....
[ More details omitted. ]
I DEMAND A PUBLIC APOLOGY AND RETRACTION, SINCE YOU
CHOSE TO MAKE THIS LIBEL A PUBLIC AFFAIR IN THE FIRST
PLACE!
[ And finally the RISKS moderator remarks: ]
[... I hesitate to add that WKG's original note was
also BULLSHITE. I wish all of you -- and especially
BITNET folks -- would at least sign your EMail! PGN]
Yours in hating that unsigned piece of crap, unix.
From: SS
Date: Fri, 15 Nov 91 13:36:21 EST
Subject: Re: Signatures
From: AB
Now the thing that I find incomprehensible is the notion
that a "signature" has become something it is
anti-social not to have.
Return addresses? A unix signature isn't a return address,
it's the ASCII equivalent of a black velvet clown
painting. It's a rectangle of carets surrounding a quote
from a literary giant of weeniedom like Heinlein or Dr. Who.
From: BB
Date: Fri, 15 Nov 91 13:46:35 PST
Subject: The Decline of the Soviet Empire
Now that that the Soviet Empire has crumbled and the Evil
Reds are Bankrupt, perhaps the KGB-spawned threat the
Western Productivity (i.e., UNIX) will fade away. On the
other hand, maybe Curiosity Killed the Empire---it is well
known that the Evil Empire "borrows" Silicon Valley
technology. Maybe they accidentally borrowed a few UNIX
systems to do their Five-Year Plans on. That, as we know,
would have been enough to doom their Central Planning to
failure... Hmmm, does the U.S. Administration use Unix?
From: JL
Date: Sat, 16 Nov 91 07:32:55 EDT
Subject: Signatures And From Lines
Actually, the wonderful systems we have today screw you when
it comes to From lines on at least two levels. Yes, as AB
points out, they provide you with no decent control and
bizarre and inappropriate rewriting. But at an even lower
level, before the mailers even come into play, we have the
problem of user ids.
In this day and age, when main memory comes in megabyte
chunks and disks in near-gigabyte chunks, and even CPU
cycles in the tens of millions every second, you'd think
that it would be possible to assign something at least very
much like real people names as user ids.
And on many systems you can. On many systems you could 10,
20 years ago. But that's not sufficiently "computerish".
No, we have the two brave holdouts: IBM systems, with their
8-letters-and-digits - and Unix, with their 8 letters that
no Unix system manager in the world even seems willing to
waste.
Hey, those letters are VALUABLE. Much better to assign
three-letter initials. You can use the extra five bytes
you've saved on every account for something else. Hmm,
maybe yet another X window manager. Or another grep
variant. (ggrep: Optimal when you want to search a few
files for each of hundreds of different strings.)
If three letters was good enough for dmr, it should be good
enough for you!
From: CM
Date: Mon, 18 Nov 91 16:12:44 EST
Subject: os/2 lossage
Well, this does not contain any irrational hatred of
unix but I think it is still germane to this forum since the
original posters are obviously products of
unix-weenie-descended culture. I ask the ruling cabal for
an Indulgence.
[forwarded from somewhere at microsoft, I think]
| >From kh Mon Nov 18 11:03:19 1991
| To: asdfnews
| Subject: FW: IBM OS/2.O Demo at the Northeast Computer Show
|
| Date: Mon Nov 18 11:03:04 1991
|
| >From as Fri Nov 15 15:09:29 1991
| To: asgroup
| Subject: FW: IBM OS/2 2.0 Demo at the Northeast Computer Show
| Date: Fri Nov 15 14:59:26 PDT 1991
|
| >From d Fri Nov 15 14:19:50 1991
| To: maoffice nettalk
| Subject: IBM OS/2 2.0 Demo at the Northeast Computer Show
| Date: Thu Nov 14 18:16:10 PDT 1991
|
| HI,
|
| Just thought that I would fill all of you in on a trip
| that SS and I took to the Northeast Computer Show in
| Boston this week.
|
| Well S and I attended an IBM os/2 2.0 DEMO FROM HELL!
|
| The presentation was supposed to be the latest OS/2 2.0
| Beta Code and they gave out registration cards for a free
| production copy when the shrink wrap product will be
| available in March or April.
|
| First off, the room was seated for 88 people. Only
| 15 showed up including 4 IBM sales staff and Steve and I.
|
| The presenter extolled the virtues of the OS/2 protected
| operating system and how Windows with it's UAE problems
| was inferior. He then went through the most korny demo
| that I have ever experienced! Some guy that looked like a
| cross between an athlete and Michael Jackson dancing
| around the screen pushing buttons and "saying join the fun
| of OS/2". After this two people left the room, we are now
| down to 9 people.
|
| He then demonstrated Lotus 123 for OS/2 and WordPerfect.
| He tried three times, unsuccessfully, to cut a selected
| area from the 123 spreadsheet into WordPerfect. On the
| fourth time he got half of the first line to paste into
| WordPerfect. What no DDE?
|
| Next he went into how OS/2's full screen Windows emulation
| was better than Windows. He clicked on the Icon and the
| system went into "Bit Heaven" and he had to do Atl-Esc to
| get back to the main PM Window. He tried again with the
| same results. He tried one more time and OS/2 crashed
| with a "TRAP ERROR". He very quickly did the three finger
| salute and told the audience that this version of OS/2 had
| a new IPL feature that automatically rebooted OS/2 and put
| him back in his original environment. Two of the
| attendees got verbally violent with the IBM staff. We
| never had to ask a single question, the audience asked all
| the right ones for us.
Date: Mon, 18 Nov 1991 20:49-0500
From: AW
Subject: Re: Don't Tell Me About Curses
Date: Wed, 13 Nov 1991 20:11 EST
From: EW
BTW, The very concept of providing a "free" version of
U*** (so that, presumably, all the more people may
choke on their own emeses) is SO utterly antisocial and
disgusting that FSF is just about up there with the
National Security Council, the Carnegie Fdn. for the
Advancement of Teaching, the Trilateral Commission, and
<fill in your favorite source of conspiratorial action
here>.
The price of U*** should be very high indeed...
This has indeed puzzled me about FSF. Here is an
organization with incredibly lofty (IMHO misguided, but
lofty) political ideals, and apparently no technological or
engineering ideals whatsoever.
It's as if there were a shite cartel charging high prices for
shite, and a counter-culture grassroots movement agitating
that shite should be free.
For those who want shite, I guess it matters.
From: DH
Date: Tue, 19 Nov 91 08:27:49 EST
Subject: Once Again, Weenix Unies Reinvent History
Yesterday Rob Pike from Bell Labs gave a talk on the latest
and greatest successor to unix, called Plan 9. Basically he
described ITS's mechanism for using file channels to control
resources as if it were the greatest new idea since the
wheel.
There may have been more; I took off after he credited Unix
with the invention of the hierarchial file system!
From: DM
Date: Tue, 19 Nov 91 10:25:51 EST
Subject: Re: Don't Tell Me About Curses
Well, what can I say. Unix Happens.
Date: Tue, 19 Nov 1991 08:27-0800
From: WR
Subject: Re: Don't Tell Me About Curses
Date: Mon, 18 Nov 1991 17:49 PST
From: AW
Date: Wed, 13 Nov 1991 20:11 EST
From: EW
[astoundingly egregious documentation elided]
[more stuff removed]
This has indeed puzzled me about FSF. Here is an
organization with incredibly lofty (IMHO misguided, but
lofty) political ideals, and apparently no
technological or engineering ideals whatsoever. It's
as if there were a shite cartel charging high prices for
shite, and a counter-culture grassroots movement
agitating that shite should be free.
For those who want shite, I guess it matters.
This is an insult to shite. At least things can grow in
shite, while everything dies in U***. Both stink.
From: AB
Date: Tue, 19 Nov 91 13:53:22 EST
Subject: Once Again, Weenix Unies Reinvent History
Date: Tue, 19 Nov 91 08:27:49 EST
From: DH
Yesterday Rob Pike from Bell Labs gave a talk on the
latest and greatest successor to unix, called Plan 9.
Basically he described ITS's mechanism for using file
channels to control resources as if it were the greatest
new idea since the wheel.
Amazing, wasn't it? They've even reinvented the JOB device.
In another couple of years I expect they will discover the
need for PCLSRing (there were already hints of this in his
talk yesterday).
I suppose we could try explaining this to them now, but
they'll only look at us cross-eyed and sputter something
about how complex and inelegant that would be. And then
we'd really lose it when they come back and tell us how they
invented this really simple and elegant new thing...
From: SG
Date: Tue, 19 Nov 91 12:54:52 PST
Subject: Re: Don't tell me about curses
Actually, the GNU project has much higher coding standards
than the UNIX kernel. For example: no fixed constants.
Everything must dynamically expand.
UNIX is terrible. GNU is trying to make a UNIX that isn't
terrible, just bad.
From: AW
Date: Tue, 19 Nov 1991 16:27-0500
Subject: Re: Don't tell me about curses
Date: Tue, 19 Nov 1991 15:54 EST
From: SG
Actually, the GNU project has much higher coding
standards than the UNIX kernel. For example: no fixed
constants. Everything must dynamically expand.
UNIX is terrible. GNU is trying to make a UNIX that
isn't terrible, just bad.
Not a good excuse. Shite painted pink is just pink shite.
Why didn't FSF try to invent a free operating system that
was good? Answer: their political agenda is 10^6 times more
important to them than good engineering.
Date: Tue, 19 Nov 91 15:12:47 PST
From: EB
Subject: comp.lang.c Answers to Frequently Asked Questions (FAQ)
Here's another great one:
38. How can I write a generic macro to swap two values?
A: There is no good answer to this question. If the values
are integers, a well-known trick using exclusive-OR
could perhaps be used, but it will not work for
floating-point values or pointers, (and it will not
work if the two values are the same variable, and the
"obvious" supercompressed implementation for integral
types a^=b^=a^=b is, strictly speaking, illegal due to
multiple side- effects, and...). If the macro is
intended to be used on values of arbitrary type (the
usual goal), it cannot use a temporary, since it does
not know what type of temporary it needs, and standard
C does not provide a typeof operator.
The best all-around solution is probably to forget
about using a macro, unless you don't mind passing in
the type as a third argument.
From: EB
Date: Tue, 19 Nov 91 15:08:22 PST
Subject: comp.lang.c Answers to Frequently Asked Questions (FAQ)
This monthly posting is always good for a laugh. (You've
got to laugh to keep from crying). The following entry
needs no further comment:
40. What's the best way to write a multi-statement cpp
macro?
A: The usual goal is to write a macro that can be invoked
as if it were a single function-call statement. This
means that the "caller" will be supplying the final
semicolon, so the macro body should not. The macro
body cannot be a simple brace-delineated compound
statement, because syntax errors would result if it
were invoked (apparently as a single statement, but
with a resultant extra semicolon) as the if branch of
an if/else statement with an explicit else clause.
The traditional solution is to use
#define Func() do { \
/* declarations */ \
stmt1; \
stmt2; \
/* ... */ \
} while(0) /* (no trailing ; ) */
When the "caller" appends a semicolon, this expansion
becomes a single statement regardless of context. (An
optimizing compiler will remove any "dead" tests or
branches on the constant condition 0, although lint
may complain.)
If all of the statements in the intended macro are
simple expressions, with no declarations or loops,
another technique is to write a single, parenthesized
expression using one or more comma operators. (This
technique also allows a value to be "returned.")
Date: Tue 19 Nov 91 17:25:27-PST
From: WW
Subject: Re: Don't Tell Me About Curses
Shite painted pink is just pink shite. Why didn't FSF
try to invent a free operating system that was good?
Answer: their political agenda is 10^6 times more
important to them than good engineering.
I doubt that, given that RMS had no particular unix
experience when he started FSF (which may explain a lot).
Given a background of ITS and Lisp Machines, I suspect unix
was chosen as the OS of choice because:
1) Useful tools could be developed and used before the
OS was ready.
2) There was sufficient public domain and portable
pieces of unix to serve as a place to start.
3) replacing unix would be "better for the world" than
replacing ITS.
RMS spent a lot of time before FSF trying to do basically
similar things with lisp machines. No one noticed, no one
cared, and there aren't any more lisp machines anyway...
From: AB
Date: Tue, 19 Nov 91 21:34:23 EST
Subject: Don't Tell Me About Curses
Date: Tue, 19 Nov 1991 16:27-0500
From: AW
...
Why didn't FSF try to invent a free operating system that
was good?
...
I think it would be a bad idea to start a discussion on
Unix-Haters about the politics of the FSF. I'm sure there
are better forums. Some of you people are far to eager to
hit the reply button in your mail reader and sound off
without thinking very hard about what Unix-Haters is all
about.
It's been a while since we flushed anyone from Unix-Haters
for neglecting to say anything bad about Unix. Perhaps some
of you newcomers don't think it ever happens. Believe me,
it does. In fact, its going to happen to the next person
who breaks the rules.
(WW is lucky. His totally non-Unix-Hating message arrived
as I was composing this one, so I'm not going to flush him.)
Just to show how arbitrary I am, and thus how dangerous it
is to mess with me, I -not- going to say anything bad about
Unix in this mesage.
From: FM
Date: Wed, 20 Nov 91 04:51:36 est
This is your brain: This is your brain on UNIX:
/~~~~~\ (~) (~)
( { & } ) (~) \~ (~)_(~) ~/ (~)
( { } ) ~\ \ ~ | ~ / /~
( O ) (~)_____\___\____|____/___/_____(~)
~\ \~ ~ \ /\ | /\ / ~
\ \ (~)___\/ \__|__/ \/___(~)
~ \__| |__/ ~
____| $ |____
/ |_____| \
(~) \ \ (~)
~ \ \ ~
Any questions?
From: AW
Date: Wed, 20 Nov 1991 10:13-0500
Subject: Ground Rules
Hey, don't look at me. I've been careful to apply
scatological adjectives to Unix in every message.
It's true that some of my abuse has been mere unreasoning
invective, but I'm beginning to wonder if that toilet thinly
disguised as an operating system deserves better. Certainly
its supporters are equally unreasoning.
From: WL
Date: Wed, 20 Nov 91 10:16:29 EST
Subject: Re: Once Again, Weenix Unies Reinvent History
In message <
[email protected]> you write:
> Yesterday Rob Pike from Bell Labs gave a talk on the latest and
> greatest successor to unix, called Plan 9. ...
The only reference I know of for "Plan 9" is from the
picture "Plan 9 From Outer Space". I have heard that film
cultists consider this to be one of the worst movies ever
produced in history.
I wonder if we should read any deeper significance into this
'coincidence'.
OBLIGATORY U**X VILIFICATION: Intelligent type-ahead. ITS
had it. TOPS-10 and TOPS-20 had it. VMS has it. RSX,
RSTS, and even CP/M-80 have it!! Guess which vile, obscene,
festering, putrid heap of lame excuses for software doesn't
have it.
From: DC
Date: Wed, 20 Nov 91 17:44:30 -0800
Subject: shut the f__k up
God damn it. There's too much random noise on this list.
It sounds like some pathetic unix snoozegroup.
In the good old days, mailing lists came in two flavors.
There were real mailing lists, whose members used real
machines on the arpa net, and there were weenie mailing
lists, whose members used unix machines on some weenie net.
(This was only the moderately good old days. When *I* was
young, there were only about ten machines in the world that
had mailing lists, and the concept of a mailing list that
went offsite hadn't really been worked out yet. RD has a
lot to answer for.)
Anyway, the point is that people on real mailing lists were
expected to think for ten seconds, before they sent
something, to see if it was mindless blather or something
that other people might want to read. This expectation is
lacking on weenie mailing lists. It's rather like weenie
programming: most unix utilities have n extremely obvious
bugs that could be fixed with ten seconds of thought, but
there is no expectation that anyone will ever do this.
Here in the future the distinction between these two types
of mailing lists has been broken down, and the world is full
of blathering yammerheads. It's much too late in general to
hold the line.
However, THIS MAILING LIST IS AN EXCEPTION.
Unless what you are going to say is non-obvious, funny
enough that people will be unable to avoid laughing out loud
when they read it, and nasty enough to be labelled seriously
offensive, DON'T SEND IT HERE.
Got it?
From: RA
Date: Wed, 20 Nov 91 21:04:18 EST
Subject: Forwarded Without Comment
From: EE
Date: 18 Nov 91 07:17:09 GMT
Subject: Re: Addresses with quoted usernames
Organization: USENET Protocol Police, Western Gateway Division
You can't get E-mail addresses with quotes in 'em through a
UUCP transport mail envelope - quotes are shell
metacharacters, and are therefore a security risk, which is
why they get stripped by sendmail before calling uux, and
why UUXQT will not execute commands with quotes through
UUCP.
Date: Wed, 20 Nov 91 22:44:34 EDT
From: JL
Subject: Vowel Impaired?
Date: Wed, 20 Nov 91 11:50:30 PST
From: AM
Subject: Mail personal trailers of the day
% From: AM
..
% X-Work-Hours: 11pm to 7am - I get lonely, talk me!
% X-Tshirt-Quip: Unix - The Operating System for the Vowel Impaired.
% X-Logical-Sequel: I donated my vowels to Wales, and all I got was this
% X-Logical-Sequel: lousy operating system.
From: AW
Date: Thu, 21 Nov 1991 10:07-0500
Subject: Re: Once Again, Weenix Unies Reinvent History
Date: Wed, 20 Nov 1991 17:04 EST
From: CG
Speaking of U*** history, I decided to look up today
and noticed that on my office wall there is a poster
optimistically titled "The UNIX Evolution".
It gushes "Tenon Intersystems would like to commemorate
the 20th anniversary of UNIX. The simplicity and
elegance which lies at the heart of UNIX is a benchmark
for generations of future systems."
What *kind* of benchmark it doesn't say...
C level.
From: AB
Subject: Unix-Haters Has Been Turned Off
Due to the fact that many of you can't shut you mouths, I
have turned Unix-Haters off. It will return in a few weeks
when you have all had a chance to think. Can't you
pin-brains think anymore?
Maybe you don't know who you are. Or perhaps public
humiliation can get through to you. OK, I just looked
through the archive for messages sent this week, and
extracted the From: field from every message that I thought
was beneath our standards. The results:
From: JL
From: AW
From: RS
From: DH
From: CG
From: RZ
From: MF
From: CK
From: SG
From: WL
From: FM
From: WW
From: WR
From: DM
From: CM
Of the recent flood of messages, the only one that fit -my-
model of what Unix-Haters is all about was the forwarded
message explaining why you can't have quotes in a mail
header. Yes we hate Unix -- but we hate Unix for -reasons-,
damnit! Just foaming at the mouth isn't good enough.
From: CS
Date: Wed, 11 Dec 1991 17:35-0500
Subject: Super-Duper Sigh
People were trying to figure out which remote login programs
they should install on one of the central UNIX servers at
the MIT AI lab. They were trying to evaluate SUPDUP, and
they thought perhaps that it would read the .rhosts file and
maybe "crypt"ed login passwords and sent them across to the
remote login shell for better security. The main system
hacker said he couldn't find the man page for it.
Sigh. So, I informed them:
SUPDUP is the "super duper TELNET" protocol; its main
feature is that is uses a more "intelligent" network
virtual terminal model. SUPDUP does not include any
provisions for passwords. It does not read the .rhosts
file.
I pointed them at the RFCs, and also mentioned that they
could also just ask RMS about SUPDUP, but that I wouldn't
recommend bothering him about the password stuff too much.
Heh heh.
Well, anyway, one of the other system hackers wrote back to
me. Here's his entire message; apparently this all he
understood about virtual terminal support:
I'd call it a misfeature... it doesn't do a particularly
good job; in particular, it breaks "vi".
I suppose I should have known better, but I wrote him back
one sentence suggesting that UNIX was what was in fact
broken. Here is his reply.
Well, one can argue this until one is blue in the face.
However, supdup is just about the only terminal type
that I have ever had problems with.
In my experience, generic terminal emulations by the OS
give noticeably poorer performance and are noticeably
more buggy than the termcap/curses approach taken by
UNIX.
In short, I dislike supdup because it doesn't work
reliably, not because I think generic terminals wouldn't
be nice if someone got them to work properly.
I remember when, at that very same lab.... oh, never mind.
It's hopeless.
Sigh.
Date: Thu, 12 Dec 91 2:20:09 PST
From: KH
Subject: Re: Super-Duper Sigh
Foo!
My recollection is that termcap was specifically designed to
support vi in the first place, and as a result is full of
incredible cruft that no other program in the world needs,
wants, or cares about. It isn't too surprising that vi
might choke when deprived of its favorite magic cookies.
So much for off-the-wall flaming; here's a first-person
account. When I wrote ELLE (which I'm using to compose this
message, by the way), I first tried to do the "unix thing"
by using termcap. What a buggy crock. Basically I never
found any terminal type that I couldn't support better
myself, and at least one never did work with termcap at all,
there being no way to describe the correct timings. If I
see any more termcap-winnage whinage I'm going to be
violently ill.
KH (co-hacker of CRTSTY with EAK & CBF...)
From: DB
Date: Thu, 12 Dec 91 08:44:03 -0500
Subject: Re: Super-Duper Sigh
I'd call it a misfeature... it doesn't do a
particularly good job; in particular, it breaks
"vi".
Vi doesn't need supdup to break it, it starts out broken.
It sends a newline in order to move the cursor down one
line. Well everyone knows that newline is really linefeed
so this should work, right? Piece of shite operating
system. I stopped trying to improve supdup on Unix at that
point. It worked with emacs and I didn't want that other
thing anyway.
Speaking of supdup, a while back the people at the IETF
(that fine organization that brings you new Internet
protocols) started talking about adding some sort of local
editing protocol to telnet to reduce network delay and host
load. So I suggested the supdup local editing protocol as a
good start (and even a good finish). I was quickly told
that no, supdup was too complicated. At least someone knew
what supdup was. A draft came out a few months later. Gee,
looked like they'd read the Unix TTY man page and written a
network spec about it. Funny how this keeps happening.
Hardly less complicated than the supdup local editing
protocol, this new spec just left out the flexibility. But
what the hey, all the worlds running unix anyway so why
would anyone want to be able to look like something else?
Feh.
From: DH
Date: Thu, 12 Dec 91 06:22:05 PST
Subject: Re: Super-Duper Sigh
Date: Thu, 12 Dec 91 08:44:03 -0500
From: DB
Gee, looked like they'd read the Unix TTY man page and
written a network spec about it. Funny how this keeps
happening.
To be fair, SUPDUP's option words bear a remarkable
similarity to ITS's tty status words. However flexibility
and power were essential features of ITS -- pretty
surprising given the way it was developed.
Hardly less complicated than the supdup local editing
protocol, this new spec just left out the flexibility.
You've described the dao of unix: crazy, inflexible options.
Remember, if it were more flexible, hackers could get work
done instead of continually re-implementing crucial
functionality in new and incompatible ways.
I guess the Ultimate Unix Workstation will have a mouse,
bit-mapped display, 8.5 million transistors (none hooked up
to anything) and no power supply.
From: AB
Date: Fri, 13 Dec 91 00:22:30 EST
Subject: Awww... Shoot
This must be an old one, but it just happened to me and I'm
still pissed off. I typed:
cp -p *.c
Now I -intended- to specify a directory for putting those
files into:
cp -p *.c old
but I forgot. Unfortunately, there were exactly two .c
files in the directory, so cp was perfectly happy to
overwrite the second file with the contents of the first
file. Why wasn't I warned that I was about to clobber my
file? Because I didn't use "cp -i".
An exercise for the reader: Read the man page for cp and
make a list of the violations of human engineering and
software engineering principles.
From: SG
Date: Wed, 18 Dec 91 09:18:26 EST
Subject: The Ultimate Unix Keyboard
Has anyone besides me noticed that Unix workstation keyboard
design is going backwards? In particular, Sun's latest
keyboard, the Type-4, is a step backwards from the previous
design, the Type-3. Give me the old keyboard of an MIT Lisp
Machine any day.
It makes me so mad; I have to use this abomination every
day. I'm getting so fed up I could just...fix it!
And so I came up with...
A modest Sun keyboard proposal
SG
December 1991
Layout:
+------------------------------------------+
| |
| |
| +----+ +---+ |
| | | | | |
| | L1 | | a | |
| | | | | |
| +----+ +---+ |
| |
| |
+------------------------------------------+
Features:
o Compact layout good for laptops
o Key placement easier to remember than Qwerty or Dvorak
o Side-by-side arrangement won't strain the fingers when
typing oft-used chords
Rationale:
I thought for a long time about offering two "L1" keys, one
on each side of the keyboard, to aid left-handers such as
myself. However, I finally decided that would add
unnecessary complexity to what is otherwise a streamlined
design. Also, it might be semanticly confusing, since the
"L" seems to stand for "Left."
As you can see, I've thought a lot about this design, and I
think it has all the features one needs when using a Sun.
Interested parties should contact me about licensing
arrangements.
From: SS
Date: Mon, 23 Dec 91 17:16:46 EST
Subject: Cross Purposes
from "Does Crossing King Kong and Road Runner get you Univel?"
by Ed Foster, editor, InfoWorld
(concerning Univel, the Novell/Unix System Labs joint
venture announced last week)
"Unix in this day and age is a lot like a giant ape
running around Manhattan, because we're either going to
have to learn to live with it being a dominant part of
our lives, or we're going to have to find a way to kill
it."
From: AR
Date: Sat, 04 Jan 92 21:45:36 EST
Subject: [Daily Clean-Ups]
From the annals of true life unix maintenance... Names have
been removed to protect the guilty.
I located the following two problems (may be
related) that were hogging <some.broken.unix.box>
cpu time:
1) For some reasons, /etc/sa (from crontab) had not
been working for some time. /usr/adm/acct grew
monstrously:
-rw-r--r-- 1 root system 168637912 Jan 2 17:54 acct
All attempts to process the info in acct dumped
core so I made a copy of it in /bigtmp and emptied
the file. /etc/sa is now back to working as
normal.
2) Long, abnormal file names of "Macintosh style"
broke the daily-cleanup script (run from crontab).
For example, the gory:
/bigtmp/ar/Music Backup/Music/People's Files/Romero/Grid/.resource
Obviously Unix can't cope with such a naming
system without some "protective wrapping" system.
We need to take this into account if we continue
to serve "Mc Files" from <some.broken.unix.box>.
Guess I have re-write the daily-cleanup script (in
perl?) but for now I've commented out the troubled
commands.
The load on <some.broken.unix.box> is now back to
approximately 2.
Happy new year.
From: NC
Date: Sun, 5 Jan 92 20:36:34 EST
Subject: Cryptic Communications
No, I *don't* want to know what this means, and
please don't gum up the mailng list with explanations, but I
just thought this was a nice piece of wierdness to pass
along. This is the entire object I got back (less some
Received-From: lines). I mean, clearly something has gone
wrong, but it's clear I don't want to know! Ah, Unix......
--------
Date: Sun, 5 Jan 92 14:40:47 CST
From:
[email protected] (UNIX-to-UNIX Copy)
Message-Id: <
[email protected]>
Apparently-To:
[email protected]
uuxqt cmd (rmaild
[email protected] [email protected]) status (signal 0, exit 67)
From: BB
Date: Sun, 5 Jan 92 18:35:36 PST
Subject: Useful Unix Error Message (Not!)
We have two SUN machines side-by-side and networked to share
a file system: a SUN-3 and a SUN-4. Some users prefer one,
some prefer the other. I compiled a program on the SUN-4,
incanted the magic saying to change its protection to
-rwx--x--x, and told people how to use it. Soon I got a
rash of mail messages saying "I tried to run your program
but I got the error message 'read permission denied'".
"Huh?" I said (momentarily forgetting that I was dealing
with the dreaded UNIX), "they have execute permission. What
more can UNIX want?" So I delved into the problem...
[details omitted, suffice it to say that it was ugly] ...and
it turned out that when you execute an execute-only SUN-4
executable on a SUN-3, the error message is not the useful
and expected 'cannot execute a SUN-4 executable on a SUN-3'.
No, goodness, no. The error is 'read permission denied'.
Sigh.
From: MC
Date: Tue, 7 Jan 92 6:34:02 EST
Subject: sed, Portability, and Lunix
If there's one language that comes to mind when I think of
"portable", it's sed. (Maybe ed, too, but that's not the
point.)
Or is it?
[Sun sed, derived from AT&T; same as most other machines]
sure@lock 137% sed -n -e n qux
sure@lock 138% sed -e n qux
line 1
line 2
line 3
line 4
sure@lock 139%
Now just where in TFM is it documented that 'n' doesn't
print the pattern space if you use '-n'? It's not. In
fact, it looks like *nobody* has ever documented this little
feature. That's just as well, since it doesn't make any
sense. It looks like Bourne shell isn't the only thing AT&T
fouled up.
[GNU sed]
sure@buddy 138% sed -n -e n qux
line 1
line 3
sure@buddy 139% sed -e n qux
line 1
line 2
line 3
line 4
sure@buddy 140%
IMHO, GNU sed got it right, but I'll never convince the
world of that, and (primarily because) it makes my sed code
non-portable. <sigh>
Another day, another (mis)feature.
From: DM
Date: Thu, 09 Jan 92 11:16:54 EST
Subject: This Message Is To The Wrong Mailing List
[Forwarded from HA at TLA via DW and JO]
I see (from reading this august list) that Sun has chosen
the name "Solaris" for their new opeating system.
In Stanislaw Lem's novel of the same name, Solaris was an
alien planet/intelligence that human explorers found to be
utterly incomprehensible and psychologically devastating.
Encounters with Solaris drove them to madness and death.
I'm glad that someone at Sun is finally getting it right.
From: RM
Date: Thu, 9 Jan 1992 23:41:00 PST
Subject: From The People Who Brought You Tabs At The Start Of Makefile Lines
From: ld
Newsgroups: comp.lang.c++
Subject: Re: Template question
Date: 16 Dec 91 22:49:39 GMT
> But could we do something like this:
> array<list<int>> question;
Yes, something *like* that, but not with the text the way
you've written it. You see, you've used a right-shift
operator ">>" token, and you'll get a syntax error on that
line. But to answer your substantive question, the
"something like this" would be
array<list<int> > question;
Note the space separating the two ">" characters.
For this reason (IMHO), it would probably be a good C++
style rule to put spaces inside the <> angle brackets in
template class names, at least whenever the enclosed thing
is more than a single token. Like:
array< list<int> > question;
From: SL
Date: Fri, 10 Jan 92 16:57 PST
Subject: Squeaky Wheels, EMACS, And The Work Of The Devil
A friend suggested that this list might prove an
appreciative audience for the following.
The following is an *actual letter* sent to me by an *actual
employee* of an *actual company*. Only the names have been
changed to protect the petulant -- er -- innocent. I think
it says something about the business world, the times we
live in, and maybe even text editors. Feel free to pass it
along.
----------------------------------
From:
[email protected] (Joe Employee)
To: Toto, Spot, Rover, Rin, sol
Subject: EEEEEEEEEEMACS
Well, the fascisti have struck again.
I asked *one* puny question about a problem with emacs, and
the Corporate Ditchpig Head Butt-Boy of MGABC's (My Generic,
Anonymous Big Company) Computer Services Center had a shite
fit.
He didn't come down on me.
He didn't go to my manager.
He went to my MANAGER's MANAGER. The head of the division.
"Whyyyyy," he asked in is best sarcasm-ridden, petulant
whine,"why do your people need EEEEEEEEmacs?" He simpered
in fear as he said the name, for he knew the power that it
held, a power that he could not bridle. "We already
*support* vi."
Right. "Support" vi.
Well, the long and short of it is that my emacs access has
been cut off (again). And I'd rather have a thousand paper
cuts on my face than use vi.
So Toto, would you kindly ship me another version of
Microemacs for People Who Want an Intelligent Alternative to
The Scourge of Vi But Don't Need Any Lisp or Fortrud
Meta-Shells? I would be one-quarter-eternally grateful.
People, vi is from HELL. It was invented by SATAN. He
designed it to turn our brains to chocolate fondue sauce and
render our thumbs un-opposable. It induces retroevolution.
It is Anti-Elvis. It is Anti-Don. Vi users: REPENT while
ye still have souls!
-Joe the Emacsevangelist
From: SS
Date: Fri, 10 Jan 92 20:18:52 EST
Subject: If No Viruses Are Handy, Just Install A Clean Unix.
Date: Fri, 10 Jan 92 13:54:36 PST
From: CJ
Subject: Errant `timed' Wreaks Havoc
We had an interesting experience this morning with `timed'
(a unix Network time daemon). A vendor brought a
demonstration machine to a first-time unix user, who let the
vendor install it and boot it while it was connected to our
network. The machine had a `timed' set up as a master.
When the vendor booted the machine, he did not set the time.
So, the first time one of our other machines on the net
asked for the time, this machine responded. Soon all of our
machines thought that the date was 1/1/1970. When this was
first noticed, our SysAdmins found the errant machine and
shut it down. Unfortunately, the story doesn't end here.
It seems that there was also a bug in our 'real' `timed'
software, such that any date with more than 1 digit in the
day is not handled correctly. So, the date went from 1/1/70
to 10/10/92 instantly. This caused further havoc with
things like 'at' and all sorts of other unix utilities.
We're still picking up the pieces of our database (which
tracks things like work orders and trouble tickets, some of
which now have ages of 20+ years!).
Needless to say, we're working on a `reasonableness' check
for `timed', as well as (more) controls on what gets put on
our network!
From: SS
Date: Fri, 10 Jan 92 20:24:46 EST
Subject: Nothing Wrong With Unix That A Good DOS Virus Won't Cure;
OR; Another Interoperability Miracle Of "Open Systems"
Date: Fri, 10 Jan 92 09:40:56 MST
From: BG
Subject: PC Virus Infects UNIX System
We were configuring the ethernet card on our new 486 UNIX
(SVR5) box when we determined that we needed to boot and run
DOS to run the ethernet configuration program. (Or possibly
the EISA configuration -- this happened in my office but I
was not involved).
No problem: simply create a boot disk from the DOS system
across the hall and reboot DOS.
Unfortunately, that system had been infected with the
'Stoned' virus. This virus overwrote the UNIX BOOT TRACK
when the infected DOS was booted.
Result -- no more SVR5. We will probably have to perform a
low-level format of the disk and rebuild the UNIX from
original media.
Morals: 1) don't ignore DOS viruses simply because you run
UNIX unless you NEVER need to use DOS. 2) Pound on DOS
users to note and report strange behavior because some
infections are very costly (several person-days to rebuild
this system -- at least it was new and had no
work-in-progress on it!)
Date: Mon, 13 Jan 1992 11:05-0500
From: TK
Subject: sed, portability, and Lunix
Know what? I don't have the foggiest idea what ANY of this
message is about. And damn proud of it, too... Don't you
dare try to `educate' me about it.
Date: Tue, 7 Jan 1992 06:34 EST
From: MC
If there's one language that comes to mind when I think
of "portable", it's sed. (Maybe ed, too, but that's
not the point.)
Or is it?
[Sun sed, derived from AT&T; same as most other machines]
sure@lock 137% sed -n -e n qux
sure@lock 138% sed -e n qux
line 1
line 2
line 3
line 4
sure@lock 139%
Now just where in TFM is it documented that 'n' doesn't
print the pattern space if you use '-n'? It's not. In
fact, it looks like *nobody* has ever documented this
little feature. That's just as well, since it doesn't
make any sense. It looks like Bourne shell isn't the
only thing AT&T fouled up.
Isn't it easier to enumerate the things they did get right
rather than the ones they got wrong? Let's see. I was
going to say using ascii instead of ebcdic, but I realize
now that doesn't quite work...
[GNU sed]
sure@buddy 138% sed -n -e n qux
line 1
line 3
sure@buddy 139% sed -e n qux
line 1
line 2
line 3
line 4
sure@buddy 140%
IMHO, GNU sed got it right, but I'll never convince the
world of that, and (primarily because) it makes my sed
code non-portable. <sigh>
Only less wrong, probably, but who wants to spend the time
to find out.
Another day, another (mis)feature.
Got that right.
From: AB
Date: Tue, 14 Jan 92 18:53:32 EST
Subject: xdvi
From: TB
Date: Tue, 14 Jan 92 18:18:24 EST
| From: TB
| Date: Tue, 14 Jan 92 16:43:53 EST
|
| The new xdvi performs anti aliasing on a grey-level
| display. I don't know what kind of display you are
| using, but on a color Sparc the output is much better
| than that of the previous monochrome version. Of
| course, drawing characters in color takes a little
| longer than in B/W.
|
|
|Actually my display is a (logical) color display
|attached to a microvax II. But even given how slow a
|microvax can be, this is slooooooww. Pop down to 501
|and I'll show you. The output is also totally
|unreadable.
Give it a try on a SparcStation sometime. Everybody who
saw the anti-aliased fonts on my screen really liked
them; that's why I made it the default. Anti-aliased
text on a SparcStation takes about twice as long (3
seconds vs. 1.5 seconds for a full page), but given the
very much superior output, that seems worth it.
Thomas.
The old version takes about 4 seconds to display a page on
my display. The new version takes about 25 seconds. And
you cannot read the result. And magnification doesn't work
at all. I'm sure it works great on a Sparc. I'll bet that
the guy who wrote it was using a Sparc, that's why he never
saw these bugs.
But that's OK, as long as I know where the binary for the
old version can be found, I can protect myself from this
latest degradation in the environment. Just another
instance of running as hard as I can to stay in the same
place.
(Oh yeah, did I mention that the "man page" no longer
describes the installed program?)
From: DH
Date: Tue, 14 Jan 92 22:18:34 EST
Subject: xdvi
Date: Tue, 14 Jan 92 18:53:32 EST
From: AB
(Oh yeah, did I mention that the "man page" no longer
describes the installed program?)
I assume this is an upgrade to be compatible with the rest
of unix.
info.
From: AB
Date: Fri, 24 Jan 92 16:38:51 EST
Subject: Egregious Lossage
X-Face: 1U^CJbV"U?.%q2h~<LW(U5nq!Z,NMQsAk8TH7m}zgWE|.l@HZG&")#=^W*/RtN(!`sVOzor
Z)D1U4W0%/>b&LD~<F^@r0%_6poYzeAh_9L\4S8V{~%Tsz|/fxeNS>jB4ZVGwop'|zORg&@""*kUJP
<y>pESV5No`.e3}Nh&fbr-FH/}r&A&3eAZqU0S8t$eEmV`MYtWyQ#],&BL!]^#>Qm%bH$;@@auKPlf
:hT{bTyyA&f3Ur27@"e5qx]Oj,H6ZfDup`%\emZ_$T/(]hUAHs/C,4TlSE"n.}&g*mh}6C6D+~
Date: Fri, 24 Jan 92 06:32:06 PST
From: DH
Subject: Egregious Lossage
Not an error of implementation, but one of judgement.
X-Face: &9PF|E~LVh;7SEjvuS(PqtuULpt<`L#k{8(^H>%"ALgKNBK
s()KGD9fR{X`g_f_k.`;85Q4V{X%K9D}<:r9-WX#Cv=FN]Ur^/KqLC
{A-r+cPO{Ta1-Y'GBp,a`wA"{*da:]-0PjqK)E1-DE*W[d<1"dUKZ{
*g+J!:Lv]ufKgBqQ|}iF5L;2>#_k8q/nyeYd{JO%6=#<bM\t7gdx&Y
D+bDeOk|3<J|Yl'):p%z~z@+i^905oE1/R9Cc7\/sTlxAHdX%C=@)\
6F\)T%}bptBrqb`9Z|-n07(hu~K6Bnxf_f.qI5V6W4yjR.m(
To:
[email protected]
From: LI
Date: Tue, 21 Jan 92 08:09:15 -0500
Subject: Bug Reports And Fixes.
Hey man, you don't know about the "faces" program do you?
Its kind of a replacement for "xbiff". If you had been
running the right software, you would have gotten a little
picture of my face on your screen when this message arrived
in your inbox.
Its kind of cute, but I stopped using myself it when it
tickled some memory leak bug in the Unix kernel on the
machine running my X server that made me have to reboot the
machine about once a day. (Sure does boot fast...)
From: KP
Date: Sat, 25 Jan 1992 15:23-0500
Subject: Egregious Lossage
Date: Fri, 24 Jan 1992 16:38 EST
From: AB
... it tickled some memory leak bug in the Unix kernel on the
machine running my X server that made me have to reboot the
machine about once a day. (Sure does boot fast...)
Careful, Mr. Moderator. Don't you realize that you came
only a few proof steps from violating the Prime Unix-Haters
Directive? Consider:
1. Good design must be measured against the goals of a system.
2. Computer systems should optimize the expected needs of
their users.
3. "Unix boots fast."
...
Only a little farther and you'd have been concluding all
questionable things about the goodness or badness of Unix's
design. You've done such a good job as moderator so far; it
would be a shame to have to ask you to step down.
From: MF
Date: Mon, 27 Jan 92 16:12:57 -0500
Subject: The Horror. The Horror.
The following net discussion gave me a little case of the
titters, though I'm not sure exactly why. I think that it
has to do with the way it combines the typical unix "nice
try, but not quite right" feature with a classic unix fixed
size something or other, along with a wonderful totally
incomprehensible workaround which references a typical unix
ad hoc language (which itself is totally incomprehensible)!
Background:
Unix shells have a feature whereby they allow shell scripts
(i.e. what some might call programs) to specify which
executable (i.e. interpreter) to use on that script. The
mechanism requires the use of the magic string "#!" as the
first two characters of the script.
Story:
Some guy on some net group says:
I've got some perl scripts that have #! lines like this:
#!/usr/local/bin/perl -- # -*- Perl -*-
or
#!/usr/bin/perl -- # -*- Perl -*-
The system tried to run /bin/sh on it instead of
perl. I've heard of there being a length limit on the #!
lines, but would that cause the line to be ignored? What
would the limit be? Seems to me it should be a bug.
Some other guy responds:
From "Programming Perl", by Larry Wall and Randal
L. Schwartz (page 5, footnote):
quotes on
Note that many versions of UNIX will not allow an
interpreter name to be longer than 32 characters. If
^^
your Perl pathname is longer than that (as it is in some
instances of the Andrew File System), and if for some
reason you can't get around that fact administratively,
say this (including the comment):
#!/bin/sh -- # A comment mentioning perl, to prevent looping.
eval '/your/long/path/name/leading/to/perl -S $0 ${1+"$@"}'
if 0;
quotes off
Love that "if 0;".
From: DM
Date: Mon, 27 Jan 92 16:22:12 EST
Subject: Re: Egregious Lossage
> Date: Sat, 25 Jan 1992 15:23-0500
> From: KP
>
>
> Careful, Mr. Moderator.
> 3. "Unix boots fast."
I guess you haven't had the pleasure of booting a Unix
recently. I admit it boots faster than an AppleShare File
Server, but I can't think of anything else that is as slow
to boot as the last Unix I booted.
From: NC
Date: Wed, 29 Jan 92 12:46:13 -0500
Subject: Another Noteworthy Sig
C++ will do for C what Algol-68 did for Algol!
From: JW
Date: Thu, 30 Jan 92 23:52:08 -0500
Subject: Truth In Advertising
Well, I'll be damned. Truth in advertising from Sun...
From: [A Sun employee. Heck, why screw the guy..]
Date: 27 Jan 92 xx:xx:xx
Organization: Sun Microsystems, Inc. Mt. View, Ca.
... Look, Sun has been successful at doing 20% of the
work for the 80% solution. ...
(Taken perhaps a little bit out of context, yes, but what do
you expect. It's unix-haters, right?)
From: NZ
Date: Thu, 6 Feb 92 15:27 EST
Subject: Re: Case Sensitivity
In a discussion on common-lisp regarding the advisability of
having case-sensitive programming languages, JS says:
> If you're using a consistent casing convention (rather
> like C, where all-cap names tend to be macros or
> constants), it's not too bad.
This is another example of the C-and-un*x-oid tendency to
utilize lexicographic conventions to make semantic
distinctions, because the rest of the system is so broken
that there isn't any other way to make them.
Want to make a file invisible? Change its name ...
Bitterly,
NZ
From: OS
Date: Sun, 9 Feb 92 18:46:43 hkt
Subject: Death, Taxes and Unix
Some evil bits of software can just be killed. With Unix,
the only way to be sure is to hold it down and drive a stake
through its heart.
Quoted from _Unix World_, November, 1989:
"The grim reality is that every life ends with a
death. Funeral homes exist to make that fact a little more
tolerable. ... UNIX can help here, too. The Gordon Funeral
Chapel, for instance, does much of its accounting on an AT
class, multiuser machine running XENIX. ...
... For example, Gordon says his system has to be able to
classify two kinds of customer, "at-need," those who are
actually deceased, and "pre-need," those who have made
arrangements for funerals while still living. Moreover,
the system has to be able to convert one kind of customer
to the other as the need arises...."
Date: Mon, 10 Feb 92 00:41:52 EST
From: SG
Subject: Loki Is Impossible To Understand
From a recent discussion. SIPB is changing over some of its
accounts from SIPB accounts to SIPBMEM accounts. There is
supposed to be an easy way to find out what kind of account
you have and request a change. Okay, I'll bite...
Begin forwarded message:
Date: Sun, 9 Feb 92 22:48:54 EST
From: SG
Subject: loki is impossible to understand
Okay. Just run the command get_user_by_login. No problem:
charon. get_user_by_login
get_user_by_login: Command not found.
charon. man -k get_user_by_login
get_user_by_login: nothing appropriate
charon.
Okay. Now what do I do? I've got to attach
something-or-other, right?
But what?
Is any of this documented in an easy-to-find place? Or do
you have to know where it is documented in order to read the
documentation?
How about this:
I type moria and end up in a nice menu:
Moira Database Manipulation
1. (cluster) Cluster Menu.
2. (filesys) Filesystem Menu.
3. (list) Lists and Group Menu.
4. (machine) Machine Menu.
5. (nfs) NFS Physical Menu.
6. (user) User Menu.
7. (printcap) Printcap Printer Menu.
8. (palladium) Palladium Printer Menu.
9. (dcm) DCM Menu.
10. (misc) Miscellaneous Menu.
t. (toggle) Toggle logging on and off.
q. (quit) Quit.
Command: get_user_by_login
Command not recognized
Command:
Well, that didn't work. What now? Ah, option 6:
User Menu
1. (login) Show user information by login name.
2. (name) Show user information by name.
3. (class) Show names of users in a given class.
4. (modify) Change all user fields.
5. (adduser) Add a new user to the database.
6. (register) Register a user.
7. (deactivate) Deactivate user.
8. (expunge) Expunge user.
9. (pobox) Post Office Box Menu.
10. (quota) Quota Menu.
11. (krbmap) User Kerberos Mappings.
r. (return) Return to previous menu.
t. (toggle) Toggle logging on and off.
q. (quit) Quit.
Command: 1
Show user information by login name
Desired login name: sg
Login name: sg Full name: G,S
User id: 237 Login shell /bin/csh Class: SIPB
Account is: Active (1) Encrypted MIT ID number:
Last Modification by someguy at 13-nov-1989 19:21:14 with moira.
Command:
Well, that didn't tell me anything I didn't know. Gee, it
would be nice to be able to find out what group I'm in....
How about option 3?
Command: 3
Show names of users in a given class
Desired class: sipbmem
moira: Insufficient permission to perform requested database
access when attemp ting to get_user_by_class.
Command:
Nope. Wrong.
The thing I love about Loki is that it is so easy to use.
Except when you don't know how to use it.
Any other ideas?
I finally just ended up sending mail to accounts asking them
to change my SIPB account to a SIPBMEM account. Hope that
was the right thing to do.
From: MR
Date: Mon, 10 Feb 92 11:56:46 -0500
Subject: Fun With cpp
I was doing a little computer graphics animation. It was to
be a potato masher going up and down, casting pretty shadows
on a table. The rendering system I was using is "nice"
enough to run cpp on the file to give users the ability to
#define and what not. So, I figured that I would do
something like this:
----
#include "object_geometry"
#if FRAME==00000
translate 0 20 0
#endif
#if FRAME==00001
translate 0 19.8 0
#endif
#if FRAME==00002
translate 0 19.6 0
#endif
.
.
.
#if FRAME==00100
translate 0 0 0
#endif
----
And I hacked the renderer code to throw cpp the proper
"-DFRAME=%05d" to spit out numbers the way I wanted
them. Why did I want the leading zeros? I don't know, I just
thought it was cleaner.
So I fired up the animation and let it run for a while
(days).
Well, the output was quite amusing (or at least it would
have been if I didn't need the results for my thesis defense
a week later). The object would go down for a few frames,
then jump up and go down a little, then go back to where it
maybe should have been, then jump up....
After a little headscratching, I realized that the leading
zeros in my frame numbers were causing cpp to treat them as
octal values. How precious.
But still, if I say "#define FRAME 00009" then "#if
FRAME==00009" should still fire (or it should at least whine
at me). Well, 00009==00009 does trigger, but so does
00009==00011.
Huh?
Well, some C library thinks that the nine in 00009 isn't
octal, so it interprets it as 9 decimal. And 00011 is a fine
octal rep of 9 decimal. So, both "#if FRAME==00009" and
"#if FRAME==00011" fired and I applied two translate calls
to my object geometry. And(!), it's not that having a
decimal digit makes the whole number decimal. The string
00019 gets interpreted as 00010 octal plus 9 decimal = 17
decimal. Lovely, not.
From: RM
Date: Mon, 10 Feb 1992 10:48:21 PST
Subject: Re: fun with cpp
You forgot to put -*- Base: 10 -*- in the mode-line.
From: DH
Date: Mon, 10 Feb 92 14:26:43 EST
Subject: Fun With cpp
Date: Mon, 10 Feb 92 11:56:46 -0500
From: MR
#if FRAME==00000
translate 0 20 0
#endif
#if FRAME==00001
translate 0 19.8 0
#endif
#if FRAME==00002
translate 0 19.6 0
#endif
.
.
.
#if FRAME==00100
translate 0 0 0
#endif
Too bad C doesn't come with macros; must have been fun
writing 100 of these.
From: Frank Yellin <fy%
[email protected]>
Date: Mon, 10 Feb 92 12:56:25 PST
Subject: bc Follies
The following was brought to my attention by VP.
Try using bc to calculate the value of 163/ln(163)
Here's a Sun4:
titanic:~[13] bc -l
163/l(163)
32.0-75570-60420-20649243140-49
Here's a DecStation:
hindenburg:~[1] bc -l
163/l(163)
32.0-85189980504841560572
From: LK
Date: Mon, 10 Feb 1992 19:22:13 PST
Subject: Re: bc Follies
In 1984 I was working on Logo for the Mac, cross-compiled
from a Unix box with the hacked PCC from Sumex. The
assembler on the Unix box started barfing on an illegal
instruction, and I feared the worst. The line was something
like
and R0, 7&F&3C@03^3
Eventually, I tracked it down to the fragment
p & FOO_FLAG
where FOO_FLAG was defined to be 0x80000000.
Deciding to find out what 0x80000000 was in decimal, I
turned to Logo running on the Mac, and typed
PRINT 8 * 65536 * 65536
and it responded
7&F&3C@03^3
Yes, the bug was in the "itoa" routine in the PCC runtime,
the basis for the Sumex compiler and also the Unix box
compiler that the Sumex compiler was compiled in...
From: RS
Date: Wed, 12 Feb 92 22:19:57 EST
Subject: Eat Flaming Death, Evil BSD-Vending Scum
I've just been advised that BSDI, who sells Berkeley Unix
for Intel architecture machines (now *there's* a match made
in purgatory) has a WATS number - 1-800-ITS-UNIX. I've
tried for several minutes to think of an appropriate
response to such an outrageous insult to ITS, but haven't
been able to. Perhaps a collective response is called for?
From: KP
Date: Thu, 13 Feb 1992 07:54-0500
Subject: Re: Eat Flaming Death, Evil BSD-Vending Scum
Date: Wed, 12 Feb 1992 22:19 EST
From: RS
I've just been advised that BSDI, who sells Berkeley
Unix for Intel architecture machines (now *there's* a
match made in purgatory) has a WATS number -
1-800-ITS-UNIX. I've tried for several minutes to
think of an appropriate response to such an outrageous
insult to ITS, but haven't been able to. Perhaps a
collective response is called for?
ITS-Unix? Certainly sounds like an uxymoron to me...
From: WW
Date: Thu, 13 Feb 92 11:47:52 PST
Subject: Re: eat flaming death, evil BSD-vending scum
ITS-Unix? Certainly sounds like an uxymoron to me...
I don't see how you can get much more of of an "incompatible
timesharing system" than unix. One would think that at
least the applications would be pretty compatible, but
NOOOO... We got bitten when we discovered that the bsd m4
didn't support multi-character quoting "characters". No
mention that this was a system-V specific feature in any man
pages, either. Sigh.
Of course, I guess you could argue that unix is not a
time-sharing system, given the poor performance of most
modern unix boxes when faced with large numbers of users...
Modern unix wasn't designed to be shared...
(Properly vitrolic this time?)
From: MS
Date: Fri, 14 Feb 92 14:31:07 EST
Subject: RE: /dev/null (fwd) -- query and reply from sun-managers list
Date: Wed, 12 Feb 92 19:35:36 EST
From: f
To:
[email protected]
Subject: RE: /dev/null
On 2/10/92, you allegedly write:
> From: Hacker
> Subject: /dev/null full
> Our sun sparc 1+ SunOS 4.1 OW2.0 started running very
> slowly. When I logged out I got the message /dev/null
> full: empty bit bucket.
> What does this mean? It seems to be running fine after a
> reboot but I am wondering if only the sympton is cured.
The problem is that null is full. Your void space is no
longer void, it's full up.
THE TOP TEN WAYS TO EMPTY AN OVERFLOWING BIT BUCKET:
10) Open the computer up. Look for the bit bucket, find the
RED stopper at the bottom of it and open it up OVER a
LARGE trashcan.
9) Stop using the computer for 6 months, let the bits
compost and continue.
8) Take the ethernet terminator off, and "cat /dev/null >
le0". This spits the bits into the ether.
7) When you write to /dev/null, the 0's don't take up any
space, but the one's do. Try writing a file full of 0's
to /dev/null (binary 0, NOT ASCII 0 - ASCII 0 will start
overfilling the partition).
6) This is a common problem _only_ if you use the computer.
If you stop using it, it won't have many problems as
all. Kick the other users off too.
5) If you use lots of C programs, they have Null terminated
strings that use up the bits in /dev/null.
4) Bring the computer to Mr. Goodwrench, he will drain the
bit bucket, change the oil and add windshield fluid, all
in less than 29 minutes. Now that's a deal.
3) Consider upgrading to a byte bucket or even a word bucket.
2) Since your already using Open Windows, open a window and
toss the useless bits out the open window.
1) Stop using the game "fortune" in your .logout script, Mr
"Hacker".
From: JW
Date: Thu, 20 Feb 92 04:58:11 -0500
Subject: Today's ".signature"
Found reading newnews:
"One of the main advantages of Unix over, say, MVS, is
the tremendous number of features Unix lacks." -- CTorek
"Fixed in SVR4" -- USL
From: AB
Date: Tue, 25 Feb 92 22:30:56 EST
Subject: Who am I?
There's currently a discussion taking place on the system
hackers mailing list at the AI Lab about the fact that Unix
provides no documented portable way to find out your own
host name (as a full domain-style name). I've been aware of
this problem for quite some time, but it seems to be news to
them. I wonder if I should bring up the fact that there
isn't a good portable way to get your Internet address
either.
(People who find a way that apparently works under their
version of Unix, and are tempted to reply to this message
with a "correction", should remember two things: (1) it
probably works differently under some other version of Unix,
and (2) this is Unix-Haters, so neatness doesn't count.)
From: PB
Date: Wed, 26 Feb 92 04:08:54 EST
Subject: Re: Who am I?
There's currently a discussion taking place on the
system hackers mailing list at the AI Lab about the
fact that Unix provides no documented portable way to
find out your own host name (as a full domain-style
name).
You speak of 'Un*x' as if was some complete and well formed
entity, particularly when it comes to networking (which was
only glommed on in recent history).
I just loved that what AT*T sold as the "Basic Networking
Utilities" package was UUCP! Basic Networking, yeah right.
For g*ds sake, RFC1 is dated 1969, before Un*x was even
starting taking up disk space.
Funny thing about your subject line is that
who am i | sed 's/\!.*//'
is almost certainly the most portable command line to return
the current hostname!!
From: JW
Date: Wed, 26 Feb 92 04:21:07 -0500
Subject: Re: Who am I?
Date: Tue, 25 Feb 92 22:30:56 EST
From: AB
There's currently a discussion taking place on the
system hackers mailing list at the AI Lab about the fact
that Unix provides no documented portable way to find
out your own host name (as a full domain-style name).
(People who find a way that apparently works under their
version of Unix, and are tempted to reply to this
message with a "correction", should remember two things:
(1) it probably works differently under some other
version of Unix, and (2) this is Unix-Haters, so
neatness doesn't count.)
Aw, shucks. This ain't hard. Y'all just fire up the "uname"
command. Now, I can show ya how it works just fine
everywhere, 'cause I've got "RISC/OS" from Mips, the Unix
that does it all.
Watch:
jtw@mercury>/sysv/usr/bin/uname -a
mercury mercury 5.0-Beta RISCos mips
See, ya just take the first word, there, to get the machine
name. I started with System V, cause I consider it
standard. But you can do the same thing on the new exciting
System V Release 4 from ATT-Sun, cause it's still standard,
so it'll still work!
jtw@mercury>/svr4/usr/bin/uname -a
RISCos mercury 5.0-Beta RISCos mips mips
Er, never mind. We'll go on to BSD.
jtw@mercury>/bsd43/usr/bin/uname
/bsd43/usr/bin/uname: Command not found.
Damn.
But anyway, now that you've got the hostname, you kin use
yer shell string contatenation operator to tie it in with
the domain name, which ya get with the domainname command,
of course. At least -that- works everywhere.
jtw@mercury>/bin/domainname
no_domainname_set
See? It's easy. If y'all need any further advice, just send
me mail. No problem there, I'm right here at
"
[email protected]_domainname_set".
From: TK
Date: Wed, 26 Feb 1992 05:13-0500
Subject: Re: Who am I?
Date: Tue, 25 Feb 1992 22:30 EST
From: AB
... Unix provides no documented portable way to find
out your own host name ... there isn't a good portable
way to get your Internet address either.
Why are you always looking for complicated solutions when we
have ones that work so well already? You could just edit
the file /etc/obscure/mystical/ypkludge/braindeath/hostid on
fully 3.5% of the installed Unix systems and solve your
problem immediately. Well, at least as soon as the daemon
ran in the next hour (unless it's crashed). I think you
might have to reboot, but then again, the crash will
probably autoboot if you do it right... Of course this
simple solution won't update the addresses for the mailer,
but I forget the file to change for that. Let's see. If I
grep the...
From: SG
Date: Wed, 26 Feb 92 07:46:21 EST
Subject: Re: Who am I?
Isn't asking the system manager a reliable, portable way?
And it even has a human-user interface. The wonders of unix!
From: IH
Date: Wed, 26 Feb 92 10:43:16 EST
Subject: Re: Who am I?
You stupid ignorant fools. Don't you know that the
official, blessed was of finding out your hostname in a
portable manner is to use the mailer? It's very simple.
Here it is in the official ASSI C pseudocode:
void crock *getmyhostnamedammit()
}
1. Call mktemp to generate a unique string
2. Spawn a /bin/mail process to spawn a /usr/lib/sendmail process
to mail the string as the subject line of a message to
[email protected] (the machine exists, the login doesn't).
3. Busy wait until the mailer daemon reply containing the unique
string appears in your mailbox. The busy waiting should be
done at a high scheduler priority so as to insure that you
return from getmyhostnamedammit() as fast as possible.
4. Extract the "To:" address in the mailer daemon reply.
5. Spawn a copy of /bin/ed to delete the message from the mail
file.
{
This routine will only very rarely destroy mail due to race
conditions.
This is a good, unix, tool-oriented approach which recycles
software rather than creating new software from scratch
(kind of like that scratchy toilet paper my housemate buys
at the co-op which says "save the forests" all over it).
Remember: Unix(tm) is the environmental operating system.
We should all show that we care for the environment by
writing lots of user programs which generate mail bounces
off of sun.com to determine their hostnames. Then we should
all run them off of cron every minute or two. In fact, we
could even modify the mailer itself to bounce off of sun.com
to determine its hostname. Wouldn't that be spiffy?
From: SS
Date: Wed, 26 Feb 1992 11:51:43 -0500
Subject: Re: Who am I?
>From: PB
>Funny thing about your subject line is that
> who am i | sed 's/\!.*//'
>is almost certainly the most portable command line to
>return the current hostname!!
Not on Apple's A/UX it isn't.
silens@brazil> who am i | sed 's/\!.*//'
silens ttyp1 Feb 26 11:38 (90.223.0.29)
Yes, A/UX, from the company that says "Unix? F__k that, we
can do better, but maybe we'd better license it from AT&T
and change it a real lot and sell it anyway just so we can
get on the federal and corporate `approved-for-purchase'
lists just to be sure."
From: RA
Date: Wed, 26 Feb 92 12:40:35 -0500 (EST)
Subject: Re: Who am I?
AB, this is not a hard question.
All unix machines are named "localhost" and have an IP
address of 127.0.0.1. You can hardwire this into all your
programs with complete assurance. The Internet Assigned
Numbers Authority has blessed Berkeley's appropriation of
network 127.0.0.0, so it must be right.
Now if only the NIC would allocate "localhost" as a
top-level domain, we'd be all set.
From: PB
Date: Wed, 26 Feb 92 11:18:18 MST
Subject: Re: Who am I?
From: IH
Date: Wed, 26 Feb 92 10:43:16 EST
..[description of mail bouncing method of getting host name]..
We should all show that we care for the environment by
writing lots of user programs which generate mail
bounces off of sun.com to determine their hostnames.
Then we should all run them off of cron every minute or
two. In fact, we could even modify the mailer itself to
bounce off of sun.com to determine its hostname.
Wouldn't that be spiffy?
Maybe we should realy go back to the source and use
att.com. ..or is it bellcore.com? Hmm.. That ATT breakup
thing was really a ploy to hide the perpetrators of unix
from us.
From: WW
Date: Wed, 26 Feb 92 13:48:12 PST
Subject: Re: Who am I?
The Internet Assigned Numbers Authority has blessed
Berkeley's appropriation of network 127.0.0.0, so it
must be right.
Thereby wasting 16 million IP addresses. Don't you love
unix?
From: DM
Date: Thu, 27 Feb 92 10:47:08 EST
Subject: Re: Who am I?
Synchronicity strikes: this was in my mailbox this morning:
Date: Thu, 27 Feb 92 03:47:57 -0500
From:
[email protected] (mail deli very sub system)
To:
[email protected]
Subject: Returned mail
--- transcript of session follows ---
While talking to 127.0.0.1
>>> .
<<< 554 sendall: too many hops 24 (23 max): from , to (null)
[the rest deleted]
From: CK
Date: Thu, 27 Feb 1992 11:10:35 PST
Subject: Re: Who am I?
If we're going to lay blame and hate at someone's door for
all this hostname crap, let's lay it where it properly
belongs: Berkeley. 4.1[bc] brought us all this headache;
Sun and USL just refined it.
From: JZ
Date: Thu, 27 Feb 92 16:02:02 PST
Subject: Who Am I again...
Well here's another lovely UNIXism. gethostname() is
supposed to return the "standard (ha!) host name for the
current processor." gethostbyname() returns a structure
describing a host-table entry, of which one of the slots is
the "standard" (ha!) host name.
So you'd think that you could look at a host name and decide
whether it was one of the innumerable representations of the
name of the host you're running on simply by comparing the
results of gethostname() and gethostbyname(), wouldn't you?
F__K NO. They apparently have nothing to do with each
other.
So if you have a program which really needs to behave
differently if it is displaying on the console monitor of
the machine it is running on because of pathetic limitations
of the X protocol, well, you're just shite out of luck,
buddy!
From: CM
Date: Fri, 28 Feb 92 02:52:43 EST
Subject: Re: Who Am I again...
Doesn't gethostname() always return "localhost"?
From: RM
Date: Sat, 29 Feb 1992 17:30:41 PST
Subject: Re: And I Thought It Was The Leap-Year
There must be some problem with the autoboot interface
because normally it is invoked preemptively, helpfully
saving one the trouble of discovering deciphering the
command-line arguments for "reboot". Perhaps I'll just keep
typing for a while... I'm sure some program or NFS daemon
or cron job or sendmail will help me out.
From: JL
Date: Sun, 1 Mar 92 09:38:39 EDT
Subject: Says It Nicely, No?
A signature:
UNIX: too little too soon, too much too late.
- notebooks of a heretic.
From: DW
Date: Mon, 2 Mar 92 09:48:40 EST
Subject: Re: Who Am I Again...
From: CM
Date: Fri, 28 Feb 92 02:52:43 EST
Doesn't gethostname() always return "localhost"?
A friend of mine who is involved in standards committee work
sometimes told me that in the original IEEE 1006.1 POSIX
standard, an implementation would conform to the standard if
the "get current working directory" entrypoint were to
return the constant string ".".
From: JL
Date: Mon, 2 Mar 92 14:24:51 EDT
Subject: Identifying Unix Users
[Forwarding removed:]
>From a posting in comp.periphs.printers from TLA.
--
CM, Grad Student and RetroGrouch
"A unix signature isn't a return address, it's the ASCII
equivalent of a black velvet clown painting. It's a
rectangle of carets surrounding a quote from a literary
giant of weeniedom like Heinlein or Dr. Who."
From: CM
Date: Wed, 4 Mar 92 10:15:56 EST
Subject: No Sympathy
Boy, it really burns my ass when people like Z spend hours
hacking on Echs and then come here whining about how painful
it is. You brought it on yourself, Jack.
It's like if a little kid comes up to you and says, "Gee, I
poured gasoline all over myself and then played in front of
the furnace and now the house burned down."
Or if a dog comes up to you and whimpers, "Gee, I stuck my
nose in a beehive and got stung and then in my frenzy of
pain fell in a pile of shite." Well, you'll get no milkbone
of sympathy from me!
From: AR
Date: Wed, 04 Mar 92 12:49:08 EST
Subject: This Seen In Comp.Programmers
In article some articla (IL) writes:
Hello fellow net-programmers...perhaps someone can
assist me.
I am looking for a program that will "shroud" C source
code. By "shroud", I mean - to make C source code
extremely difficult to read by humans.
I find hilarious the implication that C source code might be
understandable prior to this process.
From: SS
Date: Thu, 5 Mar 1992 15:29:31 -0500
Subject: The Story That Must Be Told
OK. It's time to write The Book.
You know what I'm talking about: The Unix Haters Handbook.
Publishing is not a problem. If TLA Press won't touch it, my
family owns a honest-to-god publishing company. Really.
I'm willing to edit it, and anyone else is welcome to join in.
The rules are identical to the rules for this mailing list.
You can use technical jargon and not bother to explain
it. Apologies or pragmatic suggestions (other than the
canonical choice of avoiding unix or committing suicide)
will not be tolerated.
The chapters will be:
1) The Unix Epidemic
The Abortion that Lived
2) The Shell
Playing Russian Roulette With 6 Bullets In The Chamber
3) The File System
Sure It Corrupts Your Files, But Look How Fast It Is!
4) Mail
Don't Talk To Me, I'm Not A Typewriter
5) Security
Oh, I'm Sorry Sir, Go Ahead, I Didn't Realize You Were Root
6) Programming
Like Performing Rectal Surgery With a Rusty Spoon
7) Unix weenies
It Can't Be a Bug, My Makefile Depends on It
8) The Future of Open Systems
Terminal Cancer Patients Have Choices Too, You Know
If you want to write any of these, or have a new topic to
add, let me know. The first draft should be ready by July
1st, this summer, and we will go to press by November
1st. Oh yeah, we also need to get an artist who's good at
drawing miserable people. There will be at least one
illustration per chapter, preferably more. If you know
someone, let me know.
From: AD
Date: Thu, 5 Mar 92 15:49:46 EST
Subject: Hmm, Not All Unix Hate-Mail In My
Box Comes Addressed To Unix-Haters...
but I guess I can rectify that.....
------------------------------------------------------------------------
From: MT
Hi everyone,
I burst out laughing when I saw the latest issue of The Sun
Observer, which has a front-page article headlined:
McNealy: "Unix is not confusing"
Compare this with:
Nixon: "I am not a crook"
Striking similarities, I'd say!
(In case you didn't know, Scott McNealy is the brash and
out-spoken CEO of Sun Microsystems Computer Company.)
From: DW
Date: Thu, 5 Mar 92 18:53:19 PST
Subject: The Story That Must Be Told
I've thought a lot about such a book. It should have an
introduction by Dvorak and a forward by Pournelle. I have
lots of other ideas, let's talk offline.
From: TM
Date: Thu, 05 Mar 92 19:18:07 -0800
Subject: Re: The Story That Must Be Told
9) UNIX Standards
One standard is not enough
From: LA
Date: Fri, 6 Mar 92 09:59:08 -0500
Subject: How About A Serious Critique Of Unix?
> From: SS
> Subject: the story that must be told
>
> OK. It's time to write The Book.
>
> You know what I'm talking about: The Unix Haters
> Handbook.
>
> I'm willing to edit it, and anyone else is welcome to
> join in.
>
> The rules are identical to the rules for this mailing
> list. You can use technical jargon and not bother to
> explain it. Apologies or pragmatic suggestions (other
> than the canonical choice of avoiding unix or committing
> suicide) will not be tolerated.
The following opinion will probably get me kicked off this
mailing list, but what the hell.
I see nothing wrong with flaming about Unix lossage; if
anything, this mailing list acts as a support group for
those who are forced to live with Unix. But once in a
while, why not actually do something *constructive* rather
than just complaining to the converted? In particular, I'd
love to see a serious critique of Unix in the form of a
conference paper or journal paper with a title like
"Remaining Trouble Spots in Unix" or "Unix Considered
Harmful".
The purpose of such an article would be to explain to the
rest of the world, in a very professional fashion, why Unix
inspires such unbridled negative reactions in the members of
this mailing list. In particular, I would like to see such
an article separate, as much as possible, the fundamental
design flaws of Unix from the more incidental implementation
bugs.
Would anyone be interested in writing such an article?
From: BH
Date: Fri, 6 Mar 92 11:45:05 EST
Subject: Re: The Story That Must Be Told
> I've thought a lot about such a book. It should have an
> introduction by Dvorak and a forward by Pournelle. I have
> lots of other ideas, let's talk offline.
We should mention also on the copyright page that it was
typeset without the aid of troff, eqn, pic, tbl, yuc, ick
and all those other 3 letter acronyms.
If this isn't appropriate for unix-haters, maybe we should
set up a spin off list of interested
unix-haters-evangelists.
From: AB
Date: Fri, 6 Mar 92 15:30:24 EST
Subject: Re: How About A Serious Critique Of Unix?
Date: Fri, 6 Mar 92 09:59:08 -0500
From: LA
...
The following opinion will probably get me kicked off this
mailing list, but what the hell....
No, I won't do that, but I should...
Some of us have discussed the idea of a unix-haters book,
conference, or article in the past, and in general I think
something like it could be a good thing. So I support such
movements myself. On the other hand, discussions like the
above are always in danger of diverting this mailing list
from its True Mission of high blood pressure relief and
catharsis.
So perhaps you folks should set up your own mailing list.
I'll let you use Unix-Haters to get set up until 11:59 EST
Monday 9 March 1992. Anyone who brings this topic up on
Unix-Haters -after- then will probably be flushed.
I suggest you call your mailing list Unix-Critics. I
nominate DW to be the initial moderator and maintainer.
From: RM
Date: Fri, 6 Mar 1992 13:47:46 PST
Subject: Re: How about a serious critique of Unix?
I'd love to see a serious critique of Unix in the form
of a conference paper or journal paper with a title like
"Remaining Trouble Spots in Unix" or "Unix Considered
Harmful". The purpose of such an article would be to
explain to the rest of the world, in a very professional
fashion, why Unix inspires such unbridled negative
reactions in the members of this mailing list.
If there's one thing which truly pisses me off, it is the
attempt to pretend that there is anything vaguely "academic"
about this stuff. I mean, can you think of anything closer
to hell on earth than a "conference" full of unix geeks
presenting their oh-so-rigourous "papers" on, say, "SMURFY:
An automatic cron-driven fsck-daemon"?
I don't see how being "professional" can help anything;
anybody with a vaguely professional (ie non-twinkie-addled)
attitude to producing robust software knows the emperor has
no clothes. The problem is a generation of swine -- both
programmers and marketeers -- whose comparative view of unix
comes from the vale of MS-DOS and who are particularly
susceptible to the superficial dogma of the unix cult.
(They actually rather remind me of typical hyper-reactionary
Soviet emigres.)
These people are seemingly -incapable- of even believing
that not only is better possible, but that better could have
once existed in the world before driven out by worse. Well,
perhaps they acknowledge that there might be room for some
incidental clean-ups, but nothing that the boys at Bell Labs
or Sun aren't about to deal with using C++ or Plan-9, or,
alternately, that the sacred Founding Fathers hadn't
expressed more perfectly in the original V7 writ (if only we
paid more heed to the true, original strains of the unix
creed!)
In particular, I would like to see such an article
separate, as much as possible, the fundamental design
flaws of Unix from the more incidental implementation
bugs.
My perspective on this matter, and my "reading" of the
material which is the subject of this list, is that the two
are inseparable. The "fundamental design flaw" of unix is
an -attitude-, and attitude that says that 70% is good
enough, that robustness is no virtue, that millions of users
and programmers should be hostage to the convenience or
laziness of a cadre of "systems programmers", that one's
time should be valued at nothing and that one's knowledge
should be regarded as provisional at best and expendable at
a moment's notice.
My view is that flaming about some cretin using a
fixed-sized buffer in some program like "uniq" says just as
much about unix as pointing out that this operating system
of the future has a process scheduler out of the dark ages
or a least-common-denominator filesystem (or IPCs or system
calls or anything else, it -doesn't matter-!)
The incidental -is- fundamental in dissecting unix, much as
it is in any close (say, literary or historical) reading.
Patterns of improbity and venality and outright failure are
revealed to us through any examination of the minutiae of
any implementation, especially when we remember that one
cornerstone of unix pietism is that any task is really no
more than the sum of its individual parts. (Puny tools for
puny users.)
And speaking of revealing patterns of abuse through
observation of detail, has anybody considered that unix
geeks might be Adult Children or Survivors or be permanently
In Recovery? Perhaps they were sodomised by an awk at a
young age, leading to a parodoxical attachment to the agent
of their humiliation? If we could persuade them them to
spend all their time attending pop-psych workshops in the
woods ("Fire in the John"), beating drums and invoking the
shade of Dennis Ritchie, we could keep them away from their
keyboards...
From: SS
Date: Fri, 6 Mar 1992 17:58:04 -0500
Subject: New Mailing List For The Unix Haters Handbook
This is to introduce
[email protected], for discussing the
Book. If you've sent me mail about the book, I've added you
to the list, and you should have gotten a test message by
now.
All further discussions regarding the book will take place
on the ugh list, since unix-haters@tl must remain pure.
UGH is archived. Send mail to me or
[email protected] for
changes. No, the "g" doesn't stand for anything, so quit
whining. I must say, the response to the idea of doing a
book was overwhelming and uniformly supportive. Thanks,
folks!
Two important issues have come up: intellectual property and
money. For the sake of discussion, anyone who sends mail to
ugh will be considered a "contributor". Old flames from past
unix-haters will NOT be reprinted without permission, unless
of course, the source is some cretin like Bill Joy, Dennis
Ritchie, or Chuq von Rospach or whatever the f__k his name
is.
I don't have any unix-haters archives handy. Some people
have sent me mail telling me they have pieces. If you have
anything resembling a complete archive, or even a "best-of"
collection, send mail to ugh. We will use these as a
starting point for the main text, and sprinkle a few choice
rants, verbatim, as inserts to spice up the text.
I will approach the publication of this book in a serious,
profit-minded way. It is not GnuEmacs, ok? When done, all
contributers will receive a complete online source for their
own pleasure. But let's get one thing straight, if copies of
the manuscript get posted to alt.books, I can guarantee
exactly four books will actually get sold in a real store.
The other thing to get straight is that nobody but Steven King
and Gary Larson gets rich from writing a book, so don't start arguing
over how to split those multimillion-dollar royalty checks. If we're
LUCKY, we'll have enough to buy an order of ravs for everyone when
Mary's opens again, OK? If you have published a book of your own,
you know what I'm talking about. If you haven't, you're in for an
educational experience.
I will be very happy to discuss money issues on the ugh
list, and be very candid about costs, work, and royalty
issues. But keep it off unix-haters.
From: SW
Date: Fri, 6 Mar 1992 15:09:47 PST
Subject: Re: How About A Serious Critique Of Unix?
There is no difference between "the fundamental design flaws
of Unix" and "the more incidental implementation bugs."
If you had to write umpteen versions of of a pathname parser
because the system didn't do it for you, I bet you would
make a number of "incidental implementation bugs." And it
wouldn't be your fault. It just not reasonable to expect
that every programmer that comes along has the
where-with-all to deal with aborted system calls, memory
allocation, a language that allows (make that "proudly
features!") both "==" and "=" in conditional tests, etc.
The fault lies with the original designers.
I've been waiting for an appropriate time to use this quote.
This is as good a time as ever.
Programs are written to be executed by computers rather
than read by humans.
This complicates program comprehension, which plays a
major role in software maintenance. Literate
programming is an approach to improve program
understanding by regarding programs as works of
literature. The authors present a tool that supports
literate programming in C++, based on a hypertext system.
- abstract to an article in the Jan 1992 issue of the Journal of
Object-Oriented programming
The fundamental design flaw in Unix is the asinine belief
that "programs are written to be executed by computers
rather than read by humans." [Now that statement may be
true in the statistical sense in that it applies to most
programs. But it is totally, absolutely wrong in the moral
sense.]
That's why we have C -- a language designed to make every
machine emulate a PDP-11. That's why we have a file system
that forces every file to be viewed as a sequence of bytes
(after all, that's what they are, right?). That's why
"protocols" depend on byte-order.
They have never separated the program from the machine. It
never entered their tiny, pocket-protectored with a
calculator-hanging-from-the-belt mind.
Another thought: Unix is a lot like the US economy -- it
focuses on the short term, easy to quantify, small scale
detail, while ignoring long term results and screwing the
average joe. Yes, the entire economy is built around the
idea of cheap energy. Yes, cheap energy is killing the
planet. Yes, we have to send our young off to foreign lands
to die to maintain our supply. But no, we can't fix it, too
much depends on it. Think of the chaos; think of the loss
of productivity; think of the loss of profits for the elite.
I'm sure, if you looked into it closely enough, you'd find
that Bill Joy and AT&T were involved with the Kennedy
assassination.
I ranting now. See what your calm rational suggestion did
to me? Maybe I'll go have a cup of coffee, reboot this
machine, and take a deep breath. That should take a
while...
From: WR
Date: Fri, 6 Mar 1992 14:51-0800
Subject: How About A Serious Critique Of Unix?
Date: Fri, 6 Mar 1992 06:59 PST
From: ln
> From: SS
> Subject: the story that must be told
>
> OK. It's time to write The Book.
>
> You know what I'm talking about: The Unix Haters
> Handbook. Publishing is not a problem. If MIT Press
> won't touch it, my family owns a honest-to-god publishing
> company. Really.
>
> I'm willing to edit it, and anyone else is welcome to
> join in.
>
> The rules are identical to the rules for this mailing
> list. You can use technical jargon and not bother to
> explain it. Apologies or pragmatic suggestions (other
> than the canonical choice of avoiding unix or committing
> suicide) will not be tolerated.
The following opinion will probably get me kicked off this
mailing list, but what the hell.
Kick me off too. I have thought about suggesting this for a
long time. It would be great to see Unix get what it
deserves or to have a list ready to give to some manager
type showing why it is a bad choice. Have a list in print
might change many persons minds and help everyone in the
long run.
I see nothing wrong with flaming about Unix lossage; if
anything, this mailing list acts as a support group for
those who are forced to live with Unix. But once in a
while, why not actually do something *constructive*
rather than just complaining to the converted? In
particular, I'd love to see a serious critique of Unix
in the form of a conference paper or journal paper with
a title like "Remaining Trouble Spots in Unix" or "Unix
Considered Harmful". The purpose of such an article
would be to explain to the rest of the world, in a very
professional fashion, why Unix inspires such unbridled
negative reactions in the members of this mailing list.
In particular, I would like to see such an article
separate, as much as possible, the fundamental design
flaws of Unix from the more incidental implementation
bugs.
With all the talented computer types on this list we should
be able to create a significant document which could alter
computing history. Lets do more than just ridicule Unix,
lets kill it! Wouldn't it be great to see this mailing list
disappear someday?
Would anyone be interested in writing such an article?
From: DW
Date: Fri, 6 Mar 92 15:50:02 PST
Subject: Re: New Mailing List For The Unix Haters Handbook
I had been planning to spend a month in the very near future
solely working on some sort of unix-haters book. I've been
collecting "best of" for a while now, with the creation of a
book in mind. My goal is not money, I had been thinking on
insisting that it appear in paperback for less than $10. I
was going to get permission from everyone cited. My ideas
for format differ from Silens's. It cannot be amateurishly
done, nor be merely a book of rants. It should not contain
words of the sort that get music records "warning: offensive
lyrics" labels put on them.
My goal was to produce something that would make a minor
media splash, at least in the popular technical literature.
If Cliff Stoll can get lots of press, so can this.
Daniel
From: LN
Date: Fri, 6 Mar 92 21:39:15 -0500
Subject: Re: Readability of programs
LP writes:
> I've been waiting for an appropriate time to use this
> quote. This is as good a time as ever.
>
> Programs are written to be executed by computers
> rather than read by humans. This complicates program
> comprehension, which plays a major role in software
> maintenance. Literate programming is an approach to
> improve program understanding by regarding programs as
> works of literature. The authors present a tool that
> supports literate programming in C++, based on a
> hypertext system.
>
> - abstract to an article in the Jan 1992 issue
> of the Journal of Object-Oriented programming
>
> The fundamental design flaw in Unix is the asinine belief
> that "programs are written to be executed by computers
> rather than read by humans." [Now that statement may be
> true in the statistical sense in that it applies to most
> programs. But it is totally, absolutely wrong in the
> moral sense.]
I can't help but to juxtapose Stan's quote with my favorite
quote from computer science (from Abelson and Sussman's
"Structure and Interpretation of Computer Programs"):
... we want to establish the idea that a computer
language is not just a way of getting a computer to
perform operations but rather that it is a novel formal
medium for expressing ideas about methodology. Thus,
programs must be written for people to read, and only
incidentally for machines to execute.
At least *somebody* has the priorities straight!
From: TM
Subject: Re: How About A Serious Critique Of Unix?
Date: Fri, 06 Mar 92 16:27:22 -0800
The following opinion will probably get me kicked off
this mailing list, but what the hell.
[...attempt to be constructive deleted...]
I think L is absolutely right: he should be kicked off the
list. More seriously...
reactions in the members of this mailing list. In
particular, I would like to see such an article
separate, as much as possible, the fundamental design
flaws of Unix from the more incidental implementation
bugs.
I don't see how one could talk about fundamental design
flaws when there was no design to speak of. I suppose one
could talk about conceptual flaws, but that's another
matter.
From: JW
Date: Sat, 7 Mar 92 03:27:11 -0500
Subject: How About A Serious Critique Of Unix?
Yo. People. What are you, on drugs? Some of these last few
messages have carried with them the odd, wishful implication
that if only this, that, or the other thing, some fraction
of "them" would See The Light, and angels would sing, and
suddenly this twisted and warped piece of "architecture" I'm
typing at would turn into a sleek and powerful vision of
What Could Be.
No. Wrong. Get with the program. The world -is-
changing. Already. Voices have been raised, courses have
been plotted, money (-much- money) has been spent, and the
trade magazines once again ring with the eternal chant -
dead, dead, unix is dead. The king is dead, long live the
king. He comes. He lives. We are saved.
The crowd hushes, peers, pauses. Waiting, waiting, to see
who, what, is their salvation.
Windows NT.
There is no God.
From: DM
Date: Mon, 09 Mar 92 19:12:03 EST
Subject: Re: New Mailing List For The Unix Haters Handbook
> Date: Fri, 6 Mar 92 15:50:02 PST
> From: DW
>
> My goal was to produce something that would make a minor
> media splash,
3/4 serious suggestion: Get George Gilder to blurb it.
From: TK
Date: Tue, 10 Mar 1992 10:58-0500
Subject: Re: New Mailing List For The Unix Haters Handbook
Date: Mon, 9 Mar 1992 19:12 EST
From: DM
> Date: Fri, 6 Mar 92 15:50:02 PST
> From: DW
>
> My goal was to produce something that would make a
> minor media splash,
3/4 serious suggestion: Get George Gilder to blurb it.
If he does as bad a job on this as he did on the Thinking
Machines and KSR story, I'll take a pass. I think it would
be more appropriate to get the Rant part of it excerpted in
Mondo 2000. We could get some nice color art, perhaps. Or
if we cartooned it correctly, maybe we could aim at RAW.
From: AB
Date: Tue, 10 Mar 92 17:55:19 EST
Subject: Just A Friendly Reminder
OK, the Monday midnight deadline has passed, so people on
Unix-Haters shouldn't have to hear any more about the UGH
project.
Date: Tue, 10 Mar 1992 10:58-0500
From: TK
Subject: Re: New Mailing List For The Unix Haters Handbook
I think that everybody should be very careful about sending
messages to -both-
[email protected] and
[email protected]
because even if your message contains an acceptable level of
vitriol for Unix-Haters, people may accidentally reply to it
as if it was an UGH message and forget to flame.
If you feel that you -absolutely- -must- send a message to
both lists at once -- don't. Send two separate messages
with the same contents. Or at least include an appropriate
Reply-To:
[email protected]
in the header (as I have done above).
From: DM
Date: Wed, 11 Mar 92 18:03:38 -0500
Subject: Unix Compared To US Economy (fwd)
Thanks -- I found the rantings humorous. I also found
the belittling of the people who made Unix out of place
-- Unix was designed back in the 70's, eons ago in
computer time. It is like insulting the makers of the
Woodrow Wilson Bridge for making it a drawbridge -- how
could they be so shortsighted? Answer: easy -- it is
now being used for purposes (and loads) that were never
intended or dreamed of.
Those people doing the belittling were designing
operating systems BEFORE unix was designed, and have
^^^^^^^^
every right to sneer.
I take that back. Design is too good a word. It was
hatched.
From: SS
Date: Wed, 11 Mar 1992 21:18:57 -0500
Subject: Ranting About Smileys And .Sigs
To:
[email protected]
Date: Wed, 11 Mar 92 21:13:17 -0500
Subject: Mr. Happy
Personally, I take a somewhat less strident position on
smileys. I merely prefer that, if they are used, they at
least be moderately original. Can't you just picture
Candide or Jurgen sprinkled with this little guy? ~/:^)
Why, the very cultural guerrila-hood of it would mildly (OK,
OK, *very* mildly) warm the heart, even though *this* one
:-) is pretty damn tired, and should no doubt be retired.
What *I* hate are .sig blocks. All of 'em. Especially when
I'm on a serial link (like right now). Sometimes (usually),
you have to sit through a screenful of mailer header crud, a
copied, indented version of something you've already seen
copied and indented a half dozen times already, followed by
the person's little, marginally worthwhile comment
(generally identical to everyone else's), and then another
screenful containing *two* copies of some inane, ornate .sig
semi-iconically depicting the dude/ette's entire record
collection, philosophy of life, the configuration of their
Amiga, every conceivable net address that could possibly
bounce mail directed to them, their political affiliations,
the complete details of their sex life and income tax
returns for the past decade, the dollar sum of all the
military contracts they have directed towards basic research
on artificially intelligent paramecia, the definitive
answers to why choosy mothers choose Jif and why the chicken
crossed the road, not to mention what it did once it got to
the other side, and the abstract of their scholarly
dissertation on the "Ontology and Oncology of Chicken
Road-Crossings, Droppings, and the Post-Darwinian
Industrio-Dental Ethos" ...
If you could always just see the person's little comment
without the "benefit" of all the wrapping, it would probably
raise the GNP by some tiny fraction of a percentage point.
I propose we trade .sigs for smileys on a one-for-one basis,
thereby raising the GNP by some vanishingly small fraction
of a percentage point.
--Asdf
Hm, should I put one of *those* here? Naw. You're
creative. You can no doubt visualize it in place of all the
little words on these two lines.
From: RM
Date: Wed, 11 Mar 1992 20:48:48 PST
Subject: Solaris (forwarding, from Desperado)
From: ASDF:GHJKL;
To: ZXCV::QWERTYU
Subj: DESPERADO
Re: Solaris, finally an appropriate name.
Not being a reader of arcane science fiction, I wasn't able
to find a copy of Lem's novel. But as an occasional student
of literary criticism, I did have a access to a copy of
"Alien Encounters: anatomy of Science Fiction" by Mark Rose
(Cambridge MA: Harvard University Press, 1981), which
includes a reasonably extensive discussion of Stanislaw
Lem's novel "Solaris" in ch.3, pp. 82-95.
I quote from Rose's comments, which you might also find
enlightening:
"Lem's initial move in Solaris is to choose as problematic a
sign of the nonhuman as possible. ...
"By making Solaris itself as unyieldingly problematic as
possible, Lem shifts the narrative emphasis ...
"Has the ocean [of Solaris] failed to respond to human
overtures because it is serenely contemptuous of mankind?
..
"as the novel proceeds, the inquiry turns more and more
emphatically into an analysis of the human motives behind
the whole Solarist enterprise ...
"And late in the novel we hear about the scholar Muntius,
who regards the Solarist enterprise as 'the space era's
equivalent of religion: faith disguised as science.' ...
"According to Muntius, 'Solaristics is a revival of
long-vanished myths, the expression of mystical nostalgias
which men are unwilling to confess openly.' ...
"Lem attempts to keep [Solaris] his sign of the nonhuman as
empty, as nonreferential as possible ...
"In Solaris, however, where there is little sense of joy,
the complex of protective barriers and enclosures seem
rather to be an expression of agoraphobia, the fear of open
places ..."
Of course these comments refer solely to Lem's work of
fiction, not, it must be understood, to anything else that
might by pure coincidence have the same name.
From: RM
Date: Wed, 11 Mar 1992 23:59:57 PST
Subject: Source Control In Hell
It really pisses me off that the Source Code Control System
didn't use the normal, industry-standard "From
"-at-the-beginning-of-a-line delimiter, but instead had to
implement a proprietary protocol. Not only that, but it
uses upper-case letters -- must be a VMS holdover! Haven't
they heard of Open Sources(tm)?
I think this is a small gem of Unix Philosophy In Action:
A source-control system which
* embeds information in text files (Hey, it's all 8-bit
bytes!)
* which doesn't quote its meta-information, making it
indistinguishable from the user's intended code
* chooses a sequence of characters which probably worked on
the first ten files they tried it on, even though one
minute's thought would reveal that buckets of C code
contains printf statements, some of which might very well
contain %X%X sequences.
[For true brain-curdling unix horror, consider that the
authors might have realised that "%X%" might occur in
user code, but then brilliantly determined that for C
printf-like functions, "%X%" is equivalent to "%0X%" and
hence no change -to SCCS- would be necessary for that
class of lossage. And nobody would want to use the "%"
character other than in C printf, would they?]
* requires users to alter their data in order to compensate
for system implementation bugs
* undoubtedly (ok, I haven't verified this, but can you
imagine it working?) fails on lines longer than 255
characters, on lines containing ASCII 0 characters, and
probably on all files which contain binary junk (hey,
it's all 8-bit bytes!) in the form ASCII "control" or
bit-7-set characters,
"D,#TD1Ps T[Begin using 006 escapes]", anybody?
Newsgroups: gnu.gcc.bug
From: AO
Date: Thu, 27 Feb 1992 18:22:51 GMT
Organization: GNUs Not Usenet
Subject: Gnu GCC 2 Source And SCCS Don't Mix On M68k's (With Fix)
Index: gcc-2.0/config/m68k.[ch]
(We're running SunOS 4.1 on a Sun 4/75 and a Sun 3/280.)
Description:
Character sequences of the form
%X%
where X is (almost) any upper-case letter are
treated specially by the Source Code Control
System. Such character sequences show up in the
config/m68k.c and config/m68k.h files, causing
"checked out" source files to differ from those
originally checked in.
Fix:
Interposing a 0 between the leading % and the
upper-case letter avoids the problem.
[...]
From: AD
Date: Thu, 12 Mar 92 11:49:33 EST
Subject: [POSIX_ME_HARDER]
Perhaps OpenSystems is a comment about the
open-ended need to rewrite code to comply with new
standards....
------- Forwarded Message
From: MH
Date: Wed, 11 Mar 92 23:38:42 EST
Subject: POSIX_ME_HARDER
Where are the semantics of what happens when a signal is
received during a syscall defined? On BSD, you'll get EINTR
from the function. On SunOS, the syscall will restart
unless you call sigaction with SA_INTERRUPT defined in
sa_flags. But SA_INTERRUPT is one of those "implementation
defined" things. Is there any portable way to know what's
going to happen? Are there any #define's I can check? Are
there any known systems with semantics different from bsd or
sunos?
------- End Forwarded Message
From: JW
Date: Thu, 12 Mar 92 21:29:04 -0500
Subject: [POSIX_ME_HARDER]
From: AD
Perhaps OpenSystems is a comment about the
open-ended need to rewrite code to comply with new
standards....
------- Forwarded Message
From: MH
Date: Wed, 11 Mar 92 23:38:42 EST
Subject: POSIX_ME_HARDER
Where are the semantics of what happens when a signal is
received during a syscall defined? On BSD, you'll get
EINTR from the function. On SunOS, the syscall will
restart unless you call sigaction with SA_INTERRUPT
defined in sa_flags. But SA_INTERRUPT is one of those
"implementation defined" things. Is there any portable
way to know what's going to happen?
No, wait, there's more. Actually, this guy is confused. In
BSD4.1, you got EINTR (always). In BSD4.2, signals were
changed in many (actually some good, but -that- doesn't
belong here) ways. One change was that slow system calls got
restarted, rather than EINTR'd. Good all in all, but made it
harder (not -hard-, just -harder-) to write a program that
let you ^C out of a read from the tty. So in 4.3 they added
a way to to tell the system you wanted your signals to
interrupt rather than restart. Well, that worked, too, so
POSIX standardized it, but this notion of controlling the
behavior of your signals seemed appealing, so they added the
sigaction() call, with flags. Now, we have got 32 flags
here, so we can confidently, I think, assume that soon there
will be some 32 -different- things you can do to your
signals...
Date: Fri, 13 Mar 1992 10:59-0500
From: AW
Subject: [POSIX_ME_HARDER]
Date: Thu, 12 Mar 1992 21:29 EST
From: JW
From: AD
Perhaps OpenSystems is a comment about the
open-ended need to rewrite code to comply with new
standards....
------- Forwarded Message
From: MH
Subject: POSIX_ME_HARDER
Date: Wed, 11 Mar 92 23:38:42 EST
Where are the semantics of what happens when a
signal is received during a syscall defined? On
BSD, you'll get EINTR from the function. On SunOS,
the syscall will restart unless you call sigaction
with SA_INTERRUPT defined in sa_flags. But
SA_INTERRUPT is one of those "implementation
defined" things. Is there any portable way to know
what's going to happen?
No, wait, there's more. Actually, this guy is
confused. In BSD4.1, you got EINTR (always). In BSD4.2,
signals were changed in many (actually some good, but
-that- doesn't belong here) ways. One change was that
slow system calls got restarted, rather than
EINTR'd. Good all in all, but made it harder (not
-hard-, just -harder-) to write a program that let you
^C out of a read from the tty. So in 4.3 they added a
way to to tell the system you wanted your signals to
interrupt rather than restart. Well, that worked, too,
so POSIX standardized it, but this notion of
controlling the behavior of your signals seemed
appealing,s o they added the sigaction() call, with
flags. Now, we have got 32 flags here, so we can
confidently, i think, assume that soon there will be
some 32 -different- things you can do to your
signals...
I don't understand any of this, and it's really boring.
From: LF
Date: Mon, 16 Mar 1992 12:02-0500
Subject: I Could Do Division Better Than This In Third Grade...
One of the greatest things about living here in the future
is that we mortal humans don't have to do arithmetic. Well,
obviously UNIX has not yet caught up to that future. I got
this last week from an FTP client I was using on a UNIX box
(never mind the obviously abysmal throughput this seems to
indicate, over a LAN yet; that's a second problem):
15678922 bytes sent in 52363.97 seconds (0.002 Kbytes/s)
Well, this didn't look right, but hey, I'm just a human, and
humans can't do arithmetic, right? So I asked a different
computer:
(/ 15678922 52363.97) yields 299.42197
But hey, what's two orders of magnitude error between
friends?
Maybe UNIX is still using sliderules and can't keep the
decimal points straight. (It also doesn't know how to
round.)
From: DW
Date: Mon, 16 Mar 92 11:37:05 EST
Subject: The Solution To Unix Is MORE UNIX!
From a recent announcement by Sun about their wonderful new
SPARCworks program development tools:
MakeTool MakeTool is the OpenWindows interface to make, the
SunOS utility that oversees program compilation
and ensures that programs are compiled from the
newest sources. In addition, MakeTool contains a
browser that helps you interpret makefiles by
expanding macros and rules so that you can make
sense of them easily.
I think it goes without saying that the next release will
contain a MakeToolTool that helps you figure out how to use
MakeTool...
From: RM
Subject: "Clocks Are Running Faster But The Calendar Is Running Backwards"
Date: Wed, 18 Mar 1992 15:17:08 PST
From: RO
Newsgroups: comp.arch
Date: 18 Mar 92 08:16:53 GMT
Subject: Re: Imprecise exceptions and Alpha
In some article DS writes:
> Arithmetic exceptions -- integer overflow, floating-point
> overflow, floating-point underflow, division by zero,
> invalid operation, and inexact result -- are precisely
> what the English word means: exceptions (uncommon,
> extraordinary, rare, etc.). We deliberately chose in Alpha
> to trade off increased performance for the normal case
> against lower performance in the exceptional case. Our
> paying customers have consistently asked for this.
>
> This desire is clearly reflected in some popular computer
> languages. C, for example, typically runs with integer
> overflow exceptions DISABLED, and has NO portable
> facilities for building exception handlers that actually
> do anything except die on a floating-point exception. This
> suggests that the number of portable C programmers who
> would prefer Alpha implementations to run more slowly, but
> supply precise arithmetic exceptions, is close to zero.
I've no idea what a "portable C programmer" might be. My
wife can't lift me off the ground, so I'm probably not even
luggable. But I _am_ a C programmer, *EVEN WHEN I DON'T
WANT TO BE*.
- The Fortran compiler I use is f2c (the vendor's compiler
is priced beyond our interest level)
- I am seriously considering changing from the vendor's
Pascal compiler to p2c (the optimizer's constant
propagation code firmly believes that procedure passed as
parameters to other procedures are never called, so that
variables they set -- and *exist* to set -- are
unaffected); I may even do my own p2c
- The Ada compiler I use is AdaEd, which is built on C
- The Scheme systems I use are built on top of C.
- Want to guess what the Prolog systems I use are built on?
Why am I retraining myself in Ada? Because since 1979 I
have been trying to write reliable code in C. (Definition:
reliable code never gives wrong answers without an explicit
apology.) Trying and failing. I have been frustrated to
the screaming point by trying to write code that could
survive (some) run-time errors in other people's code linked
with it. I'd look wistfully at BSD's three-argument signal
handlers, which at least offered the possibility of provide
hardware specific recovery code in #ifdefs, but grit my
teeth and struggle on having to write code that would work
in System V as well.
There are times when I feel that clocks are running faster
but the calendar is running backwards. My first serious
programming was done in Burroughs B6700 Extended Algol. I
got used to the idea that if the hardware can't give you the
right answer, it complains, and your ON OVERFLOW statement
has a chance to do something else. That saved my bacon more
than once.
When I met C, it was obviously pathetic compared with the
_real_ languages I'd used, but heck, it ran on a 16-bit
machine, and it was better than 'as'. When the VAX came
out, I was very pleased: "the interrupt on integer overflow
bit is _just_ what I want". Then I was very disappointed:
"the wretched C system _has_ a signal for integer overflow
but makes sure it never happens even when it ought to".
It would be a good thing if hardware designers would
remember that the ANSI C standard provides _two_ forms of
"integer" arithmetic: 'unsigned' arithmetic which must wrap
around, and 'signed' arithmetic which MAY TRAP (or wrap, or
make demons fly out of your nose). "Portable C
programmers", know that they CANNOT rely on integer
arithmetic _not_ trapping, and they know (if they have done
their homework) that there are commercially significant
machines where C integer overflow _is_ trapped, so they
would rather the Alpha trapped so that they could use the
Alpha as a porting base.
Having said which: I will gladly put up with the Alpha
exception mechanism as long as
- there is a documented C-callable function which
controls the integer trapping state
- there is a documented C-callable function which
controls IEEE-ish floating-point traps
- there is a documented C-callable function which
includes a barrier (can I _rely_ on signal(SIGFPE, f)
including a barrier?)
--
I am writing a book on debugging aimed at 1st & 2nd year CS
students using C/Modula/Pascal-like languages. Please send
suggestions (other than "you _must_ cite "C Traps and
Pitfalls") to RO
From: DH
Date: Thu, 19 Mar 92 11:35:32 EST
Subject: Re: Just A Friendly Reminder
Date: Tue, 10 Mar 92 17:55:19 EST
From: AB
If you feel that you -absolutely- -must- send a message
to both lists at once -- don't. Send two separate
messages with the same contents. Or at least include an
appropriate
Reply-To:
[email protected]
in the header (as I have done above).
Too bad I use out-of-the box unix mail "tools" which don't
handle Reply-To: correctly...
From: EW
Date: Thu, 19 Mar 92 08:59:41 PST
Subject: Re: "Clocks Are Running Faster But The Calendar Is Running Backwards"
From: RM
Date: Wed, 18 Mar 1992 15:17:08 PST
There are times when I feel that clocks are running
faster but the calendar is running backwards. My first
serious programming was done in Burroughs B6700 Extended
Algol...
You too?
Brother!
From: RC
Date: Fri, 20 Mar 92 14:00:50 EST
Subject: Re: It's fighting back
I made awhile ago. No problem, I type
tar -cf uh.tar
and get no response.
Whoops.
Is that a "c" rather than an "x"?
...
It's like they have to work hard to create this sort of lossage.
I have always thought it was particularly clever of them to choose
'x' and 'c' which are adjacent keys on every keyboard I have ever
used.
From: BB
Date: Fri, 20 Mar 92 13:32:07 PST
Subject: Working?
Seen in comp.newprods:
> UNIX COSORT Gets a VMS Face
>
> MANHASSET, NY, February 27, 1992 -- Information
> Resources, Inc. has announced ...
> COSORT is a general-purpose sort/merge package for
> high volume data processing installations. It includes a
> drop-in, but working, replacement
^^^^^^^^^^^
>for the system sort as well as standalone interactive and
>batch modes.
Look! Even these guys admit that UNIX programs don't work.
Of course, who's to say that theirs does either... After
all, it is implemented on top of Satan's operating system.
From: DC
Date: Fri, 20 Mar 92 15:38:40 -0800
Subject: Echs?
The following line just appeared on my screen:
xterm: fatal IO error 54 (Connection reset by peer) or KillClient on X server "Chang:0.0"
This is interesting in that I am not running X, nor have I
ever run X on this machine (or indeed used X at all in more
than a year). Pretty clearly the message was intended for
someone else.
From: EW
Date: Mon, 23 Mar 92 11:19:17 PST
Subject: [One for the Unix Haters]
[numerous ugly forwarding headers beheaded]
["ugh" members please take note -EW]
From: lp via rec.humor.funny
It occurred to me a while ago that Unix is much like the
U.S. Government:
A long time ago, a few brilliant men created a system that
empowered its users, gave them freedom, and provided a few
essential services.
Now it is old, slow, easily corrupted, overly restrictive,
too large and confusing for anyone to understand, plagued
with inconsistencies, and run by men who only care about
money.
From: DM
Date: Tue, 24 Mar 92 00:30:02 -0500
Re: I'm A Homeless Person
Once I had a fine thirty-six room mansion.
Now I live in a cardboard box called unix.
From: SS
Date: Tue, 24 Mar 1992 21:28:59 -0500
Subject: Open Systems Means "Open Wide"
Oh joy, A/UX has completely forgotten how to reclaim disk
space.
I compressed a 64MB file (/ftp/mqueue/syslog.old) down to
12MB. Of course, instead of freeing up 52MB, this simply
eats up another 12MB of space. No, Bart, the uncompressed
version is not still sitting around.
Just check this out: according to du (tells you how much
space you're allegedly using), I freed up 52MB. According to
df (tells you how much space is free), I lost 12MB. Gd this
piece of fungus.
Leave it to unix to have two completely unrelated tools that
do the same thing, both of them the wrong way.
-----------------------------------
BEFORE:
pseudo@brazil> df
/ /dev/dsk/c0d0s0 8942 blocks 18299 i-nodes
/ftp /dev/dsk/c6d0s3 25044 blocks 73118 i-nodes
/u /dev/dsk/c5d0s3 53484 blocks 73368 i-nodes
pseudo@brazil> cd /ftp
pseudo@brazil> du -s *
274 ansiloop
47244 ftp
1738 lib
18 lost+found
134936 mqueue
4172 spool
48956 src
27370 syslogs
pseudo@brazil>
AFTER:
pseudo@brazil> df
/ /dev/dsk/c0d0s0 8942 blocks 18299 i-nodes
/ftp /dev/dsk/c6d0s3 1452 blocks 73128 i-nodes
/u /dev/dsk/c5d0s3 53484 blocks 73368 i-nodes
pseudo@brazil> cd /ftp
pseudo@brazil> du -s *
274 ansiloop
47244 ftp
1738 lib
18 lost+found
23984 mqueue
4172 spool
48956 src
27370 syslogs
pseudo@brazil>
----------------------
No, don't ask me why we need to even KEEP a 64MB syslog
file. I could just blow it away, but knowing unix that
might completely fill up the rest of my disk!
But wait, there's more!
Of course, since we don't have a REAL NETWORK with CLIENTS
and SERVERS I can't put it on a backup tape unless I move it
to Brigade first. So I can't even trust moving it to
Brigade, because the checksum program (sum) gives two
different answers on the two machines. Of course, I could
use ASS-BACKWARDS COMPATIBILITY MODE on a test binary file,
because I sure as HELL don't trust ftp:
pseudo@brigade> sum -r foo
sum: Can't open -r
37798 160 foo
pseudo@regiment> sum -r foo
37798 320 foo
How's that for super compatibility? I guess you're supposed
to think that 160 = 320 in compatibility mode. You see, it
IS compatible, as long as you don't depend on getting a
consistent value for the file size. But you know, just
because a meaningless attribute like "block count" changes
unpredictably when you move a file from disk to disk doesn't
mean you can ignore it. Check out this twisted gem from
sum's man page:
DIAGNOSTICS
Read error is indistinguishable from end-of-file on most
devices; check the block count.
From: RA
Date: Wed, 25 Mar 92 03:54:50 -0500 (EST)
Subject: Re: Open Systems Means "Open Wide"
No, no, Steve, you don't understand. Your version of the
"compress" program is the first of a new generation of unix
utilities that make use of the Dynamic Expunge Feature.
Remember all those people flaming about how UNIX lacks the
separate DELETE, UNDELETE, and EXPUNGE commands we used to
have on primitive operating systems? Well, the UNIX
maintainers Heard our Prayers.
Your "compress" program cleverly spawns a child before
exiting, and leaves the child with an open file descriptor
on your deleted file. Thus, the file itself lingers on,
without cluttering up your directory listings, until the
system is next rebooted or the process is killed. Should
you need to UNDELETE, simply run the "dd" program with
appropriate arguments to copy your file from the raw disk
device; the slight additional overhead of the copy operation
is more than paid for by the defragmenting effect it will
have on your file.
Please note that the Dynamic Expunge Feature does not
require any kernel modifications or new system programs.
Another triumph for the "lots of tiny tools" school of
operating system design!
From: RM
Date: Thu, 26 Mar 1992 17:04:57 PST
Subject: What Unix Breeds
Threre is no direct unix hatred in this message, but there
is evidence of a blithe spirit (perhaps it was lithe?)
tragically broken by exposure to unix.
Unix breeds submissive users.
I saw a message on the postscript newsgroup in which this
person mentioned that she couldn't image a postscript
document in various implementations and mentioned as an
aside that "Ghostscript doesn't do clipping correctly" Well,
I didn't remember ever seeing a bug report on
bug-ghostscript to this effect, so out of curiousity I asked
her for some more information.
In spite of the fact that she apparently has the skills to read news,
snag compressed tar files from distant points of the internet, compile
the program, run it, keep version numbers straight, and so forth, the
idea of actually complaining to somebody about software which doesn't
work seems -totally- alien to her.
From: EW
Date: Thu, 26 Mar 1992 12:03:21 -0800
Subject: Memory-Intensive Postscript Program
No. How do I do it? I do not subscribe to the bug-report
mailing list. In the meanwhile I installed ghostscript 2.4.
There the same picture starts fine, but never finishes (I
killed it after 2 hours of eating 90%+ of CPU). I know this
is good postscript as NeWS displays it correctly (and 2.3
displays it with no complaints, only incorrectly, and 2.4
does not complain either...)
From: SS
Date: Tue, 31 Mar 1992 11:54:58 -0500
Subject: Author Wanted For DOS/UNIX book
Date: Mon, 30 Mar 92 17:44:57 EST
From: SG
To: <lots of
[email protected]>
Subject: Author Wanted For DOS/UNIX Book
A publisher that I am involved with (ORA) is looking for
a technical person to oversee a book that they are
developing. The tenatitive title is "UNIX for DOS
People." The book would be an introduction to UNIX for
people who know a lot about DOS.
If you are interested, please send me email or call me at
617-876-6111
A publisher that I am involved with (Reynolds) is looking
for a technical person to oversee a book that they are
developing. The tentative title is "Cocaine for
Alcoholics". The book would be an introduction to crack for
people who know a lot about drinking household cleaning
products.
If you are interested, please send me email or call me at
617-SHAKES-1.
From: PS
Date: Thu, 2 Apr 92 11:24:54 EST
Subject: Natural Analogues of Unix
From the New York Times of April 1, 1992:
"Scientists have discovered what could be the largest
and oldest living organism on earth -- an individual
mightier than the blue whale, the giant sequoia tree or
such past pretenders to size supremacy as the dinosaur.
The organism is a giant fungus, an interwoven
filagree of mushrooms and rootlike tentacles spawned by
a single fertilized spore 1,500 to 10,000 years ago and
now extending for more than 30 acres in the soil of a
forest near Crystal Falls, Mich., along the Wisconsin
border."
Just imagine: thousands of years from now, computational
archaeologists will discover a huge network of primitive
computers running Unix. They'll theorize that it spread
from a single spore that they'll be able to trace to New
Jersey.
From: DC
Date: Mon, 6 Apr 92 18:42:20 -0700
From: Finger
You know what I like about unix finger? It tells you what
shell someone is using. You couldn't get *that* from the
ITS implementation.
From: JL
Date: Tue, 7 Apr 92 05:46:44 EDT
Subject: Perhaps It IS A Typewriter And The Keys Would Jam
Ah, the wonders of Unix mailers:
Date: Tue, 7 Apr 92 04:26:02 -0400
From:
[email protected]
Subject: Returned mail: User unknown
Message-Id: <
[email protected]>
To:
[email protected]
----- Transcript of session follows -----
While talking to tla.com:
>>> RCPT To:<
[email protected]>
<<< 550 <
[email protected]>... User unknown: Operation would block
550
[email protected]... User unknown
----- Unsent message follows -----
[who cares]
[
[email protected] is a published "well-known" address.
My guess is that it really DOES exist, but a locking problem
caused the name lookup to fail - which in typical Unix
fashion got interpreted as the most convenient - to the
software - error.]
From: LK
Date: Tue, 7 Apr 1992 09:47:09 PDT
Subject: Re: Finger
> You couldn't get [shell name] from the ITS mplementation.
I think I saw something on uunet!uu!net!its-love about
finger that showed HACTRN listed in the shell column. Was
HACTRN an early offshoot of /bin/sh, before they got it
right?
From: DC
Date: Tue, 7 Apr 92 12:41:50 -0700
Subject: Re: Finger
Apparently the point of my message was lost on some.
It's of no conceivable interest to me what shell someone is
running. Or, more accurately, what shell they are given by
default. The only reason I get told that is because it's in
the passwd file, and finger is so stupid all it knows to do
is look there, and some boucephalic idiot figured it might
as well tell me since it's there along with the user's full
name. Actually I'm surprised it doesn't tell me the
person's encrypted password too.
But I might want to know any of the several useful things
the ITS finger give me that unix finger doesn't. Like what
the person does, who they work for, what job they are
currently running, when they last logged out if they aren't
running a job, and what actual terminal they are logged in
from.
ITS is the *only* operating system I know of that got that
last right. The supdup protocol (at least; I don't know
about telnet) allows the client computer to pass a location
string along to the host for this purpose, so that you can
be logged in through arbitrarily many supdup links and your
console location is transitively displayed by finger at the
far end. Apparently it was ``impossible'' to make this work
under 20X, despite serious efforts by several very smart
hackers, apparently because there was no place the
information could be passed between the supdup acceptor
process and the HACTRN-equivalent (what did 20 call that?
God it's been a long time) it created.
Unix, of course, doesn't even try.
No, actually, that's not true. I'm told that there's a
helpful field in the passwd file you can set, and *that*
will be displayed as your terminal location. Even if you
are logged in from a STY. In Mallorca.
(What does unix call a STY? ...No, I don't want to know.)
From: WW
Date: Tue, 7 Apr 92 14:34:42 PDT
Subject: Re: Finger
I think I saw something on uunet!uu!net!its-love about
finger that showed HACTRN listed in the shell column.
Was HACTRN an early offshoot of /bin/sh, before they
got it right?
No, HACTRN was an early version of gdb, before they messed
it up.
(HACTRN was just the name that showed up when you were
sitting in DDT, if I remember enough. DDT far exceeded the
usefulness of ANY unix debugger, because it was always
there...)
From: LK
Date: Tue, 7 Apr 1992 16:31:49 PDT
Subject: Re: Finger
> No, HACTRN was an early version of gdb, before they messed
> it up.
>...
>DDT far exceeded the usefulness of ANY unix debugger
I don't understand. Why would you want your shell to be a
debugger? Was it because ITS had so little disk space that
you had to do limit coredumpsize 0? ;-)
/bin/sh is one of the most important features of Unix.
Treating all data as strings and files makes life so much
easier for writing the shell scripts, I don't see how you
could do it in a debugger, even one more powerful (?!?!?)
than GDB.
Like, did IT'S have its cron job spawn debugger scripts?
From: WW
Date: Tue, 7 Apr 92 19:09:15 PDT
Subject: Re: Finger
ITS is the *only* operating system I know of that got
that last right. The supdup protocol (at least; I
don't know about telnet) allows the client computer to
pass a location string along to the host for this
purpose, so that you can be logged in through
arbitrarily many supdup links and your console location
is transitively displayed by finger at the far end.
Ah yes. The extended info that ITS finger/etc kept about
each user (and allowed them to update, of course) was quite
nice. X.400 does all that for one now, of course, using
only a couple hundred times the CPU cycles and memory
storage...
Actually, at IncPresU there was a "terminal location"
database that kept track of where which terminal server
ports were, so that when you connected from one of the
"ethertips" (using PUP or TCP), finger would print the
correct location. This went away when you connected via
multiple hops, though. The "telnet location" option was
eventually defined, but hardly anyone implements it. I
think that on "dialin" lines, the user could even modify
their own location...
Apparently it was ``impossible'' to make this work
under 20X, despite serious efforts by several very
smart hackers, apparently because there was no place
the information could be passed between the supdup
acceptor process and the HACTRN-equivalent (what did 20
call that? God it's been a long time) it created.
The "EXEC". The problem with tops20 was there wasn't any
particularly good way for one process to glean info from
another.
Unix, of course, doesn't even try.
And the problem is much worse, since of course the process
that talks to the tcp connection (telnetd) is not the same
process that the user is talking to (the infamous shell),
and even THEY can't talk to each other in any useful manner.
Blech. It's all a matter of not being very sensible about
who needs what info, and of course, one must be sure not to
pollute the idea that nothing more complex than a single
byte stream is ever needed to talk between two processes.
From: LK
Date: Tue, 7 Apr 1992 20:01:47 PDT
Subject: Re: Finger
>From: WW
>Date: Tue, 7 Apr 1992 16:53:37 PDT
>Subject: Re: Finger
>
> You're forgetting that you are not allowed to say nice
> things about unix on the unix-haters mailing list. >
>
> The nice thing about ddt/hactrn was that if your program
> crashed, you were left sitting in the debugger and could
> look at it. None of this "I'll run it again under the
> debugger and see if it crashes again. Oops, I guess I
> need the debug switch on the compiler. Oops, that
> compiler doesn't support gdb. Oh well, ship it..."
>
:WQ!
logout
From: DH
Date: Wed, 8 Apr 92 03:20:33 EDT
Subject: TTYLOC
Date: Tue, 7 Apr 92 12:41:50 -0700
From: DC
But I might want to know any of the several useful
things the ITS finger give me that unix finger doesn't.
Like what the person does, who they work for, what job
they are currently running, when they last logged out if
they aren't running a job, and what actual terminal they
are logged in from.
You Don't Understand; It's Actually A Very Complicated
Issue. In Fact There's A Usenix Working Group Studying This
Problem, And They've Been At It For A Couple Of Years.
Right Now They're Worrying About The Problem Of Keeping This
Information 8-Bit Clean.
From: SG
Date: Wed, 8 Apr 92 08:59:07 EDT
Subject: cron
Begin forwarded message:
From: BW
Date: Wed, 8 Apr 92 7:17:04 EDT
Subject: Re: News
>
> Wow, it all just came in.
>
I just read on comp.sys.sun.mumble that sun's cron loses
when the time changes to EDST (last weekend)... this would
explain why no batches went out from foobar the other night.
Date: Wed, 8 Apr 1992 11:03:22 PDT
From: PP
Subject: Two notes without comment
Subject: "proc table is full"
To: ...
From: ...
Date: Tue, 7 Apr 1992 20:03:05 PDT
What does the message "proc table is full" mean? Anything
special to do about it (other than reboot, which seems to
work fine)?
Subject: Re: "proc table is full"
To: ...
From: ...
Date: Tue, 7 Apr 1992 23:03:38 PDT
It's an UNIX kernel's message meaning you have too many UNIX
processes to fork a new process.
I believe you can kill some less important processes as a
super user. (Some proc table elements are reserved for
super user.) But at first, use "ps -aux" command to
investigate why you have so many processes. (SUN's GENERIC
kernel allows 128 processes, kernels used here allows 512.)
If all processes on your computer seem normal and you often
have this message, you need to reconfigure your kernel to
increace the limit of processes. To do this, edit
configuration file and increse "maxuser" entry. (The max
umber of processes is defined as "10 + 16 * MAXUSERS", and
MAXUSERS is 8 for SUN GENERIC, 32 for kernels used here.)
---------------------------------------------------------------------------
Subject: None Of My Cron Jobs On News Ran After 2 a.m. Sunday
To: ...
From: ...
Date: 7 Apr 92 18:10:24 PDT (Tuesday)
.. noticed that we didn't send him any netnews after 2
a.m. on Sunday. Come to think of it, none of the cron jobs
associated with news ran after this time.
I edited the crontab and now things in cron are running.
We noticed a similar problem with a Sun that was scheduled
to do a dump at precisely 2 a.m. and no cron jobs ran since
then.
I did notice that cron didn't abort but it seems there is
still a bug wrt Daylight Savings time. Anyone who is
relying on cron jobs running might want to check to make
sure the jobs are running.
Can you look into this bug and report it to Sun.
*user*
Date: 8-Apr-92 9:08:36 PDT
Subject: cron jobs vs. Daylight Savings Time
To: ...
From: ...
I noticed that ... had stopped sending us news Sunday, and
at least one of my own root crontab jobs didn't run Monday.
You might want to check yours. It looks like the workaround
is to edit the crontab in question ("crontab -e").
I'm running SunOS 4.1.1b. I've sent an inquiry to Sun and
will copy you when I get more info on fixes.
From: RA
Date: Wed, 8 Apr 92 14:07:27 -0400 (EDT)
Subject: Re: TTYLOC
If there's not already an IETF working group doing this, you
can bet there will be one soon, complete with a FINGER MIB
that allows SNMP updates to the GCOS fields of /etc/passwd.
From: PP
Date: Wed, 8 Apr 1992 17:19:58 PDT
Subject: one more note without comment
Sender: SunGuy
Date: 8 Apr 92 12:49:39 PDT (Wednesday)
Subject: Service Order # 977764...Trouble With Cron After Time Change
From: SunGuy
To: ...
The problem you have run into is a known problem and has not
yet been fixed (I guess that last part is rather obvious
:-)).
Three ways to fix the problem:
1) reboot the system
2) do the command "crontab -e" as a user,
specifically write the editor file (without making
any changes) and then quit (e.g. if the editor that
comes up is vi(1), then type ":wq<ret>"). This will
signal the cron daemon to reread all the crontab files
and will get it out of the wedged state it is in.
3) restart the cron daemon by doing the following:
ps -aux | grep cron | grep -v grep
kill -9 <pid for cron daemon>
rm /var/spool/cron/FIFO
type "cron<ret>"
e.g.:
rumrunner# ps -aux | grep cron | grep -v grep
root 160 0.0 0.6 444 184 ? S Mar 26 2:50 cron
rumrunner# kill -9 160
rumrunner# rm /var/spool/cron/FIFO
rumrunner# cron
rumrunner#
The attempt was made to correct the problem a while ago, but
it resulted in cron running jobs twice, so the fix was
removed from the code.
To keep the problem from re-occuring in the future, do not
schedule cron jobs to run between 1:59 am and 3:01 am (for
the night that the time change occures).
SunGuy
[email protected]
Technical Support Engineer
U.S. Answer Center (Utilities group)
Sun Microsystems, Inc.
From: RM
Date: Wed, 8 Apr 1992 17:36:56 PDT
Subject: Re: TTYLOC
From: DH
Date: Wed, 8 Apr 1992 00:20:33 -0700
Subject: TTYLOC
Date: Tue, 7 Apr 92 12:41:50 -0700
From: DC
But I might want to know any of the several useful
things the ITS finger give me that unix finger
doesn't. Like what the person does, who they work
for, what job they are currently running, when they
last logged out if they aren't running a job, and
what actual terminal they are logged in from.
You Don't Understand; It's Actually A Very Complicated
Issue. In Fact There's A Usenix Working Group Studying
This Problem, And They've Been At It For A Couple Of
Years. Right Now They're Worrying About The Problem Of
Keeping This Information 8-Bit Clean.
There are SubStantial security features which Must Be
Addressed before this sort of dangerous and sensitive
InFormation can be passed over the NetWork. RUIP
interactions with SNMP MTA UAs must also be Considered.
Please see RFC1288 (one of my favourites of a recent slew
which redefine protocols to agree with unix implementation
bugs.)
======================================================================
Network Working Group D. Zimmerman
Request for Comments: 1288 Center for Discrete Mathematics and
Obsoletes: RFCs 1196, 1194, 742 Theoretical Computer Science
December 1991
The Finger User Information Protocol
[...]
3. Security ............................................... 7
3.1. Implementation security .............................. 7
3.2. RUIP security ........................................ 8
3.2.1. {Q2} refusal ....................................... 8
3.2.2. {C} refusal ........................................ 8
3.2.3. Atomic discharge ................................... 8
3.2.4. User information files ............................. 9
3.2.5. Execution of user programs ......................... 9
3.2.6. {U} ambiguity ...................................... 9
3.2.7. Audit trails ....................................... 9
3.3. Client security ...................................... 9
[...]
5. Acknowledgments ........................................ 12
6. Security Considerations ................................ 12
7. Author's Address ....................................... 12
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.
However, the BSD version provides few options to tailor the Finger
RUIP for a particular site's security policy, or to protect the user
from dangerous data. Furthermore, there are MANY potential security
holes that implementors and administrators need to be aware of,
particularly since the purpose of this protocol is to return
information about a system's users, a sensitive issue at best.
Therefore, this memo makes a number of important security comments
and recommendations.
[...]
3. Security
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.
3.2.1. {Q2} refusal
For individual site security concerns, the system administrator
SHOULD be given an option to individually turn on or off RUIP
processing of {Q2}. If RUIP processing of {Q2} is turned off, the
RUIP MUST return a service refusal message of some sort. "Finger
forwarding service denied" is adequate. The purpose of this is to
allow individual hosts to choose to not forward Finger requests, but
if they do choose to, to do so consistently.
Overall, there are few cases which would warrant processing of {Q2}
at all, and they are far outweighed by the number of cases for
refusing to process {Q2}. In particular, be aware that if a machine
is part of security perimeter (that is, it is a gateway from the
outside world to some set of interior machines), then turning {Q2} on
provides a path through that security perimeter. Therefore, it is
RECOMMENDED that the default of the {Q2} processing option be to
refuse processing. It certainly should not be enabled in gateway
machines without careful consideration of the security implications.
3.2.2. {C} refusal
For individual site security concerns, the system administrator
SHOULD be given an option to individually turn on or off RUIP
acceptance of {C}. If RUIP processing of {C} is turned off, the RUIP
MUST return a service refusal message of some sort. "Finger online
user list denied" is adequate. The purpose of this is to allow
individual hosts to choose to not list the users currently online.
3.2.3. Atomic discharge
All implementations of Finger SHOULD allow individual system
administrators to tailor what atoms of information are returned to a
query. For example:
- Administrator A should be allowed to specifically choose to
return office location, office phone number, home phone
number, and logged in/logout time.
- Administrator B should be allowed to specifically choose to
return only office location, and office phone number.
- Administrator C should be allowed to specifically choose to
return the minimum amount of required information, which is
the person's full name.
3.2.4. User information files
Allowing an RUIP to return information out of a user-modifiable file
should be seen as equivalent to allowing any information about your
system to be freely distributed. That is, it is potentially the same
as turning on all specifiable options. This information security
breach can be done in a number of ways, some cleverly, others
straightforwardly. This should disturb the sleep of system
administrators who wish to control the returned information.
3.2.5. Execution of user programs
Allowing an RUIP to run a user program in response to a Finger query
is potentially dangerous. BE CAREFUL!! -- the RUIP MUST NOT allow
system security to be compromised by that program. Implementing this
feature may be more trouble than it is worth, since there are always
bugs in operating systems, which could be exploited via this type of
mechanism.
3.2.6. {U} ambiguity
Be aware that a malicious user's clever and/or persistent use of this
feature can result in a list of most of the usernames on a system.
Refusal of {U} ambiguity should be considered in the same vein as
refusal of {C} requests (see section 3.2.2).
3.2.7. Audit trails
Implementations SHOULD allow system administrators to log Finger
queries.
3.3. Client security
It is expected that there will normally be some client program that
the user runs to query the initial RUIP. By default, this program
SHOULD filter any unprintable data, leaving only printable 7-bit
characters (ASCII 32 through ASCII 126), tabs (ASCII 9), and CRLFs.
This is to protect against people playing with terminal escape codes,
changing other peoples' X window names, or committing other dastardly
or confusing deeds. Two separate user options SHOULD be considered
to modify this behavior, so that users may choose to view
international or control characters:
- one to allow all characters less than ASCII 32
- another to allow all characters greater than ASCII 126
For environments that live and breathe international data, the system
administrator SHOULD be given a mechanism to enable the latter option
by default for all users on a particular system. This can be done
via a global environment variable or similar mechanism.
[...]
From: JA
Date: Wed, 8 Apr 92 21:56:57 EDT
Subject: [luciduser: Mail Problems]
From: luciduser (name changed to protect the victim)
Date: Wed, 8 Apr 92 17:36:21 PDT
To: lucid
Subject: Mail Problems
Lucidhostname went down for an hour, please resend any
mail to me.
Thanks,
---luciduser---
You know, any self-respecting mailsystem would hold and
resend any messages instead of dropping them on the floor
when a machine went down. Indeed, there should be *no
holes* in the path from sender to recipient in which any
machine crashing or failing in any way should cause mail to
be dropped on the floor. The worst failure mode should be a
duplicate message (and I mean just one). Does unix
subscribe to this philosophy? No... And its users know it,
too!
From: DH
Date: Thu, 9 Apr 92 05:35:07 EDT
Subject: Re: TTYLOC
Date: Wed, 8 Apr 1992 17:36:56 PDT
From: RM
Date: Wed, 8 Apr 1992 00:20:33 -0700
From: DH
You Don't Understand; It's Actually A Very
Complicated Issue. In Fact There's A Usenix Working
Group Studying This Problem, And They've Been At It
For A Couple Of Years. Right Now They're Worrying
About The Problem Of Keeping This Information 8-Bit
Clean.
Please see RFC1288 (one of my favourites of a recent
slew which redefine protocols to agree with unix
implementation bugs.)
Jesus, that will teach me to be sarcastic!
I liked the bit about "Atomic Discharge." I guess I should
expect no more from the Evil Spawn of New Jersey.
From: NE
Date: Thu, 9 Apr 92 11:30 EDT
Subject: The Surgeons General Are Now Distributing
"Safe Halting" Guidelines ...
From "The Design and Implementation of the 4.3 BSD UNIX
Operating System Answer Book", by Leffler and McKusick,
which purports to give "answers" to all of the exercises in
the original book.
Chapter 13, question 8:
Q: The reboot system call causes the system to halt or
reboot. Give three reasons why this system call is useful.
A(1): Safe halting and rebooting of a system requires
support from the kernel.
A(2): The existence of a system call permits applications to
halt or reboot a system without operator intervention.
A(3): The third reason was lost in an improper system
shutdown.
From: GS
Date: 7 Apr 92 05:36:36 GMT
Subject: Re: Use Of "Crashme"
I would not be startled in the least tiny bit. Nor would I
think that 'ls' ought to be solid. I have seen several
discussions, one I think on alt.sys.sun where a user was
complaining about a specific behavior and wondering if it
was a bug, and blaming the software &| hardware provider.
The poster was told that this behavior was known, and was a
bug, but not to blame Sun since the code came from BSD and
that came from AT&T (the bourne shell I believe).
The replier then went on to enumerate several other bugs
that everyone seemed to know about and that had been
plaguing people for years, and yet nobody had fixed them.
Nearly every company that came out with a machine running
unix, ported the code, bugs and all, and presumably did not
fix the bugs because of the fear of being struck by a
lightning bolt from the unix gods. Or possibly if they
fixed the bugs it would not be "compatible". This kind of
thing has been happening for years, and it is instead
amazing to see that there manages to be any progress at all.
Assuming the reader believes SVR4 _is_ progress.
(insert 0.4 8-)'s) 8-(
---------------------------------------------------------------------------
We want to offer a more standard product; smaller, slower,
less reliable, and more profitable, but standard.
Using yesterday's technology to solve tomorrow's problems.
--Computer Company X
****************************
From: PS
Date: 7 Apr 92 21:56:18 GMT
Subject: Re: Use Of "Crashme"
In an article GS writes:
> Nearly every company that came out with a machine running
> unix, ported the code, bugs and all, and presumably did
> not fix the bugs because of the fear of being struck by a
> lightning bolt from the unix gods.
One company has been fixing the bugs. The problem is, they
get panned for it.
The problem is that if you fix the bugs you need to KEEP
fixing them in every release because AT&T (or USL) never
bothers to fold any fixes back into the source release. So
either you give up fixing them or you give up picking up
every new release of UNIX.
Can you figure out which company I'm talking about now?
> We want to offer a more standard product; smaller, slower,
> less reliable, and more profitable, but standard.
Make that "bigger, slower, and less reliable" and I'll
believe it.
From: NE
Date: Fri, 10 Apr 92 22:45 EDT
Subject: The Dungeons Of UN*X
You are in a maze of tiny twisty tools, all broken in
different ways ...
From: CM
Date: Mon, 13 Apr 92 01:19:32 EDT
Subject: People Unclear On The Concept
And Unix would be a great operating system if you could fix
all the brain damage...
From: HS
Date: 12 Apr 92 00:18:19 GMT
In an article AT writes:
>for the second act, I hereby challenge all the people who
>have commented on my list to do better. List what YOU
>consider the five most important things we have learned
>about distributed operating systems in the past 20 years.
1. A distributed operating system should look, to the
customer, just like a non-distributed operating system,
apart from the possibility of more creative failure modes.
Cleverness should go into hiding its distributed nature, not
exposing it.
2. Unix filesystem semantics -- resources organized in a
tree structure named by ASCII names, and operated on by
open/close/read/write -- work just as well in a distributed
system as in a non-distributed one, unlike most of their
competitors.
3. Most resources are used by only one customer at a time,
so it is important to streamline the *un*shared case while
handling the shared case gracefully.
4. Pipes are an excellent interprocess-communication method,
superior to most of their competitors in flexibility and
distributability (is that a word? :-))... provided you have
some way of establishing them between unrelated processes,
and preferably some way of passing them between processes
dynamically.
5. Most distributed-OS designers would rather design
something new and weird, in hopes that everyone will say
"oh, how wonderful, we must rewrite all our programs to use
this at once", than observe point #1 above and build a
distributed implementation of the same old thing, on which
all that software will run without change.
--
GCC 2.0 is to C as SVR4 is to Unix.
-DD
From: DE
Date: Mon, 13 Apr 1992 10:45-0700
Subject: Can't see the forest for the trees!
Date: Tue, 7 Apr 1992 12:41 PDT
From: DC
Apparently the point of my message was lost on some.
It's of no conceivable interest to me what shell
someone is running.
I chuckled good on that one. I can't believe that someone
missed the point on it.
From: DW
Date: Tue, 14 Apr 92 10:43:00 EDT
Subject: Cheery Message In My Mailbox
I got in this morning and found one of these little gems in
my mailbox; the nice little Unix mailer leaves one of these
cheery greetings from time to time:
Return-Path: <
[email protected]>
From:
[email protected]
Message-Id: <
[email protected]>
Date: Mon, 13 Apr 92 20:28:07 -0400
To: odi!DW
Subject: uuxqt cmd (rmail) status (4 [USAGE])
You know, I was just reading how now that there are window
systems for Unix that let you see your directory as a bunch
of little pictures on the screen, just like a Macintosh,
Unix is now easy to use.
From: "Leigh L. Klotz" <
[email protected]>
Date: Wed, 15 Apr 1992 11:15:12 PDT
Subject: <<
Yesterday I wanted to send a line from a standard .twmrc
file to RM.
With the demise of the SEND protocol, I've resorted to using
X protocol to put up windows on other people's screens,
using the "xmessage" tv:menu-choose program that comes with
X11. Unfortunately, everybody has a different version of
xmessage with slightly different arguments ('-' vs. '-m' for
message, comma-separated vs. space-separated buttons lists,
etc.). But anyway, I trudge on.
Thinking I'd use a Unix feature, rather than just start a
shell buffer and yank the line in, I wrote the line out to a
file, and then stuck the "xmsg" command on it:
xmsg mlynarik << EOFEOF
/import/Xmisc/bin/xsnap -xwd -file $HOME/Snaps/snap`ls $HOME/Snaps | wc -l | sed -e 's/\ //g'`.xwd &
EOFEOF
This is what RM got:
Message from LK on asdf at Tue Apr 14 23:57:58 PDT 1992 (for RM)
/import/Xmisc/bin/xsnap -xwd -file /net/foo/bar/lk/Snaps/snap1.xwd &
From what I can tell, unix weenies consider this a feature.
From: DM
Date: Wed, 15 Apr 92 14:32:22 -0400
Subject: Five Minute Hate
My emacs X window just vanished! No warning, I had just
typed control-X and *KA-BOOM* -- gone. Could I have typed
control-C by mistake? No, it would have queried about
unsaved buffers. I guess a shell window vanished with it,
but was obscured by the emacs window. Anyway, all I ever do
in unix shells is run emacs and log out. Maybe the mouse
slipped and I accidentally did control-D at the shell? No,
the shell window would vanish but the emacs would remain,
although it would look as if I was gone, thanks to yet
another lovely X feature.
I went to the console. It seemed to know that it was halted
although there was no explanation as to why. A phone call
revealed that it was shut down in order to install new
authorization codes, because the old ones were going to
expire. You have to reboot to do that? Of course.
In fact, a system shutdown message had gone to all shell
windows! The display I'm on, being polite and
well-mannered, never beeps.
Apparently there is some tiny tool called "Zephyr" which
might have notified me of the impending shutdown, although
it's a bit flaky...
Gosh, maybe I could put a system-going-down handler in my
emacs? Whoops, nope, wrong operating system there, wrong
decade, here in the future we have to run as fast as
possible just to stay in one place, and by golly, the one
place is falling apart around us!
Just thought I'd share that with you. Gotta go re-delete my
mail now.
From: CM
Date: Wed, 15 Apr 92 16:19:44 EDT
Subject: I'm Having A Haiku Attack...
vmunix
shouldn't have dereferenced that pointer.
oops. run fsck.
From: JL
Date: Wed, 15 Apr 92 23:34:52 EDT
Subject: More Interesting Data On The Eternal Life Of Unix Bugs
A couple of days ago I forwarded two messages pulled off of
comp.arch on this subject. Some brain-dead mailer software
couldn't distinguish between envelope and body material, so
that message ended up looking as if it had been posted
directly by one of the two authors involved - but with a
return path back to me. Very strange and wonderful.... So,
this time I'm removing or sanitizing everything that might
look like a header.
-- Jerry
***From: AG
***Subject: Re: Use Of "crashme"
***Date: 14 Apr 92 23:27:15 GMT
> ........ Nea[r]ly every company that came out with a
> machine running unix, ported the code, bugs and all,
> and presumably did not fix the bugs because of the
> fear of being struck by a lightning bolt from the
> unix gods...
>
> ... or because they do not have the resources to
> re-fix these bugs each time they receive a new
> port... there's enough to do in that realm already,
> I presume, with X, NFS, etc..
... Hmmm, I wonder.... Do these 'resellers', when they
detect and/or fix a bug, bother to report said bug to
*their* supplier, so that the _originator_ of said bug
can fix it? Any re-sellers wish to comment on this?
I formerly worked at <somecompany>, working on a BSD based
UNIX system which was one of the first outside-of-SUN ports
of NFS, and later at <someothercompany> on SVr4.
I can assure you that we *did* detect/fix bugs, and report
them to our suppliers:
BSD
AT&T
SUN
Berkeley was the only group that was at all willing to
accept fixes from outside.
Both AT&T and SUN had a great big "Not Invented Here"
attitude - they would refuse to accept fixes, or fixes would
go into a big black hole, or the next release would have
"fixed" the bug you reported, but with code different from
what you reported - and their fix wouldn't be correct, or...
Hell... one fellow added comments to a rather abstruse code
section, and they were not allowed to be added to the next
official release.
From: JW
Date: Sat, 18 Apr 92 02:50:09 -0400
Subject: Re: Why Is Dxclock Bigger Than Vmunix?
Well, I sort of liked this. Shows spirit.
From: PD
Date: 16 Apr 92 13:00:30 GMT
For reference, here is the output from size (Ultrix 4.2):
text data bss dec hex
1556480 327680 86112 1970272 1e1060 /usr/bin/dxclock
1140496 117200 570848 1828544 1be6c0 /vmunix
I'm sure people have beaten this topic to death before,
but I'll flog it again - WHY DOES IT TAKE 400K BYTES
MORE CODE SPACE AND 200K BYTES MORE DATA SPACE TO PUT A
SILLY CLOCK ON THE SCREEN THAN TO IMPLEMENT ULTRIX?
I feel much better now.
From: DH
Date: Sat, 18 Apr 92 10:32:50 EDT
Subject: Re: Why Is Dxclock Bigger Than Vmunix?
Date: Sat, 18 Apr 92 02:50:09 -0400
From: JW
Date: 16 Apr 92 13:00:30 GMT
From: PD
again - WHY DOES IT TAKE 400K BYTES MORE CODE SPACE
AND 200K BYTES MORE DATA SPACE TO PUT A SILLY CLOCK
ON THE SCREEN THAN TO IMPLEMENT ULTRIX?
I suppose this shows that unix is so lame even a clock is
more powerful.
From: DM
Date: Mon, 20 Apr 92 11:01:50 EDT
Subject: Re: Why Is Dxclock Bigger Than Vmunix?
> Date: Sat, 18 Apr 92 02:50:09 -0400
> From: JW
> again - WHY DOES IT TAKE 400K BYTES MORE CODE SPACE AND
> 200K BYTES MORE DATA SPACE TO PUT A SILLY CLOCK ON THE
> SCREEN THAN TO IMPLEMENT ULTRIX?
dxclock must be implemented in Lisp. Everyone knows that's
what makes programs large and slow.
From: EB
Date: Mon, 20 Apr 92 10:41:23 PDT
Subject: Re: <<
Hey, it is a feature! But don't worry, you can turn it off.
Fortunately it's completely obvious and intuitive how to
turn off this feature.
Instead of
xmsg mlynarik << EOFEOF
/import/Xmisc/bin/xsnap -xwd -file $HOME/Snaps/snap`ls $HOME/Snaps | wc -l | sed -e 's/\ //g'`.xwd &
EOFEOF
You say
xmsg mlynarik << 'EOFEOF'
/import/Xmisc/bin/xsnap -xwd -file $HOME/Snaps/snap`ls $HOME/Snaps | wc -l | sed -e 's/\ //g'`.xwd &
'EOFEOF'
Got that?
[My God, I just realized I *used* this in a shell script 11
years ago! I've been a Unix hacker for over a decade.
Pardon me, I've got to go insert some arbitrary size limits
in my programs...]
From: LF
Date: Tue, 21 Apr 1992 14:08-0400
Subject: Not As Incendiary As I'd Like,
But A Typical Example Of The Mindset...
I'm not under the impression that updating the software by
five years will do much of anything to improve the
reliability of the system. After all, then you get NFS and
NIS and all that fun stuff that breaks, too. But perhaps the
weenix unies remember the recent bugs better than the old
ones or something.
I'll bet we could come up with a good list, though. Whether
they're fixed or not five years later is something else.
--- Start of forwarded messages ---
[ . . . Various headers stripped . . . ]
From: R
Subject: A Request from Steve Jobs -- anyone help
>Begin forwarded message:
>
>Date: Mon, 20 Apr 92 11:35:13 GMT-0700
>From: JB
>Subject: A Request from Steve Jobs
>
>Gentlemen,
>
>I have been belaboring NeXT about the fact that the "Unix"
>they ship with their operating system is generally about 5
>years behind the current BSD release.
>
>I told them that this is causing a fair amount of sysop
>aversion to trying to fold NeXTs into existing SUN or
>heterogeneous networks.
>
>This morning, I got a call from Steve Jobs in which he
>said, essentially, "Look, we don't have the resources to
>get a completely new release of BSD Unix running on top of
>Mach right now. Besides, we're not hearing much about it
>from our customers, many of whom are now installing
>all-NeXT networks."
>
>I told him that the customers he needs to be hearing from
>are the ones he's never going to get unless the Sun sysops
>of the world have more confidence in NeXT Unix. He needs
>more beach-heads. They're not going to try incorporating
>experimental NeXTs into their networks unless they think
>they can do so without a lot of pain, suffering, and
>face-loss.
>
>I also told him that while I'm not a Unix weenie by a long
>shot, it was my impression that a very few
>utilities...telnet, rlogin, sendmail, etc...cause 95% of
>the interoperability problems. Would he consider just
>fixing those?
>
>
> This he tentatively agreed to do, but he asked for a list
> of the ones I had in mind. I found myself embarrassingly
> empty-handed.
>
> I would appreciate it very much if you could ask around
> for war stories regarding hooking NeXTs into Unix networks
> so that we can identify the five to ten utilities which
> need to be brought up to spec. (Feel free to copy this
> around to folks who might be able to help in this regard.)
>
> He also asked for this list as soon as I could generate
> it, so I would appreciate a fairly timely response.
>
>Thanks much...
>
>
> MAN PLANS, GOD LAUGHS
>
>
--- End of forwarded messages ---
From: SS
Date: Tue, 21 Apr 1992 15:23:47 -0500
Subject: Environmental Study Reveals DAMAGING EFFECTS OF SUN
Infoworld, April 20, 1992, page 13:
A full-page ad from Next fills over half the page with big
lummox type:
ENVIRONMENTAL STUDY REVEALS
DAMAGING EFFECTS OF SUN
"Here's a refreshing approach to advertising for you: No
opinions, no theories, no wishful thinking. Just the cold
hard facts about how today's developers and programmers feel
about the major platforms.
It's all here in this report from the independent management
consulting firm, Booz, Allen, & Hamilton....
[ call 800-try-next for a free copy ]
. Avoid prolonged exposure to the Sun.
From: LF
Date: Tue, 21 Apr 1992 16:06-0400
Subject: We Don't Want A Fish With Good Taste...
The last sentence of the first paragraph says it all...
From: HA
Date: 11 Apr 92 13:32:16 GMT
Subject: Scheme Programming Position At TLA
The TLA Artificial Intelligence Laboratory has an opening
for a Research Scientist to provide system support for
research in symbolic and numerical computing. We are
seeking an outstanding system designer who will assume
primary responsibility for the continued development of
TLA's implementation of the Scheme dialect of Lisp, and the
associated Unix environment. Other duties include
continuing research on high-performance implementations of
Lisp-like languages, and supervising students and staff
members. A formal degree (bachelor's level or higher) in
Computer Science is preferred. Applicants must have
experience with Scheme and with Scheme compilation
techniques, and must have developed substantial applications
in Scheme or Lisp. Applicants must also have extensive
knowledge of Unix, although they should have sufficiently
good programming taste to not consider this an achievement.
TLA is an Affirmative Action/Equal Opportunity Employer.
TLA is a non-smoking environment.
From: OS
Date: Fri, 24 Apr 92 22:35:01 EDT
Subject: UNIX As Plant Life
This week, when she could postpone it no longer, my wife
went through her company's "introduction to UNIX" training.
After it was over, she said "UNIX is really awful. Why on
earth is everybody asking for it?"
This prompted an insight, which I can only hope is true:
maybe UNIX systems are the tulip bulbs of the 1990s. After
it's all over, nobody will be able to remember why they
seemed so valuable at the time, and lots o' people will have
lost a pile o' money.
From: JW
Date: Sun, 26 Apr 92 01:47:53 -0400
Subject: Translation
Often, when using the Unix(TM) computer system, one will
find that the error messages one receives are terse and do
not convey the problem precisely. In these cases, a
translation function is useful.
For example, I recently received the following helpful error
message from the C compiler of my DECstation 5000/200, a
state-of-the-art Unix(TM) workstation:
jw> make CC=cc CFLAGS='-Dvolatile=""'
cc -Dvolatile="" -c machinestate.S
input buffer on non-int boundry <===
A brief study of the situation reveals that the full and
correct English translation of this error message is:
The C compiler has just deleted your source file
"machinestate.S" without a trace. It has also deleted
the old version of the object file, in case you were
thinking of recreating the source by disassembling the
object. The compiler notices with regret that the source
file in question contained a hairy interrupt-driven
multithreaded scheduling kernel which you have just
gotten to work right after N days of effort, and
respectfully suggests that you may wish to consider
killing yourself at this time.
Oh well, see you later. Time to run down to Dorchester and
throw some cherry bombs at the police station.
From: JL
Date: Sun, 26 Apr 92 09:21:39 EDT
Subject: RE: Translation
No, no, no, you don't understand the elegant simplicity of
Unix error mes- sages. Remember: The map is not the
territory. No translation is ever completely accurate. The
text doesn't MEAN anything, it simply IS.
In attempting to translate a Unix error message into
English, you have missed the point. The message is what it
is. Absorb it on that basis. Go with the flow.
More to the point, you have all the sources on line, don't
you? (No Unix system is complete without them.) Simply
grep for the error message. The meaning is the message; the
code is the secret. The experience user will know what
needs to be done.
A truely elegant Unix would eschew the use of English-like
phrases in its error messages - they just confuse the issue.
If your error message had been just, say, "+2C)", you would
have been equally enlightened, and could have grep'ed just
as easily - but much more quickly.
From: WP
Date: Sun, 26 Apr 1992 10:15:21 PDT
Subject: Re: Translation
I . . . I . . . I am enlightened!
From: WW
Date: Sun, 26 Apr 92 20:42:44 PDT
Subject: Re: Simple Shell Programming
Well, not quite. Files beginning with a dot are
assumed to be uninteresting, and * won't match them.
There probably aren't any, but
^^^^^^^^^^^^^^^^^^^^^^^^^
Hah hah hah. That's really a good one. ho ho ho.
Of the approximately 130 files in my top level directory, fully
half of them begin with "." Tis very ammusing. Maybe unix
should re-invent the "switch.ini" file from tops10..
Date: Mon, 27 Apr 1992 12:08-0400
From: TK
Subject: RE: Translation
Date: Sun, 26 Apr 1992 09:21 EDT
From: JL
No, no, no, you don't understand the elegant simplicity
of Unix error mes- sages. Remember: The map is not the
territory. No translation is ever completely accurate.
The text doesn't MEAN anything, it simply IS.
A truely elegant Unix would eschew the use of
English-like phrases in its error messages - they just
confuse the issue. If your error message had been
just, say, "+2C)", you would have been equally
enlightened, and could have grep'ed just as easily -
but much more quickly.
Gee, I thought the politically correct error message was
just the same as the success message: null. Think of the
advantages. No pesky man page to update, or have users
complain about. When it gets piped into the middle of you
text file, your file no longer has "%%swap space exhaused"
spliced into it. It does make it a tad more difficult to
grep for the error in the sources, but hey, that's a small
price to pay for making the elegant pipe mechanisms robust
and bullet-proof.
From: GR
Date: Tue, 28 Apr 92 15:12:34 -0400
Subject: Flame
I just sent the following flame to (oh no!) Unix newsgroup
comp.arch. Since most of you probably don't put up with
such lossage (I know I'm weak), I thought you might like to
see it.
In some article PS writes:
* In another article DB writes:
* > Unix programmers have a bizzare idea of
* > efficiency. Emacs misuses pointers to save a few bytes
* > (while being huge and bloated), XWindows is a pig, but
* > hey, we saved a JMP! :-)
* That's not UNIX, that's MITnix. This massive abuse of
* virtual memory seems to have come in with the MIT "free"
* software: X, the GNU stuff, and so on... --
First of all, memory for PCs (and soon for workstations)
runs for about $30/MB, and 8 additional MB take care of both
X and GNU Emacs.
In addition, I won't say much about X, which I dislike,
although if I'm not mistaken most of the bloat has occurred
because of vendor requests. X 10 was much leaner, and
provided more than sufficient functionality as far as I'm
concerned.
With respect to Emacs, may I remind you that the original
version ran on ITS on a PDP-10, whose address space was 1
moby, i.e. 256 thousand 36-bit words (that's a little over 1
Mbyte). It had plenty of space to contain many large files,
and the actual program was a not-too-large fraction of that
space.
There are many reasons why GNU Emacs is as big as it is
while its original ITS counterpart was much smaller:
- C is a horrible language in which to implement such things
as a Lisp interpreter and an interactive program. In
particular any program that wants to be careful not to crash
(and dump core) in the presence of errors has to become
bloated because it has to check everywhere. A reasonable
condition system would reduce the size of the code.
- Unix is a horrible operating system for which to write an
Emacs-like editor because it does not provide adequate
support for anything except trivial "Hello world" programs.
In particular, there is no standard good way (or even any in
many variants) to control your virtual memory sharing
properties.
- Unix presents such a poor interaction environment to users
(the various shells are pitiful) that GNU Emacs has had to
import a lot of the functionality that a minimally adequate
"shell" would provide. Many programmers at TLA never
directly interact with the shell, GNU Emacs IS their shell,
because it is the only adequate choice, and isolates them
from the various Unix (and even OS) variants.
Don't complain about TLA programs vs. Unix. The typical
workstation Unix requires 3 - 6 Mb just for the kernel, and
provides less functionality (at the OS level) than the OSs
of yesteryear. It is not surprising that programs that ran
on adequate amounts of memory under those OSs have to
reimplement some of the functionality that Unix has never
provided.
What is Unix doing with all that memory? No, don't answer,
I know, it is all those pre-allocated fixed-sized tables and
buffers in the kernel that I'm hardly ever using on my
workstation but must have allocated at ALL times for the
rare times when I actually need them. Any non-brain-damaged
OS would have a powerful internal memory manager, but who
ever said that Unix was an OS?
What is Unix doing with all that file space? No don't
answer. It is providing all sorts of accounting junk which
is excesive for personal machines, and inadequate for large
systems. After all, any important file in the system has
been written by root -- terribly informative. And all that
wonderfully descriptive information after lots of memory
consumed by accounting daemons and megabytes of disk taken
up by the various useless log files.
Just so you won't say that it is only TLA OSs and software
that has such problems, consider everyone's favorite text
formatter, TeX (I'm being sarchastic, although when compared
with troff and relatives...). The original version ran
under FLA on PDP-10s. It is also bloated under Unix, and it
also must go through contortions in order to dump a
pre-loaded version of itself, among other things.
From: AD
Date: Sat, 2 May 92 16:34:15 EDT
Subject: Caution: No User Configurable Parts Inside....
Yesterday afternoon, I undertook the "simple" task
of moving machine W from subnet A to subnet B...which would
seem to be an easy task...
Remembering that there is little one can do to a
modern sun unix box when it hasn't properly booted and found
it's file servers, etc., I took care to change "all" the
magic files on the machine before shutting it down for the
move -- changing internet address both on the machine and on
the master YP server. Since I thought I would move the
machine back later, I dutifly kept around the old versions
of relevant files with a suitable extension.
I moved the machine to the other side of the floor,
plugged it in, and it failed to boot. Well, at this point I
needed to muck around with the configuration to find out
why...but, since the machines files cannot be edited in this
preboot state, I had little choice but to netboot the
machine (yes, one can use the CD-ROM to boot it, but this is
just as painful, I've been through that, too). Now, I
couldn't netboot off of subnet B which I'd moved to since it
didn't have a machine on the network setup to allow
netbooting (and I'm sure that setting this up is just about
as intuitive as everything else...). So, that meant I had
to physically cart the machine back across the floor to the
old connection on subnet A.
Back on subnet A, I find that some boot file not
only looks for magicfilename, it looks through
magicfilename.*....then expects * to match to something of
the form xx0. So, when I kept around a backup with my own
extension, this violated the assumptions of the fragile
script and it bombed out in some way. I didn't bother
trying to figure out the full implications here since I
don't understand sh subtleties and would prefer not to. I
deleted my nice old files (I wasn't going to 2nd-guess it
and try to come up with a name it wouldn't decide to
misinterpret), and move the machine back across the floor
(even IPCs aren't exactly portable machines).
Now it stopped complaining about that, but was
unable to find the machine where most of the rest of its
file were stored. It turns out said machine had been on the
same subnet prior to the move, but was on a different subnet
afterwards. I suppose, I should have guessed that this
would break every assumption in the boot script.
Just as I was about to string a cable and give up on
any sort of software solution to this problem, I ran into a
unix-wizard. I described my problem and he said, "Ah! Your
machine needs to know the gateway for getting off of your
network." So, we looked at the arcane boot scripts and
found that there was an obscure comment in one of them which
implied we needed to put the hostname of the gateway in a
magic file, then copy over the "route" program to the root
partion. Then the script would go off and install some
fixed route through the gateway and all would be happy. I
was concerned that this might not work because of Sun's
great innovation known as dynamic libraries (in a previous
fight with booting a machine, I'd tried copying files to the
root partition and found that it didn't work when all the
dynamic libraries weren't mounted....and I had no clue what
all it wanted). The wizard insisted that sun must not be
that brain dead so things should be fine.
I moved the machine back to subnet A, edited the
magic file, and copied over the route program. Back on
subnet B the machine failed to boot for two reasons: (1) it
couldn't find cat (2) it couldn't find ld.so (the shared
libraries). So the script had lied, it really needed cat,
as well (which also uses dynamic libraries)...AND the route
was also dynamically linked.
Back on subnet A, we found that in other places in
the same shell-script, Sun had used shcat (something they
defined in the script) since cat wasn't around -- clearly we
were dealing with a piece of code that had never been used
before. Consulation with another unix-wizard led us to find
a staticly linked version of route on some other machine
around the lab. By now the unix-braindeath was so
prevelant, I gave up and hard-coded the ip address for the
gateway machine into the shell script and carted the machine
back to subnet B -- where it again failed to come up.
Now the first wizard comes in and plays around with
ifconfig and decides that the netmask is set wrong. Further
perusal of the boot files convinces him that if I add an
entry to another magic file, it will override the default
(and wrong) assumptions made by ifconfig about what part of
the ip address consitutes our physical network. Another
round trip later, the machine gets a step further and tells
me that I don't have access to mount the filesystem I want.
This turns out to be due to the fact that it had been 8
hours since I started this project and I'd never gotten
around to updating the real canonical source in our
namespace and the automagic update and finally kicked in and
trashed my name change -- that, at least, was easy to fix.
...so, 8 to 9 hours later, the machine now runs on
subnet B. I think next time I'll just run a long cable and
yell back real loud at anyone who complains about the mess
of cables around the lab....
From: ER
Date: Mon, 4 May 92 13:56:05 EDT
Subject: Operating System Similes (fwd)
An addition to an old thread comparing operating systems:
TOPS-10 was like a rural Mexican bus. It wheezed and
clattered and the aisles were full of weird livestock and
stolid characters who spoke no known languages. The running
times bore no coherent relationship to the schedule or
anyone's expectations and the whole lash-up seemed
perpetually on the verge of disintegrating under its own
weight. But it hung in there years after everyone thought
it was obsolete getting the job done, and outlasted a lot of
fancier competition. A lot of people who cursed it while
they rode remember it fondly now.
From: RS
Date: Mon, 4 May 92 19:04:27 EDT
Subject: Re: Operating system similes (fwd)
From: ER
An addition to an old thread comparing operating systems:
TOPS-10 was like a rural Mexican bus.
...
A lot of people who cursed it while they rode remember it fondly now.
Give this boy some compiler-generated optimized sparc code
to hand-disassemble...
From: ER
Date: Mon, 4 May 92 23:25:08 EDT
Subject: Re: Operating system similes (fwd)
In reply to the Mexican-bus analogy:
> Give this boy some compiler-generated optimized sparc code
> to hand-disassemble...
Verdad? Don' you know any better than to patch binaries,
sen~or? Gringos are all crazy. South of the border, we
steek to HLLs. Less work, for sure. In other words...
Assembler? *Assembler*? We don' need no steenking *assembler*!
From: SW
Date: Tue, 5 May 1992 08:27:17 PDT
Subject: Just Imagine...
------- Start of forwarded message -------
Subject: Windowing Korn Shell
Date: 4 May 92 20:39:37 GMT
NEW PRODUCT ANNOUNCEMENT: APRIL 10th 1992
UNIX SYSTEM LABORATORIES ANNOUNCES THE WINDOWING KORN SHELL (tm) -
Imagine the power, speed and flexibility of UNIX(r) System
shell programming, coupled with the ease-of-use of today's
new graphical user interface (GUI) applications. Now, UNIX
System Laboratories offers the best of both worlds -- with
the Windowing Korn Shell -- WKSH(tm).
..
------- End of forwarded message -------
From: WW
Date: Tue, 5 May 92 10:05:48 PDT
Subject: Re: Operating System Similes (fwd)
Assembler? *Assembler*? We don' need no steenking *assembler*!
Yet another reason that a 2MIPs system running Tops10 out-performs
many a 30 MIPs workstation...
From: JL
Date: Wed, 6 May 92 08:36:39 EDT
Subject: This About Says It All, No?
Quite a nice signature line:
By analysis of usenet source, the hardest part of C to
use is the comment.
From: RM
Date: Wed, 6 May 1992 21:03:16 PDT
Subject: Who Watches The Watchmen?
From: PP
Date: Wed, 6 May 1992 14:29:01 -0700
Subject: Second Request: PLEASE FIX /usr/fla/mail/bin/watchdog
THIS IS SERIOUS! Last night the /usr/fla/mail/bin/watchdog
script managed to kill the texteditor process I was using!
Either fix the script or take it out of the root crontab.
I'm tired of having it take pot-shots at my processes. Of
course I do want ZMailer to continue working.
------------------------------
From: SP
Subject: Sliplogin Killed -- ZMailer To Blame?
Tonight I was using xrn across a SLIP connection when
suddenly the console message "slip0: going down" appeared
and sure enough the network connection was gone.
I then noticed that was right after a "One or more ZMailer
processes have died!" message. It seems that often when I
see that message, one of my processes dies unexpectedly.
* * * It appears that /usr/fla/mail/bin/watchdog sometimes
kills off a random process that has nothing to do with
ZMailer! * * *
Has anyone else noticed this problem? I have only seen it
on my home IPC.
[...]
From: JL
Date: Thu, 7 May 92 07:09:27 EDT
Subject: My It Really WAS A Typewriter...
But the mailer needed to do something specific to, oh, an D
to A converter.
>From a bounced mail message:
----- Transcript of session follows -----
Connected to gateway.anonymous.com:
>>> RCPT To:<
[email protected]>
<<< 550 <
[email protected]>... User unknown: Inappropriate ioctl for device
550 <
[email protected]>... User unknown
From: AB
Date: Thu, 7 May 92 22:19:22 EDT
Subject: Operating System Similes (fwd)
In response to multiple messages I have received:
ER is -not- on Unix-Haters. (At least in any way that is
apparent to the maintainers.) Of course, nothing prevents
him from sending mail to Unix-Haters, and nothing prevents
some of you from replying to his mail and CCing your reply
to Unix-Haters -- which creates the impression that ER is on
Unix-Haters. But he isn't. So stop sending me mail
suggesting that he be flushed.
From: SS
Date: Fri, 8 May 1992 11:45:30 -0500
Subject: Add A Typewriter - Kill A Unix Box
Date: Wed, 06 May 92 18:24:37 -0400
From: JH
Subject: High-Tech Software + Low-Tech Hardware == Network Failure
This network failure analysis was just posted to the
facilities bboard here at TLA ALT. I guess it illustrates a
potential risk of making a hard-copy log of all console
messages...
==============================
Date: Wed, 06 May 92 17:17:12 -0400
Subject: AFS tokens expiring
This morning from about 11:30 am to 1:00 pm users who
attempted to access afs files located on <host> would get
back an error saying that their token had expired. This
anomaly was caused by the fact that <host>'s clock was an
hour behind, so newly aquired tokens presented to its
fileserver appeared to have a start time in the future and
thus were rejected. The problem was fixed by manually
resetting the time
The clock got so far behind due to the following series of
events:
A process on <host> was writing a file into AFS which was
larger than the AFS cache on that machine. This caused the
in-kernel AFS cache manager to continiously print the
message :
" <host> vmunix: afs: cache too small: flushing active file"
Since this message was being written to a 300 baud hardcopy
console at a high interupt level, it was causing significant
delays to the rest of the system. One of the results of
these delays was that clock interupts were lost, and another
was that 'ntpd' was not given a chance to run and fix the
time skew. By the time the process acausing the problem
finished the time skew was too large for ntpd to make
adjustments, thus manual intervention was required.
From: AB
Date: Sat, 9 May 92 20:21:04 EDT
Subject: Hey Martha, Look What The Root Drug In!
I found the following message in my mailbox today:
Return-Path: <
[email protected]>
Received: from janus (janus.one.two.thr) by hoser.one.two.thr (4.1/AI-4.10)
id AA25710; Sat, 9 May 92 18:45:29 EDT
From:
[email protected] (Operator)
Received: by august (4.1/AI-4.10) id AA00106; Sat, 9 May 92 18:46:19 EDT
Date: Sat, 9 May 92 18:46:19 EDT
Subject: editor saved ``/usr/man/cat1/more.1''
Apparently-To: AB
(I wonder why this message can't have an ordinary "To:" field?)
You were editing the file "/usr/man/cat1/more.1"
at <Wed Apr 22 14:35> on the machine ``janus''
when the system went down.
I was? This is certainly news to me. Of course we're
talking over two weeks ago here, so I may have mercifully
forgotten whatever incident precipitated this. I've never
heard of the file in question, but perhaps this has
something to do with the inner workings of the `man' command
or the emacs command M-x manual-entry...
You can retrieve most of your changes to this file
using the "recover" command of the editor.
Ho ho. "The Editor" huh? I wonder which one?
An easy way to do this is to give the command "vi -r /usr/man/cat1/more.1".
This method also works using "ex" and "edit".
Ohhh that editor.... OK, just for giggles, I tried starting
up vi with this command. The first thing I learned is that
vi doesn't know about the TERMCAP environment variable --
quite a surprise to me, given the repeated claims that the
whole system of termcap kludges exists solely to support
vi... But I digress. The second thing I learned is:
"/usr/man/cat1/more.1" File not found
Oh well, I guess I should have simply ignored it...
From: RC
Date: Mon, 11 May 92 13:08:39 EDT
Subject: No Comment
$ ftp tonfro
Connected to tonfro.
220 tonfro FTP server (SunOS 4.1) ready.
Name (tonfro:ewing):
331 Password required for ewing.
Password:
230 User ewing logged in.
ftp> mget bogus*
mget bogus* not found? y
200 PORT command successful.
550 bogus* not found: No such file or directory.
ftp> quit
221 Goodbye.
From: JZ
Date: Sat, 16 May 92 18:34:12 PDT
X-Windows: Sometimes you fill a vacuum and it still sucks.
Subject: What Unix Hath Wrought
In an article JM wrote:
>
> What's wrong with turning it off in the default case, and
> turning it on, and leaving it on, until a problem recurs?
> Do you compile all of your programs with -g just so you
> can debug them if they should crash?
Why, what a SILLY idea...
From: AW
Date: Tue, 19 May 1992 18:26-0400
Subject: "Appears To" Message From G
From: RS
Date: Tue, 19 May 1992 16:14 EDT
My copy ended the same way, so it's probably ok.
I was hoping to tweak G. into using a signature, but
he's pretty set in his ways.
[Flame on! WHOOOSH!]
I'm afraid I am quite of a mind with G., being a firm
adherent of the "Klingon" school of email, whose dictum is,
"Don't greet, don't sign, just say what you have to say in
the nearest approximation to English you can manage.".
If you use signatures as a way to reassure yourself that you
got the whole message, think again -- many people add cute
postscripts after their signatures. Furthermore, in the
Un*x culture one finds extremely verbose signature blocks
that are inserted automatically by some brain-damaged piece
of mail software.
These are the electronic equivalent of license plate frames
with cute slogans on them and should be banned. At least
they should be banished to a header -- something like
"Cute-Signature: ..." which I could in extremis teach my
mail-reading program to hide from my sight.
SMTP, the protocol that mediates email on the Internet, is
guaranteed reliable end-to-end. It is a well-defined
protocol, and it is the responsibility of every Internet
mail-reading program to implement it. If characters are
being dropped, for whatever reason, it is a _bug_ and ought
to be fixed. (I do not consider the local prevalence of
some idiotic text-formatter to be a valid excuse for
mangling my text.)
However, the bug will almost certainly turn out to be in
Un*x, and therefore will be enshrined in such a way that
fixing it will require fixing other bugs in Un*x, and the
process never ends because there is no bug in Un*x so
egregious, so counterintuitive, so purely _wrong_ that some
pea-brained bozo's shell script doesn't depend on it doing
exactly what it now does.
The news that some dimwit's mail-reader handles specially lines that
happen to begin with a period, because period in column 1 is the escape
.character for the Plugh-909 parser generator that no Un*x weenie can
..do without, will only encourage me to begin more lines with periods
...in the hopes of inconveniencing these scumsuckers enough to make
::..::>>them wake up and smell the coffee.
So there.
From: RM
Subject: Synergy
Date: Fri, 15 May 1992 11:26:06 PDT
From: EK
Date: 15 May 92 13:27:39 GMT
Subject: Re: Bent Axel's - What To Do?
I'm not trying to ignore anyone who may have sent me mail
after 12pm EST Thrusday. We switched from X11R4 to X11R5
this afternoon and my mailer doesn't want to reply to
anyone. Posting here seems to work fine but everything else
is messed up.
G'day all.
From: RM
Date: Mon, 18 May 1992 19:31:07 PDT
Subject: Don't Grep Without /dev/null
Have you ever wondered why when you type m-x grep "-i cretin /vmunix"
Emacs actually runs the command "grep -n -i cretin /vmunix /dev/null"?
I'd always sort-of thought it was to avoid the screw case of
having the user ask to do "grep -i cretin" in which case the
pointy-headed program would assume that its input should
come from standard input and Emacs would wait indefinitely
for grep to do nothing. (Of course, it should actually be a
wrong-number-of-arguments error, if I wanted input from
standard input I would have said "/dev/stdin", except of
course there is no way to name standard input in unix, even
though Everything Is A File.)
Well, it turns out that it does avoid this screw case
(coincidence or design -- you be the judge!), but, as one
would expect in the Wonderful World of Weenix, it has a
another side-effect.
"And that's not an unintended side-effect, that's a feature!"
I was trying to search a large number of files for a text
string. Now, not having any sort of m-x List Callers
facility, I was reduced to text-search. (Have you noticed
that ordinarily reasonably people these days seem to refer
to text-search as "grep"? Perhaps this is much the as one
using the generic term "Kleenex" to refer to the things with
which one wipes up the parts of one's brain which have
dribbled out all over one's keyboard.)
First of all, I look briefly at the grep "man" page to
determine which combination of switches du jour I'll want.
Remember that man pages are praised by unix cretins for
their terseness and the simplicity with which one may
immediately reach the Important Information about what weird
goulash of switches a particular command requires.
I see that for my afternoon's scheduled grepping I do want
"-i" (real men are case-insensitive) and "-n" (precede each
line by its relative line number in the file."
I see that I definitely DON'T want "-h" ("Don't display
filenames.") as I expect a large amount of output and DO
want to know in which particular file the string-matches
were found.
Now, because I was dealing with something larger than the
usual unix weenie 10-file system, I immediately exceeded the
shell's built-in command-line limit.
"No problem", say I, "instead of
grep -i -n version *.ps */*.ps */*/*.ps etc
(ever notice how unix has no wild-inferiors directory
wildcard syntax?) I'll just run grep on each file, using
some magic bullshite incantation I'll steal from somebody
else who did this."
So I end up writing a shell script which does
foreach f (`cd ../foolib; find . -name "*.ps" -print')
grep -i -n version ../foolib/$f
end
and so forth.
After exactly twelve attempts to get the above syntax
correct (and moving from to /bin/sh and back to /bin/csh in
the process as I could find marginally better documentation
on the weird iteration constructs of the latter) and lots of
cursing of content-free error-messages like "Badly placed
()'s", I finally get the script to run.
As output I get a zillion lines of the following type
3:%%Version: 1.0
182: % generated this text. Perhaps the version-stamp for the blorp code,
3:%%Version: 1.0
3:%%Version: 1.0
239: { .interpreter print ( v) print version =only
45:% easier-to-debug versions of some procedures.
87:{ % If we aren't in debugmode, here is a version of the above that does
32:% _version_ int for future backward compat. - currently 0
1215: (, _version_ int NOT NULL\)) foocmd
and so forth, and so on, and so on.
Note that even though I know the exact line number in which
each "version" string was located, I have absolutely no
information about which files in the deep and broad
directory tree actually contain those line numbers.
Well, I fritter away some more idle minutes running another
ten or so iterations of running my shell script, adding and
removing switches, carefully checking that no commands are
aliased, that my search path is correct, that I'm actually
running grep on the correct files and that I am really
invoking grep without the "-h Do not display filenames"
switch. I check the non-setting of "-h" many times, since
having it set would produce exactly the sort of lossage I
was experiencing.
Finally, about to tear my hair out, I happen to type "c-L"
in the Emacs buffer in which the grep options are displayed.
This recentres the window such that three additional lines
appear at the top of the buffer's window. I read
----------------------------------------------------------------------
want the filename to appear, use /dev/null as a second file
in the list.
----------------------------------------------------------------------
ARRGGGGGGGGGGGHHHHHHHH.
I scroll back and read the whole screen:
----------------------------------------------------------------------
When any of the grep utilities is applied to more than one
input file, the name of the file is displayed preceding each
line which matches the pattern. The filename is not
displayed when processing a single file, so if you actually
want the filename to appear, use /dev/null as a second file
in the list.
OPTIONS
-b Precede each line by the block number on which it was
found. This is sometimes useful in locating disk block
numbers by context.
-c Display a count of matching lines rather than
displaying the lines which match.
-h Do not display filenames.
----------------------------------------------------------------------
The iron spike of enlightenment finally punches through into
my cerebellum "... ... ... so... so... so... you
mean... there's ANOTHER reason why Emacs always appends
/dev/null to its m-x grep command-line! ... Well f__k me
harder again and again! ... errgghhhh... FEELINGS are
cascading over me!!!"
Incidentally (or not -- YOU be the judge!) this is EXACTLY
the kind of bullshite which makes the "ls" command lose so
badly (and which, incidentally, contributes to every unix
FTP server flagrantly violating the FTP spec): the default
filename argument for "ls" (the current directory) is
totally different from specifying "ls * .*" (which one might
think would be the same thing) because bloody cretinous "ls"
descends into subdirectories which are specified on the
command-line, even those without a trailing "/" (even if
unix had some command-line convention to discriminate
between "the directory" and "the files of the directory",
which it doesn't) and even those which are a result of a
wild-card expansion (even if unix commands knew anything
about wild-cards, which they don't.)
(I won't even start to rant on the matter of needing ".*" in
addition to "*" to get all of the files in a directory. I
won't. I won't. I won't.)
Anyway, I now feel so much better for knowing why Emacs does
what it does.
I'm now a grep wizard! I can probably get a job as a
high-powered unix system administrating consultant, the sort
who just recently hosed three day's of my mail.
From: SS
Date: Thu, 28 May 1992 14:53:57 -0500
Subject: Imagery
How to design a book cover:
-------------------
From: GS
Subject: fortran images [for cover design]
From: <name removed to protect the innocent>@think.com
Date: Mon, 25 May 92 16:51:53 EDT
please free associate on fortran.
what are its formal characteristics? informal? how
is it structured?
i assume it is regular. (it is, isn't it?)
if you had to draw ten pictures of it, what would the
ten pictures be? if it were a color, what color
would it be? what texture is it? what shape is it?
how many pieces are there in it? is it solid? is it
a regular shape? can you see through it? is it
layered?
A solid wall of cinder blocks, painted institutional gray,
with four of them missing in random locations. Through the
four holes you can see a tangle of wires. One of the holes
has been partly covered with a circular piece of pegboard.
Three pink ostrich feathers have been hot-glued to the wall
in a desperate attempt to create a festive mood.
A programmer, as Sisyphus, pushing a huge square stone up
Mt. Xinu. Despite the fact that it is square, it keeps
rolling back down anyway.
A drab brown metal box with rounded edges and corners--the
1950's look. Large, clunky typewriter keys that you have to
PUSH (they go "*chonk*") and they produce only uppercase
letters. Beside it, an operator limply holds a half-empty
box of cards and gazes in despair on the thousand or so that
have fallen all over the floor.
Fortran is the color of compatibility at all costs. Fortran
has the texture of sand and ball bearings, mixed. It is
regular until you look at it more closely. It sounds like
Phyllis Diller singing "Strawberry Fields Forever". It
shines like purple Jell-O.
Does this help?
From: LK
Date: Mon, 1 Jun 1992 12:19:12 PDT
Subject: Re: Imagery
Continuing in the Unix mail tradition of adding tangential
remarks, I've always thought that if Lisp were a ball of
mud, and APL a diamond, that C++ was a roll of razor wire.
From: SS
Date: Mon, 1 Jun 1992 17:36:10 -0500
Subject: Write Your Bug Reports In vi
Y'know, reading bug reports from unix weenies is like
listening to the disemboweled android in Aliens trying to
speak while choking on its own synthetic blood.
I wonder who was the rocket scientist who implemented cut
and paste for X windows. Oh yeah, I remember now - cut and
paste of plain ascii text is a HARD, UNSOLVABLE PROBLEM.
------------------------
Date: Mon, 1 Jun 1992 16:36:24 -0400
From: AM
Subject: Mach Bug Problme em
Hi !
My name is Andres Monterrosas and I am installing MACH 2.5 i in a Sun 350 at UM /50 at
UMASS-Lowell. I nee The operating With thw e operating system SUN unOS b 4.1.1. I have a problem when
I am doing step 16: Fsck k the root partition )( (fsck -p /dev/sd0a) and the
error message that I received is
BAD SUPER BLOCK: TRASHED VALUES IN SUPER B;\ BLOCK
USE -b OPTION TO FSCK TO SPECIFY LOCATION OF AN ALTERNATE SUPER-BLOCK TO SUPPLY
NEEDED INDO\\ FROMA ORMATION.
Then I tried with all the op alternate super-b;l locks and A I received the message:
CG 0:BAD MAGIC NUMBER
UNEXPEXTED XPECTED INCONSISTENCY; RUN fsck MANUALLY
Thee refore, I rebbot oot and not the problem is repetea ated again. I want to mention t
I do not Before this NOTE:
Beforre re this step, I did installboot /mnt/noot boot bootsd /dev/sd0a rsd0a.
Any information you can give me is welcome. I would appreciate your help.
ThaNKS\\\\\\\\ anks in davanced to my request ad C C C C C C C C C C C C C C C Cvanced to my request.
Mail: amonterr
[email protected]
Andres Bye. .
From: DC
Date: Mon, 1 Jun 92 18:12:52 -0700
Subject: Bizarre Incompatibility
Overheard:
``Yeah, there's this incompatibility problem, that they
have signed booleans and we have unsigned booleans. But
I think I know how to program around it.''
Signed booleans???
From: JL
Date: Mon, 1 Jun 92 21:16:22 EDT
Subject: Re: Imagery
Continuing in the Unix mail tradition of adding
tangential remarks,
Likewise,
I've always thought that if Lisp were a ball of mud,
and APL a diamond, that C++ was a roll of razor wire.
That comparison of Lisp and APL is due to Alan Perlis - he
actually described APL as a crystal. (For those who haven't
seen the reasoning, it was Alan's comment on why everyone
seemed to be able to add to Lisp, while APL seemed
remarkably stable: Adding to a crystal is very hard, because
you have to be consistent with all its symmetry and
structure. In general, if you add to a crystal, you get a
mess. On the other hand, if you add more mud to a ball of
mud, it's STILL a ball of mud.)
To me, C is like a ball. Looked at from afar, it's nice and
smooth. If you come closer, though, you'll see little
cracks and crazes all through it.
C++, on the other hand, is the C ball pumped full of too
much (hot) air. The diameter has doubled, tripled, and
more. All those little cracks and crazes have now grown
into gaping canyons. You wonder why the thing hasn't just
exploded and blown away.
BTW, Alan Perlis was at various times heard to say that
(C|Unix) had set back the state of computer science by
(10|15) years.
From: RS
Date: Mon, 1 Jun 92 23:00:45 EDT
Subject: Re: Bizarre Incompatibility
From: DC
Overheard:
``Yeah, there's this incompatibility problem, that
they have signed booleans and we have unsigned
booleans. But I think I know how to program around
it.''
Signed booleans???
I'll betcha it has something to do with whether you consider
1 to be t or nil. It always struck me as strangely
appropriate that in C, 0 usually means success.
From: DH
Date: Tue, 2 Jun 92 10:33:51 EDT
Subject: Write Your Bug Reports In vi
Really, this looks like most of the mail I get from weenix
unies. Are you now claiming this is due to buggy
_software_?
Date: Mon, 1 Jun 1992 17:36:10 -0500
From: SS
Y'know, reading bug reports from unix weenies is like
listening to the disemboweled android in Aliens trying
to speak while choking on its own synthetic blood.
I wonder who was the rocket scientist who implemented
cut and paste for X windows. Oh yeah, I remember now -
cut and paste of plain ascii text is a HARD, UNSOLVABLE
PROBLEM.
------------------------
Date: Mon, 1 Jun 1992 16:36:24 -0400
From: AM
To:
[email protected]
Subject: Mach Bug Problme em
Hi !
My name is Andres Monterrosas and I am installing MACH 2.5 i in a Sun 350 at UM /50 at
UMASS-Lowell. I nee The operating With thw e operating system SUN unOS b 4.1.1. I have a problem when
I am doing step 16: Fsck k the root partition )( (fsck -p /dev/sd0a) and the
error message that I received is
BAD SUPER BLOCK: TRASHED VALUES IN SUPER B;\ BLOCK
USE -b OPTION TO FSCK TO SPECIFY LOCATION OF AN ALTERNATE SUPER-BLOCK TO SUPPLY
NEEDED INDO\\ FROMA ORMATION.
Then I tried with all the op alternate super-b;l locks and A I received the message:
CG 0:BAD MAGIC NUMBER
UNEXPEXTED XPECTED INCONSISTENCY; RUN fsck MANUALLY
Thee refore, I rebbot oot and not the problem is repetea ated again. I want to mention t
I do not Before this NOTE:
Beforre re this step, I did installboot /mnt/noot boot bootsd /dev/sd0a rsd0a.
Any information you can give me is welcome. I would appreciate your help.
ThaNKS\\\\\\\\ anks in davanced to my request ad C C C C C C C C C C C C C C C Cvanced to my re
quest.
Mail: amonterr
[email protected]
Andres Bye. .
From: RM
Date: Tue, 2 Jun 1992 16:11:56 PDT
Subject: "3D: Adds a New Dimension To Filesystems -- Time"
You'll remember unix "gurus" flaming about how evil and
repulsive and wrong file-systems with versions are (about as
wrong and evil as they claimed "shared" libraries to be, as
an example.)
More way retro progress from the avant-garde boys at the
phone company.
Oh, and now you know why your Sun loses your work all the
time -- its that "translucent" filesystem.
From: CC
Newsgroups: comp.arch,comp.unix.misc
Date: 2 Jun 92 21:25:43 GMT
Subject: Re: User-Level File Systems
In an article BS writes:
|> In another article DS writes:
|> > In still another article PS writes:
|> > >[SCCS file system]
|>
|> > Bell Labs has done this. They call it the "3D" or
|> > "versions" file system.
|>
|> Does it handle release control?
|>
|> More to the point, Bell Labs has done EVERYTHING but you
|> can't get it out of them for love nor money. A user-level
|> file system interface (like people have told me DomainOS
|> had) is pretty much a requirement to get this stuff to the
|> masses.
The original 3D filesystem done by Dave Korn (of ksh) and
Phong Vo (of systemV curses, and systemV fast malloc) (Glenn
Fowler (of nmake) might be in there too) works _entirely_
with shared libraries. The first implementation of it used
a new filesystem type in the kernel (running on a 3b type
machine), but once they got SunOS style shared libraries,
they went that way.
There have been numerous spin-offs of their work (mostly
based on a USENIX talk they gave on the subject) which
include Sun's translucent filesystem and the 3D filesystem
in Plan 9.
The fundamental concept of 3D is that ... represents the
previous version of the current directory. In other words,
when you create a new version of a directory, all the files
in old version appear to be in the new version as well, but
when you write new copies of those files, the new copies
don't appear in the old version of the directory. Think it
as if you created the new version by making a bunch of
sym-links to the old versions, and then destroyed a sym-link
before writing a file.
They're currently working on newer stuff which uses has
security/control/concurrency/etc features, but looks mostly
the same to the casual user.
From: JZ
Date: Tue, 2 Jun 92 18:29:41 PDT
Subject: Re: "3D: Adds A New Dimension To Filesystems -- Time"
Wow, just imagine all the code that's going to break because
"..." is neither "." nor "..". The mind reels...
From: SS
Date: Wed, 3 Jun 1992 11:02:51 -0500
Subject: Re: "3D: Adds A New Dimension To Filesystems -- Time"
OK, let me get these new improved directory links straight.
... = previous version
.... = shorthand for parent of the previous version
.., = next version
..., = parent of next version
..... = previous version of parent
...,. = next version of parent
.;-+. = header files of prereleased parent of next
previous version, but without binaries (BSD
only) or strictly with binaries (V only)
It's only a matter of time before all possible smileys
become perfectly acceptable pathnames.
From: CM
Date: Thu, 4 Jun 92 11:40:34 EDT
Subject: Pretty Pathetic
From: JR
Subject: WAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA FEEEL GOOD!
Date: 29 May 92 09:27:42 GMT
[...]
Even *I* used to have slack. On a much smaller scale of
course. I used to get Usenet for free, which was slightly
slackful. I am working on getting a friend to setup another
free Usenet access board, which will hopefully raise ever so
slightly my fallen slack levels.
[...]
From: LL
Date: Thu, 4 Jun 92 11:19:11 -0700
Subject: "Remember Zorg From The Early Days Of Unix?"
Ahh, I just feel like shaking their little heads while
grabbing a 200dB megaphone and politely informing them that
THE NAME ISN'T ZORG like some bletcherous cyborg from the
brainwashing television cartoons, nor DOES IT HAVE ANY
REMOTE CONNECTION to the KLEENEX of operating systems that
they happen to be using on their underdesigned workstations.
Get in to your TINY LITTLE HEADS that there are other things
than UNIX out there. Study your HISTORY for Gads sake!
Don't just look ten inches in front of your noses and
believe that the world ends there.
OK, so I received this message just after having read a
column in a so-called "professional publication" that spent
a whole page on discussing the boundaries between
worktations and PCs. MS-DOS here, UNIX there, OS/2 in
between. Then I read "With the introduction of NT, the
answer to 'When is a PC a workstation?' is moot". Like, who
cares what it's called anyway; just give me something I can
work with! Besides, I'm really SICK and TIRED of reading
about how some future, unreleased and most often not even
conceptually defined product is going to save the world and
make everything else obsolete. And then people talk about
it as if it already was reality. "Well, yeah, you may do
distributed objects/3D graphics/multimedia mail today but
Taligent/Windows NT/Solaris 2.0 will make all that better
tomorrow." Yeah, really, just like ACE. And people believe
this? ARGH!
I feel better now, I really do.
Vidarebefordrat:
From: AC
Date: Thu, 4 Jun 1992 07:01:30 PDT
Subject: Good Grief!
Quote from a CS3 newsgroup. What on earth are they teaching
the children these days?
"I have a vage recollection of a text based game devised
in the early days of Unix called Zorg (or something like
this)"
I really feel like an old fart now.
T
----
This explains a lot about me. I thought it was the heavy
drinking, the late hours, the barking mad women, the lying
around in bed reading novels and eating Nescafe out of a jar
with the spoon. But it's because of the Mac.
From: SW
Date: Fri, 5 Jun 1992 08:17:03 PDT
Subject: Solving Problems The Unix Way
------- Start of forwarded message -------
From: AL
Date: Fri, 5 Jun 1992 05:04:46 GMT
Subject: Re: Coping With NFS Failures
In an article VM writes:
|> The following problem bites me from time to time. I'd be
|> interested in any suggestions about dealing with it. My
|> ~/Mail directory is NFS mounted. For various reasons I
|> access it from a remote node. Once in a while there is a
|> LAN hiccup which causes an NFS problem. The way this
|> manifests itself, is that when an MH command is run it
|> doesn't find .mh_profile. Therefore it decides to create
|> a new one. However, this ends up destroying my old
|> profile (because it overwrites it). Is there any way for
|> MH to cope with this bug? Or should I just create a hard
|> link to .mh_profile under some other name? Of course then
|> there's the problem of finding out that this happened.
Just set the permission on the .mh_profile to read only. The
attempted creation then fails.
e.g. chmod 440 .mh_profile
------- End of forwarded message -------
:WQwq!
From: AB
Date: Fri, 5 Jun 92 12:41:30 PDT
Subject: Workstations
If a train station is where a train stops,
then a workstation is where the work stops.
From: SS
Date: Mon, 8 Jun 1992 16:45:55 -0500
Subject: Security? No Thanks, I've Got Unix!
From: DA
Date: Mon, 08 Jun 92 16:04:22 -0400
Subject: ATTENTION USERS OF /U2
Due to a bug in gtar, for a period of time all directories
and subdirectories on /u2 were in permission mode
"drwxrwxrwx", which is very insecure. I have changed all
directories and subdirectories on /u2 to be in mode
"drwx--x--x", which is much more secure. If you want your
directories to be less secure, you will have to change them
back. We are sorry for the inconvenience.
|>..... /\......
System Programming Group
From: SM
Date: Tue, 9 Jun 1992 10:28-0400
Subject: Re: Security? No Thanks, I've Got Unix!
Date: Mon, 8 Jun 1992 17:45 EDT
From: SS
From: DA
Date: Mon, 08 Jun 92 16:04:22 -0400
Subject: ATTENTION USERS OF /U2
...
|>.... /\.....
System Programming Group
I especially like his signature, which I initially dismissed
as the usual Unix trashing of data, but then realized are
gibberish characters masquerading as uppercase alphabetics.
From: RK
Date: Tue, 9 Jun 92 10:56:36 EDT
Subject: Long-Gone Nemesis...
From: MH
Date: Thu, 28 May 92 03:47:30 GMT
Subject: Where Windows/NT *REALLY* Came From
For some time now I've been puzzled by the named
"Windows/NT" and how it was derived.
Oh I know that supposedly it stands for "new technology".
Recently a new conspiracy theory was brought to my
attention. Do you remember the mess with the choice of
"HAL" in the movie 2001? If you incremented each letter
forward one you came up with "IBM". Of course they denied
everything.
Well someone pointed out today that if you took "VMS" and
incremented each letter forward by one you get "WNT".
Chalk one up for Dave Cutler. I hate to blow the cover on
this one so early. I'm certain that everyone involved will
deny this and claim this is just a coincidence.
This is why the Unix guys all hate it so much. Clearly
their subconscious is flashing alarm signals at them, but
they don't really understand why. Well now you know.
And I thought they just wanted to dump out corrupted
superblocks and inodes for the rest of their lives.
--
--------
NO DAD!! You're supposed to type it in with downer case letters!
From: CM
Date: Tue, 9 Jun 92 12:21:36 EDT
Subject: Small And Consistent Interface, Bah!
So I'm doing this tcp/ip implementation and my advisor and I
agree that we should be binary compatible with bsd syscalls
[this is kind of a traditional move around here otherwise
people tend to ignore your work because recompiling is too
difficult]. "How are you going to handle ioctl's?" he asks.
"Hmm," I say, "I mapped out how I'd handle every socket
syscall except the ioctl's but how hard could that be?" Heh
heh heh.
Not only do you have to handle ioctl's which get called
using the ioctl syscall. You also have to handle the
ioctl's that get called via the fcntl syscall and the
setsockopt syscall. Oh yeah, and then there are some fcntl
ioctl's that can be called by the dupx syscalls. [Let me
guess, they named these syscalls dup and dup2 because they
are (a) completely redundant and (b) you are one if you use
them.]
Did I forget anything?
From: AD
Date: Wed, 10 Jun 92 19:52:27 EDT
Subject: Unix Corrodes Hardware Design At Sun
I can see the unix brain-rot creeping all over Sun, now.
I have occasion to be in the middle of the design
for an Sbus card (you know, that "Open" bus in sun unix
boxes these days -- if you're lucky, when you receive your
machine sun has condescended to actually leave one of them
open for you to put something of your own (or someone
else's) into).
Sun, seeing the need for high-level hardware
modelling in today's complex systems has developed a set of
models in Verilog (a popular hardware description language
due to the fact that it looks much like C....) for driving
and monitoring the sbus hardware. However, it's quite clear
that the unix mindset which the Sun engineers have become
accustomed to has crossed over into their hardware design
and modelling.
First, they provide a model that only works with a
special patch to Verilog (which they don't bundle in with
their hardware model). Now this patch actually deals with
the fact that Verilog inherits some braindeath from C and
apparently you can't get at some of the information Verilog
is storing around unless you go outside of Verilog to do it.
Sun's routines model various sbus transactions, but
they don't give you an actual handle on the data to, say,
check if it's correct.
Just like their network code, there are large
portions of this code which have clearly never been
used/tested. To check timeout on the bus, they look to see
if a certain *8* bit counter has counted up to 256. But
that's ok, if the counter was big enough, then you'd
discover that they actually didn't have any part of the
model sitting around ready to model the things which are
supposed to happen when timeout occurred (after all, since
the counter never reaches 256, the bus never times out ---
why have useless code around when it's not needed...).
No wonder they've had so much troubles with
SuperSparc....
From: SZ
Date: Thu, 11 Jun 92 01:13:34 EDT
Subject: Environment variables are a crock.
Unix sometimes reminds me of the Baby Dinosaur in "Dinosaurs":
"Gotta love it! Gotta love it!"
NOT!
-------------------------------------------------------
From: JK
[9434]
[email protected] (
[email protected]) Loki Bugs 06/10/92 09:21 (29 lines)
From: MG
Date: Wed, 10 Jun 92 09:21:41 EDT
System name: Calvin
Type and version: KN01 7.3P (2 update(s) to same version)
Display type: PMAX-MFB
What were you trying to do?
rlogin to CALVIN.dot.dot
What's wrong:
CALVIN is running 7.4, and appears to have a bug.
Instead of displaying the message:
zwgc: Unable to open X display -- disabling X driver.
zwgc: To receive Zephyrgrams, (type `/usr/loki/bin/zwgc
-ttymode').
it runs a zwgc with a DISPLAY :0.0
This causes zephyrs to pop up on the idle login screen,
which shouldn't be happening. This *DOES NOT* occur on
7.3 machines. This bug is reproducable.
What should have happened:
It should have displayed the warning message and not
run a zwgc. (CERTAINLY not on :0.0)
Please describe any relevant documentation references:
--[9434]--
This occurred because someone started inetd by hand on
podge with the DISPLAY environment variable set, and your
rlogin process therefore inherited the variable setting.
People who find it necessary to kill and restart inetd on
workstations should be careful when doing so of the
environment they propogate to inetd when they restart it.
I have killed and restarted inetd on podge without DISPLAY set.
IS/Loki Quality Assurance
From: AD
Date: Thu, 11 Jun 92 11:15:04 EDT
Subject: [End of an Era]
I couldn't settle on a single title to tag this with:
Unix authors see the light, throw in the towel
You mean, they were having fun with this?
The sad part is, the author makes the announcement
sound like the world is losing something worthwhile.
------- Forwarded Message
Date: Thu, 11 Jun 92 10:53:51 -0400
From: MR
Subject: End of an Era
It was announced last night at the BSD BoF here at Usenix
that the Computer Systems Research Group will be closing up
shop after BSD4.4 is released later this year. They've been
having trouble with funding, too much fighting and political
manouvering, and it just isn't fun anymore. Mike Karels has
already left to work for BSDI, Keith Bostic (who just got
married) will be moving to the Boston area.
On another front, you can get complete source (commercially
supported, no AT&T licvense required) to a working BSD4.3
system for 386/486 from BSDI for $1000.
------- End Forwarded Message
Date: Fri, 12 Jun 92 15:59:28 PDT
From: JA
Subject: [Something Fun]
Received this gem in my mail file, forwarded from someone
else who thought it amusing.
Date: Fri, 12 Jun 92 14:27:55 EDT
To: JI
Subject: Seen In Netland
...
The server does not respond to requests from users named
"root", "system", "daemon", or "mailer". This is to
prevent mail loops. If your name is "Bruce Root" or "Joe
Daemon", and you can document this, I will happily
rewrite the server to remove this restriction. Yes, I
know about Norman Mailer and Waverley Root. Norman
doesn't use netmail and Waverley is dead.
...
Uh huh. Just why is it that Unix needs special names for
users? Aaah! Give me back the old tops20 days when
privileges were granted to individual users of arbitrary
names! Yeah, it starts with some defaults, but you don't
need 'em!
Personally I'm really tired of all the files in the universe
being written by "root". No way to easily assign blame for
horrible lossage caused by someone's fatfinger...
Date: Fri, 12 Jun 92 22:36:19 -0400
From: DH
Subject: Re: [Something Fun]
They need to deal with Rex Root, system manager of
a pile of systems at University of Maryland the last
time I checked... He does have a problem with people
sending mail to root, rather than rroot or rex...
From: CM
Date: Sat, 13 Jun 92 12:40:37 EDT
Subject: Re: [Something Fun]
Date: Fri, 12 Jun 92 14:27:55 EDT
To: JI
Subject: Seen In Netland
The server does not respond to requests from users
named "root", "system", "daemon", or "mailer". This is
to prevent mail loops. If your name is "Bruce Root"
or "Joe Daemon", and you can document this, I will
happily rewrite the server to remove this restriction.
Yes, I know about Norman Mailer and Waverley
Root. Norman doesn't use netmail and Waverley is dead.
There are about 25 people named "Root" in the Pittsburgh
white pages. No Mailer's or Daemon's, however.
From: SS
Date: Tue, 16 Jun 1992 13:49:12 -0500
Subject: Mailer Headers From Hell And/Or ATT
Check out this mailer header... this is the version *after*
it was been stripped of the usual bogosities by my mail
reader (Eudora on a Mac).
Notice the "End-of-Header" header halfway through the header.
Notice the ">To:" field in addition to the "To:" field.
Notice the hideous mix of @,%, and ! in the addresses.
And what, pray tell, would "End-Of-Protocol" mean?
-----------------
>To: internet!uni.xha.te!pseudo
Date: Tue Jun 16 13:02:14 EDT 1992
Mts-Message-Id: <lizard1681700080>
Ua-Content-Id: <lizard1681700080>
End-Of-Header:
Email-Version: 2
Subject: Accessing Zebu
Ua-Message-Id: <lizard1681700080>
To:
[email protected]
End-Of-Protocol:
Content-Type: text
Content-Length: 61
Thanks for the info!
From: RC
Date: Thu, 18 Jun 92 10:03:05 EDT
Subject: Pretty Ftp Behavior
Very nice. First it prints a cryptic message (netout:
broken pipe), then it tells me that the service is not
available, and then it tells me that it transferred some
portion of the file. In fact the remote filesystem was full
when this happened. Is that too difficult for it to figure
out?
$ ftp brandy
Connected to brandy.
220 brandy FTP server (SunOS 4.1) ready.
Name (brandy:sierra):
331 Password required for sierra.
Password:
230 User sierra logged in.
ftp> send /etc/termcap testdata
200 PORT command successful.
150 ASCII data connection for testdata (141.162.1.57,2774).
netout: Broken pipe
421 Service not available, remote server has closed connection
local: /etc/termcap remote: testdata
49160 bytes sent in 0.43 seconds (1.1e+02 Kbytes/s)
ftp> quit
From: SS
Date: Thu, 18 Jun 1992 14:24:37 -0500
Subject: Our Intelligence Community
You know, the NSA has always kind of scared me, but not the
way you'd think. Here's why (from RISKS, of course):
------------
Date: Wed, 17 Jun 92 14:55 EDT
From: FC
Subject: Two wrongs make a right
Those of us who are aware that denial results when the
output queues for peripherals overrun are aware that it can
be devastating, but there are also those of us who take
advantage of it as if it were a feature. Here is what
happened to me today.
On a 3B2, the system backups and restoration
program does not allow you to restore information to
different directory structures than it was backed up from
without great difficulty. I happened to have over 9,000
files to restore to a system, and they were backed up from
"/v", but the system they were being restored on had only a
"/u" it would fit on. (These are Unix subdirectories). As
a result, I essentially had to do the restore to a newly
created "/v" in the root file system, which did not have
enough file space available to do the entire restore. I had
a plan - As the tape was restored, I would copy disk-to-disk
and delete the incoming files after copying them. I have
done this "race" before, and I knew that I had to transfer
out at a rate high enough so that the root file system would
not overrun - which is to say, I had to beat the incoming
tape transfer with disk to disk transfers. Of course the
tape in streaming mode operates faster than the disk I was
using, so in the end, it was helpless because it takes two
disk accesses to move a file from one disk to another, but
only 1 access to get a new file from the tape. I tried
putting in multiple transfer processes at high priority, but
of course, the DMAs always won from the tape to the disk.
The solution I used (when the available space
began to get critical) was to halt output on the console!
Hard to believe it works? Of course it does. The tape
transfers produce a dot on the screen for each of the files
transferred in, and by pressing <ctrl>s (stop output) I was
able to block the tape transfer process after only a few
hundred more files are transferred. By watching the disk
space, stopping the console output to block tape transfers
when space got too low, and continuing output when more
space was created by the transfer to the second disk, I was
able to complete the job.
The point of this insanity is that as a practical
matter, there are times when knowing how to cause denial of
services can be a very useful part of systems administration
- especially when we can do it so selectively. The title of
this piece indicates that by knowing about how to break a
system, I was able to compensate for one flaw in the system
by exploiting another flaw - hence, 2 wrongs made a right!
P.S. I am interested in other stories where known holes
were used to compensate creatively for other known holes.
It is my contention that most of the best systems
administrators and systems programmers know about and
exploit these sorts of things all of the time, and that
without these flaws, we would really have to design systems
right - otherwise, we would never be able to make up for the
wrongs with other wrongs.
From: SG
Date: Thu, 18 Jun 92 16:47:48 EDT
Subject: Re: Pretty Ftp Behavior
UNIX in general doesn't do well when a filesystem gets
filled.
From: RS
Date: Thu, 18 Jun 92 17:48:35 EDT
Subject: Apology For Crashing Mueslix
I accidentally crashed mueslix today, and I wasn't even
logged in to it.
Seems that Sun-4s (not 4cs or 4ms) that have ipforwarding
turned on (ie, are being used as routers) will panic with an
mclput message (even if the mclput patch is installed) if
they see an ICMP echo request packet with the loose source
route option turned on. But they forward the packet first
for the next guy to enjoy, too. A friend of mine at PSU
managed to crash 3 4/370s with one ping command.
If you want to annoy someone who's too cheap to buy a router, you
could put this in your crontab...
<sigh>
From: SG
Date: Fri, 19 Jun 92 16:56:50 EDT
Subject: Re: Pretty Ftp Behavior
Begin forwarded message:
Date: Fri, 19 Jun 92 16:55:28 EDT
From: SG
Subject: Re: Pretty Ftp Behavior
Several people complained about this message.
I had actually sent a much longer message, but my ^&&*%*%
UNIX mailer cut off the rest of the message.
It also cut off the rest of about 20 other messages that I
sent out.
I hate UNIX.
Begin forwarded message:
From: AB
Date: Fri, 19 Jun 92 16:43:36 EDT
Subject: Re: Pretty Ftp Behavior
From: SG
Date: Thu, 18 Jun 92 16:47:48 EDT
UNIX in general doesn't do well when a filesystem gets
filled.
Error: Insufficient vitriol in message to unix-haters.
I'll leave it up to you to figure out what to do about this
transgression.
From: WA
Date: Sun, 21 Jun 92 21:37:52 EDT
Subject: Filesystems That Don't Do Well
A recent posting:
"UNIX in general doesn't do well when a filesystem gets
filled."
Excuse me, I don't understand what it means for a file
system to "do well" or "not do well". When it comes to
filesystems, or other software in general, but especially
filesystems, there are only two concepts in my vocabulary:
to be CORRECT or to be BROKEN. :-)
From: JL
Date: Mon, 22 Jun 92 09:37:51 EDT
Subject: Bugs Is Bugs
The following was posted by a system manager at a site I
use.
Now, we all know that software has bugs. On every system.
But Unix and X bugs are somehow different. Stronger. More
distressing. More consistently dumb. More clearly based on
a programming philosophy that says "oh, no one would ever
want to do that. After all, *I* never want to do that."
Somehow, these just seem to scream UNIX! X! at me.
I had some complaints about IslandWrite/Paint/Draw. Based
on them I have updated the man pages for both that software
and Wingz, to explain some setup issues. Please see the man
pages for details. Here are the issues:
1. Island software causes the X server to exit, when on a
color display. It turns out that twm (the window manager)
coredumps. The way X is designed, if you lose the window
manager, X exits. We are about to start moving from X11R4
to X11R5, a somewhat newer version of X. The version of twm
in X11R5 does not have this problem. Thus the man page
recommends that you change you path so that you get the
X11R5 software. This will not take effect until we have the
X11R5 core distribution on our systems, which should happen
by the middle of next week.
2. Island software, particularly IslandPaint, appears to
hang the machine on startup. It isn't actually hanging the
machine. It's just causing it to page very heavily for a
very long period of time. The problem is most noticable on
color displays with small memory. It appears the the
software is constructing the file menu for the current
directory. It does this before putting up the first window.
Unfortunately they are using disasterously slow code to
construct the menu. It appears to be N**2 in the number of
files. If you have a very large directory (several hundred
files -- this may be a problem only for staff), you may see
this. If so, we suggest creating a subdirectory for your
Island files, and cd'ing to it before starting the Island
software.
From: RC
Date: Mon, 22 Jun 92 09:41:39 EDT
Subject: More Pretty Ftp Behavior
In Unix, the operating system from the Bizarro world, "quit"
means "yes".
$ ftp lancet
Connected to lancet.
220 lancet FTP server (SunOS 4.1) ready.
Name (lancet:midif):
331 Password required for midif.
Password:
230 User midif logged in.
ftp> mget ti*
mget ticker.1? quit
200 PORT command successful.
150 ASCII data connection for ticker.1 (141.162.1.57,4175) (8179 bytes).
226 ASCII Transfer complete.
local: ticker.1 remote: ticker.1
8408 bytes received in 0.043 seconds (1.9e+02 Kbytes/s)
ftp> quit
221 Goodbye.
$ ls -l ticker.1
-rw-r--r-- 1 midif 8179 Jun 22 09:00 ticker.1
$
From: AR
Date: Mon, 22 Jun 92 11:45:24 EDT
Subject: Let Me Tell You:
Upon setting establishing a dial up connection, I found that
when scrolling one line in a smallish half window emacs
buffer - the summary window for reading news using gnus -
would redraw all the lines, instead of scrolling the buffer
and just drawing the newly exposed line (like any sane
machine would do).
This annoyed me.
Step 1 into hell: Lets look at the Termcap entry I'm using
and the termcap man page (which of course is in section 5,
which I can't access - simply - using emacs).
Step 2 into hell: Lets actually try to modify the termcap
entry. Of course some of the entries in the termcap aren't
documented in "Termcap(5)". Hmm, perhaps we'll fiddle with
the delay entries for various capabilities - explain that
redrawing is MUCH SLOWER THAT SCROLLING DAMNIT EXCEPT WHEN
YOU SCROLL 30 LINES ONE AT A TIME ON A LARGE THICK BITMAPPED
SCREEN %^$! And of course, is there a scroll forward entry
in termcap? Like "sf", corresponding to "sr" which *is* in
Termcap. NOOOOOO.
Notice your emotion in step 2. You're perhaps thinking -
this looks like a description of productive work, perhaps
even leading to useful information. WHAT THE HELL IS THIS
DOING ON UNIX-HATERS! Have no fear, there is a happy
ending... No dice, no matter how I mess with this, nothing
changes.
Step 3 into hell: I am obsessed. Somewhere from the dimness
of my memory I recall something about the line speed
affecting the redrawing. The unix PERCEIVED line speed,
which of course bears no resemblance to the actual line
speed I am communicating at. I think lets try stty baud
2400. The answer "extb". Ext what? A quick check using
"stty everything" reveals that baud is still "38400". I
have a 9600 baud modem. (note for the historians: a modicum
of sensibility: the word "everything" in a unix command,
causes me to relax when invoking it. I am pretty far gone
by now).
Of course this doesn't change anything. It doesn't fix my
problem. It makes me swear. I was swearing before I
started the process.
Step 4 into hell: I give up. Actually, that is a step back
to sanity in unix. But several days later another dim
memory surfaces. Perhaps I should read the manual to see
how to set the baud rate. Sure enough it I need to do "stty
2400". On a real computer you now see garbage on the
screen, as your modem tries to talk to the uart 4 times
faster than it is listening. Seeing THAT would have made me
happy.
Hell: It works. Screen updating makes sense again. My
problem is solved (heh heh). I am happy. I think this is
the moment when the little red light in my hand is supposed
to go off asking me to report (docile please) to the
termination center.
Purgatory: I wonder why this works.
DONT SEND ME OR THIS LIST ANY REASONS. DONT SEND ANY
PLATITUDES ABOUT THIS BEING STANDARD UNIX BRAINDAMAGE. JUST
DON'T.
(and mourn for soul if you happen to have some problem that
this message inadvertantly helps solve, and you fall asleep
with a smile on your face, happy with a day's productive
work).
From: AW
Date: Thu, 25 Jun 1992 14:02-0400
Subject: [Mail Signatures]
Unix BD is a conceptual virus. Watch it attempt to invade
the world of real computers. Read and weep.
Date: Thu, 25 Jun 1992 05:45 EDT
From: VK
Subject: Mail Signatures
Is there a way to define signatures to be automatically
added to the end of a mail message?
From: RM
Date: Thu, 25 Jun 1992 19:35:57 PDT
Subject: Bill Joy Golden Shower
Back on the original incarnation of MC I used to have a file
full of some of the egregiously appalling things Bill Joy
said over the course of a couple of years. But could
anything from those days of mild megalomania compare with
the idea of a Limited Edition Bill Joy Golden Edition CD?
----------------------------------------------------------------------------
The Florida SunFlash
SUNSOFT DELIVERS SOLARIS 2.0 FOR SPARC
SunFLASH Vol 42 #28 June 1992
----------------------------------------------------------------------------
SunSoft, the system software subsidiary of Sun Microsystems,
Inc., today announced the first customer ship of Solaris 2.0
for SPARC users. The press release, which includes
background information on the key technologies offered in
Solaris 2.0, is attached for your reference.
SMCC announced that Solaris 2.0 is available for all Sun
workstations currently being shipped. Solaris 2.0 support
for the SPARCstation 10, SPARCserver 10 and the SPARCserver
600 MP series is scheduled for later this year. All future
SMCC workstation and server products will be based on
Solaris 2.0 and future Solaris releases.
Press inquiries to Amy Choice at 415-336-0594.
--------------------------------------------------------------------------------
Shrink-Wraps Multiprocessing, Multithreading, Networking For
High Volume Markets
Bill Joy Golden Edition Delivered To Customers On Schedule
MOUNTAIN VIEW, Calif., June 23, 1992 -- SunSoft today
announced the on-schedule shipment of the Solaris 2.0
software environment, the culmination of one of the computer
industry's most ambitious software undertakings. Requiring
more than 1,000 man years of development time, Solaris is
the first system software product to combine the features of
high-performance computing -- such as multitasking,
multiprocessing, multithreading and network security -- with
the ease of use of a personal computer bringing
traditionally expensive commercial and technical computing
processes to mainstream desktop computers. In addition, it
is the only software solution available today that provides
a compatible path to next-generation object-based computing.
Solaris 2.0 will ship to customers worldwide in a special
limited edition Compact Disc (CD) package -- the Bill Joy
Golden Edition. Signed by UNIX pioneer and Sun cofounder,
Bill Joy, the gold CD encapsulates 32-bit power,
industry-standard networking, a robust developer environment
and a 3-D multimedia desktop. The Bill Joy Golden Edition
will be shipped to customers, including Toshiba, CompuAdd,
Solbourne, Tatung and Sun Microsystems Computer Corp. (SMCC)
beginning next week. These companies design computers based
on the world's most widely used RISC microprocessor, SPARC.
[...]
From: JZ
Date: Thu, 25 Jun 92 23:19:46 PDT
X-Windows: Sometimes you fill a vacuum and it still sucks.
Subject: The Personification Of UNIX
There is an arcade game called Block-Out (or something like
that) which is a 3d version of Tetris; you're looking down
on the stack of blocks and rotating wireframes in 3space.
But that's not the point.
The point is that when a round ends, this big Oz-head comes
onto the screen, growling something at you with way too much
reverb for you to be able to understand anything it's
saying, and as it's doing this, the background has a list of
UNIX error messages scrolling by, with such classics as
core dumped
bad system call
too many links
fsck failed
not a typewriter
hangup
and my personal favorite
network is unreachabl
(In the true UNIX spirit of fixed-size buffers.)
So now whenever Unix shafts me, I get an image of this giant
Oz-head guy, YELLING at me with way too much reverb.
From: JL
Date: Fri, 26 Jun 92 09:15:22 EDT
Subject: Every Bug A Feature
..and every feature a bug? Found in comp.std.c:
From: GF
Date: 25 Jun 92 15:42:32 GMT
Subject: Trigraphs Considered Useful
I am not a trigraph advocate but have just put at least one
trigraph mapping to good use
the problem arises in code that compiles under classic and
__STDC__ where the __STDC__ code may use #pragma
#if _ok_to_use_pragma_foo_
#pragma foo
#endif
this is ok for __STDC__ but some classic compilers complain
about the undefined control #pragma and terminate
the first attempt indented the #pragma by a space/tab, but
some non __STDC__ hybrids still choked
the trigraph solution is
#if _ok_to_use_pragma_foo_ && _ok_to_use_trigraphs_
??=pragma foo
#endif
From: PB
Date: Fri, 26 Jun 92 09:59:17 MDT
Subject: Re: Bill Joy Golden Shower
Signed by UNIX pioneer and Sun cofounder, Bill Joy, the gold CD
encapsulates 32-bit power, industry-standard networking, a robust
^^^^^^
That would be about eight bucks. It will buy you enough gas
to get you far enough away from the nearest weenie power
machine to not have your brain ruined again.
From: RM
Date: Tue, 30 Jun 1992 18:44:29 PDT
Subject: "Neat Things" Are In Your Future
From: CF
Date: 30 Jun 92 22:04:50 GMT
Subject: Re: STREAMS based TLI for IP and OSI ?
In an article AB writes:
>Hello out there!
>
>I'm looking for X/OPEN compatible, STREAMS based TLIs
>for TCP, UDP, TP0 and TP4. Is there anything available
>with SunOS 5.0/Solaris 2.0 besides /dev/tcp?
The following STREAM devices are mentioned in the SVr4
Network Interfaces Guide.
/dev/icmp - Internet Control Message Protocol
/dev/rawip - Internet Protocol
/dev/tcp - Internet Transmission Control Protocol
/dev/udp - Internet User Datagram Protocol
/dev/tivc - STREAM clone device
These should be present in Solaris. /dev/tivc allows
you to do some neat things if you need to write
protocol independent code (you can supply a set of
protocol characteristics --- eg. connection oriented
vs. broadcast --- and a protocol will be selected
automatically from an ordered list in the NETPATH
environment variable.
Why would anybody want "protocol independent" code anyway?
Neat Stuff Methodology:
Step 1. Completely ignore NET:INVOKE-SERVICE-ON-HOST
(substitute appropriate vastly superior,
preexisting technology)
Step 2. Implement a totally trivial, useless subset of that
technology.
Step 3. Tie it to some random environment variable/text
file. Be sure to make this tie-in cryptic,
non-extensible, per-user, application-specific,
ad-hoc and totally independent of extensible
databases and automatic, global configuration.
Step 4. Claim you've invented something new and wonderful.
Cretins.
PS if you want to retch, check out the imbecile
server-location (srv-loc) "protocol" being "designed" by the
IETF.
From: PB
Date: Tue, 30 Jun 92 22:31:19 EDT
Subject: Re: "Neat Things" Are In Your Future
From: RM
Date: Tue, 30 Jun 1992 18:44:29 PDT
if you want to retch, check out the imbecile
server-location (srv-loc) "protocol" being
"designed" by the IETF.
Actually it's one luser from Apple who clearly has the
"hidden" agenda of being able to replace the lower layers of
AppleTalk with IP protocols. Of course he can't come out
and say this, he has to come up with cretinous and
elliptical requirements like "it has to work in a dentist's
office". Actually, a dentist's office is a faily good
metaphor for AppleTalk!
From: PS
Date: Thu, 2 Jul 92 09:59:25 EDT
Subject: Re: The Personification Of UNIX
From: JZ
Date: Thu, 25 Jun 92 23:19:46 PDT
There is an arcade game called Block-Out (or something
like that) which is a 3d version of Tetris; you're
looking down on the stack of blocks and rotating
wireframes in 3space. But that's not the point.
The point is that when a round ends, this big Oz-head
comes onto the screen, growling something at you with
way too much reverb for you to be able to understand
anything it's saying, and as it's doing this, the
background has a list of UNIX error messages scrolling
by...
This reminds me of an arcade game from Atari, popular in the
mid-80s. It was called "Major Havoc", and playing involved
moving Major Havoc through a bunch of nuclear power plants
that were going critical because the evil Vaxx had taken
them over. Your mission, you were told, was to fight off
the Vaxx, disable the power plants, and eventually engage
the Vaxx in combat on their home planet of Maynard.
From: NE
Date: Sun, 5 Jul 92 13:12 EDT
Subject: YPSCREW(8)
> tcsh# /usr/etc/yp/ypinit -m
> Installing the NIS data base will require the use of large
> quantities of vaseline. Questions will all be asked at
> the beginning of the procedure, however your answers will
> be totally ignored.
[quantities of silliness supressed]
> Don't know my own name!: Connection refused
> sh: 551 Abort - core dumped
> *** Exit 134
[more silliness supressed]
> `all' not remade because of errors
>
> demo-26 has been set up as a NIS master server without any errors.
I particularly like the part where it says there
were no errors right after announcing how it didn't remake
things because of errors. Perhaps "Don't know my own name!"
(followed after a bit by "demo-26 has been set up ..." is a
variation of sendmail's well-known inability to talk to
itself.
My only real fear at this point is that someone is
going to propose we replace the losing lispm namespace
(something that should have been done years ago) with YP.
This is like inviting Stalin to save you from Hitler.
The Network is the Computer (tm), but when you boot
the f*cking miniroot, you have no network utilities
whatsoever. No telnet, no FTP, not even p*ng.
Will somebody please tell me where I can get a real
opsys to run on this ostensibly wonderful hardware?
From: AR
Subject: Mailer Error Of The Day. (Does That List Still Exist?)
Date: Tue, 07 Jul 92 20:51:21 EDT
Check out the Sender: field. Looks like the return path is a
lose too. No wonder he's subscribing to lisp-jobs.
------- Forwarded Message
Return-Path: amc-gw!/u8/john/lisp-jobs/
[email protected]
Received: by ret.aeh.bnm (5.57/DA1.0.3)
id AA03717; Tue, 7 Jul 92 05:19:50 -0400
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA00299; Tue, 7 Jul 92 05:19:39 -0400
Received: from amc-gw.UUCP by uunet.uu.net with UUCP/RMAIL
(queueing-rmail) id 051817.1712; Tue, 7 Jul 1992 05:18:17 EDT
Received: by amc-gw.amc.com (5.61/3.1.15/Ultrix-3.0)
id AA27284; Tue, 7 Jul 92 00:42:54 -0700
Return-Path: </u8/john/lisp-jobs/
[email protected]>
Received: by amc-gw.amc.com (5.61/3.1.15/Ultrix-3.0)
id AA27209; Tue, 7 Jul 92 00:29:12 -0700
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA13305; Mon, 6 Jul 92 23:50:06 -0400
Received: from logrithm.UUCP by uunet.uu.net with UUCP/RMAIL
(queueing-rmail) id 234734.9463; Mon, 6 Jul 1992 23:47:34 EDT
Received: from cds687.Logrithm.COM by logrithm.Logrithm.COM (5.61/3.14)
id AA11962; Mon, 6 Jul 92 10:54:23 -0700
Received: by cds687 (5.65+/1.4)
id AA04807; Mon, 6 Jul 92 10:58:29 -0700
Date: Mon, 6 Jul 92 10:58:29 -0700
From:
[email protected] (JC)
Message-Id: <9207061758.AA04807@cds687>
To:
[email protected],
[email protected]
Subject: Please add me to your list
Sender: @ret.aeh.bnm:/u8/john/lisp-jobs/message-footer-file@/u8/john/lisp-jobs/message-header-file
[email protected]
------- End of Forwarded Message
From: EB
Date: Wed, 8 Jul 92 10:40:47 PDT
Subject: Re: Mailer Error Of The Day. (Does That List Still Exist?)
In a message JA wrote:
>
> Fortunately I am no longer stuck with the foibles of unix!
> Take that!
Ah, JA, you are so naive. Do you really think having a
LispM on your desk will protect you from the foibles of
Unix? Remember, Unix is Everywhere (like Elvis, or
Satan...)
From: JO
Date: Fri, 10 Jul 92 13:49:12 EDT
Subject: Re: Splitting BandyHairs (tm) on LuseNet
The real mystery to me is how any of us ever succumbed to
the temptation to
(a) implement the concept of "article cancellation"
and
(b) get mired in the rigamarole surrounding "news administration"
since both of these ideas are essentially contrary to the
spirit of usenet and will probably tend to impede its
usefulness as a multicast publishing and information sharing
medium in the long term.
From: EF
Date: Fri, 10 Jul 92 14:16:09 -0700
Subject: Re: Splitting BandyHairs (tm) on LuseNet
If what I plan works, there will be an end to the
rmgroup/newgroup wars on the Internet part of USENET. And
the lusers will hate me even more than bandy. Watch This
Space for Further Details...
(insert maniacal laughter)
From: AD
Date: Fri, 10 Jul 92 19:09:49 EDT
Subject: FTCS-22 Keynote Speech
After describing how much we know about making
computer hardware which is fault-tolerant...
So, what other problems do we have?
<strategic pause>
UNIX.
<mumbles of agreement from the audience>
Unix is a standard brought to us by academia....
<goes on to point out the obvious contradictions
to implementing fault-tolerant systems on top of
Open Systems -- continually equating the concepts
of "Open Systems" with "UNIX" as the propoganda
would have us believe... finishes up with pleas
to academia for Open Standards which are
compatible with Fault Tolerance...>
Why do "we" get all the blame? AT&T spawned this virus.
Perhaps we are at fault for not rising to the occassion and
writting an anti-toxin which vaccinated machines to cure
them of the virus. Hmm, perhaps that was what RTM's worm
was really after (after all, it did only affect UNIX
machines...).
From: CM
Date: Sat, 11 Jul 92 23:06:31 EDT
Subject: [ Re: Summary Of TAP Discussion ]
Speaking of bizzarre flame wars, have you all been following
the TAP-fest on tcp-ip (comp.protocols.tcp-ip for the lame)?
This DB guy is starting to sound like the Penguin, nya-ha-ha!
From: DB
Subject: Re: Summary of TAP Discussion
Date: Thu, 09 Jul 92 13:44:46 +0100
It's a conflict of interest, Crocker. Your company has
business dealings with a company which I have vowed to
destroy. Do you deny that SAAG is concerned with TAP's
possible competition with cryptographic protocols?
``I am concerned that if we were to progress the RFC it
would be interpreted as being suitable for
authentication, in lieu of the other, higher assurance
mechanisms now under development.'' (SK, last December.)
Do you deny that PEM is a ``higher-assurance mechanism''? Do
you deny that TIS has a financial interest in the future of
PEM?
You can't have it both ways. SAAG has held TAP back for a
year with the excuse that TAP could delay widespread use of
cryptographic mechanisms. Now that we've discovered that
you have a *financial* interest in those cryptographic
mechanisms, are you going to lie about SAAG's position?
An honest man with a conflict of interest will admit the
conflict and take steps to remove himself from the position
of difficulty. In this case that is the position of
controlling TAP's future. Remove yourself!
All your rhetoric about ``the overall operation is strongly
driven by consensus'' can't justify your actions. You
singlehandedly replaced me with SJ as chairman of the
effort. Then SJ, without checking with the Ident group, cut
the TAP document out of Ident's agenda. And then you threw
me off the SAAG mailing list.
That's not how consensus works! An honest man doesn't
attempt to achieve ``consensus'' by cutting his opponents
out of the process. Nor does he abuse a position of power
just so that he doesn't have to listen to something he
disagrees with. People working towards consensus normally
state their concerns and build on top of each other's
suggestions, incrementally. Your actions have been anything
but incremental.
You say ``The ident spec is close to complete and should
soon be ready for advancement to Proposed Standard.'' Weird:
According to PG, you said exactly the same thing two months
ago. Neither time have you presented specifics to back up
this claim. So how about I present specifics: There are
twice as many complaints about the current Ident draft now
as there were two months ago (even ignoring my objections).
Two weeks ago I sent Ident a list of 73 unresolved problems;
by now 6 of them---under 10%---have been settled. The
auditing restriction issue, which has been identified by
both sides as crucial, has made zero progress.
Most importantly, nobody has any implementation experience
with Ident. IDENT IS NOT COMPATIBLE WITH CURRENT USE OF TCP
PORT 113. Do you deny this, C? I will never support any
attempt to cripple TAP by ``standardizing'' a quite
different protocol which uses the same port. (SJ refuses to
change the port number. Why?)
And SJ *still* hasn't said anything about an Ident meeting
at the Boston IETF. How can the working group be expected
to finish its document when the working group chair neglects
even his most basic duty: organizing meetings? (``Pssst, SJ,
how about the five of us get together and hold a dummy
meeting to finish crippling the protocol. Don't worry, I
won't mention it to the working group, so nobody who objects
will show up.'')
From: JZ
Date: Mon, 13 Jul 92 14:39:49 PDT
X-Windows: A moment of convenience, a lifetime of regret.
Subject: Left To Their Own Devices
In an article MB wrote:
>
> In the GNU system, and in those systems which already
> support /dev/fd, you can do the following:
>
> cat a.c | gcc -x c /dev/fd/0 -o /dev/fd/1 > a.o
How terribly pleasant.
From: CM
Date: Thu, 16 Jul 92 13:13:23 EDT
Subject: Forgive Them, Lord, For They Have No Taste.
Jesus H. Spaghetti-coding Christ! 4.3BSD -- who the hell is
responsible for this shit? Haven't these Berkeley losers
heard of words like "procedural abstraction" or
"aesthetics"? Note the following function which looks for a
routing entry first in the host route table and then in the
network route table. Note how they cleverly have a variable
named "table" which is set first to the host route table and
then the network route table and also how the function
avoids any confusion despite repeated goto's to "again:" by
judicious use of the "doinghost" flag.
The fact that procedure calls are expensive on the vax is no
argument for ugliness like this.
sys/net/route.c:
/*
* Packet routing routines.
*/
rtalloc(ro)
register struct route *ro;
{
register struct rtentry *rt;
register struct mbuf *m;
register u_long hash;
struct sockaddr *dst = &ro->ro_dst;
int (*match)(), doinghost, s;
struct afhash h;
u_int af = dst->sa_family;
struct mbuf **table;
if (ro->ro_rt && ro->ro_rt->rt_ifp && (ro->ro_rt->rt_flags & RTF_UP))
return; /* XXX */
if (af >= AF_MAX)
return;
(*afswitch[af].af_hash)(dst, &h);
match = afswitch[af].af_netmatch;
hash = h.afh_hosthash, table = rthost, doinghost = 1;
s = splnet();
again:
for (m = table[RTHASHMOD(hash)]; m; m = m->m_next) {
rt = mtod(m, struct rtentry *);
if (rt->rt_hash != hash)
continue;
if ((rt->rt_flags & RTF_UP) == 0 ||
(rt->rt_ifp->if_flags & IFF_UP) == 0)
continue;
if (doinghost) {
if (bcmp((caddr_t)&rt->rt_dst, (caddr_t)dst,
sizeof (*dst)))
continue;
} else {
if (rt->rt_dst.sa_family != af ||
!(*match)(&rt->rt_dst, dst))
continue;
}
rt->rt_refcnt++;
splx(s);
if (dst == &wildcard)
rtstat.rts_wildcard++;
ro->ro_rt = rt;
return;
}
if (doinghost) {
doinghost = 0;
hash = h.afh_nethash, table = rtnet;
goto again;
}
/*
* Check for wildcard gateway, by convention network 0.
*/
if (dst != &wildcard) {
dst = &wildcard, hash = 0;
goto again;
}
splx(s);
rtstat.rts_unreach++;
}
From: DM
Date: Thu, 16 Jul 92 21:54:04 -0400
Subject: TOPS20 Lives (at Cisco)
From: KB
Date: Mon, 13 Apr 92 15:59:54 -0700
Subj: FWD: TOPS-20, still making money...
Subj: TOPS-20, still making money...
Subj: TOPS20 Lives (at Cisco)
Company contact:
FOR IMMEDIATE RELEASE
CISCO SYSTEMS PAYS DEC FOR STOLEN SOFTWARE
"WE'VE ALWAYS USED IT" SAY FOUNDERS
MENLO PARK, Calif., April 1, 1992 -- Cisco Systems today
announced that they will pay an undisclosed sum of money to
Digital Equipment Corporation (DEC) in return for the rights
to incorporate software from DEC's "TOPS20" operating system
in Cisco's market leading routers and communications
servers. "TOPS20" was the operating system for DEC's line
of 36-bit computers, which were made obsolete in 1983.
Cisco officials admitted that Cisco routers have used tops20
code since Cisco's founding in 1984, and that Cisco felt
they should "come clean" now that are in a sound financial
position.
Cisco founder LB, contacted at his new company, XKL Inc,
commented: "The same software technology that allowed
TOPS20, which ran on a machine capable of one or two MIPS,
to support many more users than a modern '30 MIPS'
workstation, allowed Cisco to switch 12000 packets per
second with a 12 MHz 68020, when our competitors were
throwing RISC processors with two or three times that clock
rate at the problem, and only getting half the end
performance." Mr. LB felt that DEC had abandoned the
software, and had no moral qualms about "borrowing" it for a
completely different end product. "We knew a large number
of 20 hackers, so it seemed a natural thing to do at the
time. But Cisco is more conservative now, and I guess they
are playing it safe [by paying DEC]. I had planned to add
an additional 4 bits to the router CPU hardware so that we
could make use of even more of the tops20 software, but this
was no longer acceptable, which is why I founded XKL."
Another of Cisco's founders, who asked not to be identified,
added that the original Cisco router's cooling fan and color
scheme were also inspired by DEC's TOPS20 systems.
DEC's reaction to Cisco's volunteering to pay for TOPS20 was
mainly one of surprise. "Once we found someone who knew
what they were talking about, even he was surprised that
there could still be money involved. Still, times are hard,
and money is money, so we aren't complaining."
From: LL
Date: Fri, 17 Jul 92 01:00:35 -0700
Subject: Re: TOPS20 Lives (Elsewhere Too)
It's amazing what you can do with the Columbia command
completion package (ccmd) and a few spare weekends.
Although this is a bit of a hack, I thought it might amuse
some of you and maybe stirr up some nostalgic memories. So
sit back for a moment and imagine that all those bletcherous
UN*X obscurities are just part of a big bad dream.
Do you remember the time when commands actually spelled out
their actions? Do you remember when the command interpreter
knew about the context in which you typed and guided you
through the command's completion? Do you remember when you
could delete a file and actually get it back again?
It's not that long ago (and it could be true again)...
% egzek
TOPS-20 Command processor 7(109)-8 [alpha]
[You have new mail from MAILER-DAEMON (NeXT Mail Agent)]
@? command, one of the following:
again blank break connect continue
copy daytime define delete directory
disable echo enable expunge fdirectory
finger fork freeze help information
logout man pop print push
qdirectory quit rdirectory recall rehash
remark rename reset run send
set suspend systat take tdirectory
terminal type undelete vdirectory wdirectory
or UNIX program, one of the following:
(682 matching keywords)
or filename, one of the following:
. ..
@day
Friday, July 17, 1992 00:18:49 PDT
@information (about) ? keyword, one of the following:
batch-requests directory-stack disk-usage
file fork-status history
internet job-status logical-names
mail memory-usage message-of-the-day
monitor-statistics output-requests remote-printing
resource-usage terminal-mode uptime
version
@information (about) disk
/private/tmp/foo
1 Kbytes assigned
96654 Kbytes free on /dev/sd0a, 265373 Kbytes used.
@dir
?No matching files
@copy /dev/null foo
/dev/null => foo
@dir
foo
@vd
/private/tmp/foo Blks Bytes Creation Owner Access
foo 0 0 17-Jul-92 00:19:34 lennart rw-------
@del foo
foo [OK]
@dir
?No matching files
@qdirectory (of deleted files)
foo
@undel foo
foo [OK]
@dir
foo
@del foo
foo [OK]
@exp
/private/tmp/foo [1 file expunged, 0 blocks freed]
@cat&
@[cat: Stopped (tty input) at 00:26:04]
@i fo
=> cat (1987): Stopped (tty input)
@cont/back cat
@[cat: Stopped (tty input) at 00:26:11]
@reset cat
[cat: Terminated at 00:26:18]
@sy no op
Fri 17-Jul-92 00:28:33
12+7 Jobs Load av 0.02 0.08 0.05
No operator in attendance
Job Line Program User Origin
2 cons EXEC lennart
9 p2 EXEC lennart
11 p4 EXEC lennart
12 p5 EXEC lennart
13 p6 EXEC lennart
14 p7 EXEC lennart
15 p8 EXEC lennart
16 p9 EXEC lennart moat
17 pa EXEC pgraff wonka
18 pb EXEC pgraff wonka
19 pc EXEC lennart cubesq
20 pe EXEC lennart gatekeeper
@logo
Killed Job 20, User lennart, Account next_sw, TTY pe
at 17-Jul-92 00:29:28, Used 0:00:02 in 0:04:16
From: MC
Date: Fri, 17 Jul 92 16:38:20 EDT
Subject: Standard Rot
I find myself unable to compose a flame which does not
diminish the message which follows. It is like a good
horror film, which, each time seen, reveals another layer of
hideousness.
[Z39.50 is, roughly, a standard for dialog between a client
and a bibliographic database server. Think ISO and leaping
featurism. Explain is a mechanism for a server to describe
its contents.]
From: WD
Date: Fri, 17 Jul 1992 14:47:00 EDT
Subject: Ongoing Explain Ramblings
(no one has complained and at the ZIT i said i would
comment on potential interesting aspects of implementing
EXPLAIN, since i think i am the 1st)
A major thing i am doing with explain (yes it is partially
functional for me) is sending over a "display language"
which tells how to put a record on a user's display. Most is
straightforward like
if (field 1) display field1
if (field1 and author=waldstein) display "why read this??"
but several constructs raise issues:
+ Unix shell escapes, e.g. "time = `date`"
I think correctly the client should do this, since
sometimes the info found is related to the
user/system/setup doing the display. However,
security is involved, clients may not want to know
Unix shell, etc. So i am evaluating these at server
end and sending them expanded. I do not think this
is right, but so it goes.
+ Environment fetches ( ${NAME})
AM doing these as above with same problem with this
being the wrong way. Note one application I use for
this is we set MYLIBRARY in a users environment and
do a display line
if (${MYLIBRARY} ~ 049) display "Your library has this"
This functionality is being lost unless the clients
knows/learns that the 049 is holdings and MYLIBRARY
checks it.
+ #include filename
displays bringing in displays. What a mess, but i
think they must be relative data on the server (or
maybe the include is to another server to do a Z39.50
fetch??)
[...]
From: RA
Date: Mon, 27 Jul 92 19:41:19 EDT
Subject: Re: Return-Path or From: ?
From: EN
Date: 27 Jul 92 21:05:15 GMT
Subject: Re: Return-Path or From: ?
NR writes:
|
| In an article SM writes:
| >
| >Which is the correct field for a mailer to use when
| >getting the address>from a message to reply to it:
| >
| >Return-Path: *or* From:
| >
| >Seems to me that the Return-Path is often unreliable and
| >should be avoided, but there still seem to be sites on
| >the net that use this.
|
| You are supposed to use "Reply-To:" if there is one,
| otherwise "From:". Don't ever use "Return-Path:". It is
| highly unreliable.
Perhaps a little explanation of why it's unreliable would
do. The cause is, as almost always when we discuss
malfunctioning mail software, a virus known as "sendmail"
which has infected a number of systems using BSD Unix, and
has yet to be given the proper attention, i.e. be removed.
The Return-Path header is supposed to be inserted upon final
delivery of the message, as far as SMTP is concerned. This
may not always be final delivery to the user, though, but on
the Internet, it is. Now, this bogus SMTP daemon and mail
ravager, sendmail, inserts Return-Path headers at will and
does not obey the standard. And, which is more, it believes
that when a message has a Return-Path header, it should not
replace it with a good one.
The Return-Path is thus meant to be reflect the envelope
sender, as SMTP sees it, and it should, theoretically, be as
reliable as bouncing mail at the SMTP level to bounce it at
the application level. Not so in practice. Thanks to
sendmail.
Help stomp out sendmail in our lifetime.
From: CS
Date: Wed, 29 Jul 1992 13:03-0400
Subject: [You Know You've Come Of Age When,]
----- Begin Forwarded Message -----
From: HN
X-Delivery-Notice: SMTP MAIL FROM does not correspond to sender.
Date: Wed, 29 Jul 1992 00:45 EDT
Subject: You Know You've Come Of Age When,
At the next American Folklore Society meeting in
Jacksonville, FL (Oct 15-18) there will be a session called
'Invisible Folk: Identity, Communication and Community in
Cyberspace'
Two papers (maybe more) will be presented:
"Smiley Icons: Keyboard Kitsch or New Communication Code" by
Brenda Danet and Lucia Ruedenberg
"Usenet Signatures: the Expression of Persona, Status and
Community" by Bruce Jones
We have now passed the stage of designing new protocols and
WGs and have entered the realm where we have linguists and
sociologists studying how we do things.
Lawyers, copyrights, pleasure.com (for those who heard Mitch
Kapor at IETF), and now we are already folklore :-)
P.S. Don't bother to follow-up. This was just an
informational posting.
----- End Forwarded Message -----
From: CM
Date: Wed, 29 Jul 92 16:50:05 EDT
Subject: Re: [You Know You've Come Of Age When,]
Barf!
From: SM
Date: Thu, 30 Jul 1992 13:35-0400
Subject: [Returned Mail: Unknown Mailer Error 1]
But why does it *care* about the term type?
----Begin forwarded message----
Date: Thu, 30 Jul 1992 13:12 EDT
From: Mail Delivery Subsystem <
[email protected]>
Subject: Returned Mail: Unknown Mailer Error 1
----- Transcript of session follows -----
lock t (clim) permanently locked - consult a guru
You have no TERM environmental variable. This variable
tells the system what type of terminal you are using so it's
features may be used. To set this variable:
From csh type 'setenv TERM <term-type>'.
From sh type 'TERM=<termtype>;export TERM'.
Where <term-type> is the system designation for your terminal.
(E.g. hp2621, adm3a, aaa40, etc).
554 "| /usr/spool/notes/.utilities/nfmail -s clim"... unknown mailer error 1
----- Recipients of this delivery -----
...
----- Unsent message follows -----
...
----End forwarded messages----
From: RM
Date: Thu, 30 Jul 1992 21:47:33 PDT
Subject: Re: [Returned Mail: Unknown Mailer Error 1]
From: SM
Subject: [Returned mail: unknown mailer error 1]
Date: Thu, 30 Jul 1992 10:35:00 -0700
But why does it *care* about the term type?
----Begin forwarded message----
Date: Thu, 30 Jul 1992 13:12 EDT
From: Mail Delivery Subsystem <
[email protected]>
Subject: Returned mail: unknown mailer error 1
To: <@BBN.COM:
[email protected]>
cc: Postmaster
----- Transcript of session follows -----
lock t (clim) permanently locked - consult a guru
You have no TERM environmental variable. This variable
tells the system what type of terminal you are using so
it's features may be used. To set this variable:
From csh type 'setenv TERM <term-type>'.
From sh type 'TERM=<termtype>;export TERM'.
Where <term-type> is the system designation for your terminal.
(E.g. hp2621, adm3a, aaa40, etc).
554 "| /usr/spool/notes/.utilities/nfmail -s clim"... unknown mailer error 1
I like the "transcript" -- it looks like the mailer is
running under CLIM. ("lock t (clim) permanently locked -
consult a guru")
In fact, that would explain the voluminous error-message, as
I've seen very few unix utilities which provide any sort of
error-detection, and those that do usually have inaccurate
error-reporting, and those error-messages which are accurate
are usually terse to the point of meaninglessness, and those
that aren't don't offer any sort of real diagnostic, and
those that do offer no suggested remedy.
Besides, unix programs don't use locks.
One thing I don't understand is why the distinctly ween-oid
word "guru" appears in the same breath as "clim" and "lock".
Perhaps miniscule "clim" means something different from
CLIM? "c"onfused "l"imited "i"gnorant "m"ailer?
From: DH
Date: Fri, 31 Jul 92 07:00:12 EDT
Subject: Re: [Returned mail: unknown mailer error 1]
Date: Thu, 30 Jul 1992 13:35-0400
From: SM
But why does it *care* about the term type?
So it can verify you're using a typewriter!
From: WA
Date: Fri, 31 Jul 92 12:03:01 EDT
Subject: Consult A Guru?
(Was: [Returned mail: unknown mailer error 1])
You are losing sight of one other fundamental lossage here.
UNIX victims have become so accustomed to this garbagy
mindset that they no longer notice it.
NOW DARE AN OPERATING SYSTEM TELL US TO CONSULT A GURU????
This is a computer program! It's supposed to know what to
do. If it can't, it should produce a diagnostic scan,
reboot itself, and send the diagnostic info to the system
vendor.
From: LK
Date: Fri, 31 Jul 1992 10:42:10 PDT
Subject: Re: [Returned mail: unknown mailer error 1]
This seems a variant on the old bug in /usr/ucb/mail where
the naive user types "mail" inside the mail program, and it
starts up a new mail job with no "TO" argument, so somehow
it takes the environment string as the recipient and sends
mail to
vt100@TERM
unix:0.0@DISPLAY
etc.
Date: Fri, 31 Jul 92 17:41 EDT
From: NE
Subject: Re: [Returned mail: unknown mailer error 1
> they attribute bugs in *anything* which runs on *any*
> version of UNIX to "the spirit of UNIX" rather than to the
> incompetance of any particular programmer or system
> administrator.
After 15 years in the industry, I think it's quite
fair to say that the UN*X "philosophy" generates,
encourages, and enshrines bugs and bugginess. Who can say
whether any particular bug would (or would not) have
happened if what RPG refers to as "the MIT approach" had won
the day? All I can say for sure is that things are much
worse than they need have been.
As for competence, well, it seems to be a moving
target. I'm tired of hearing described as incompetent
anyone who doesn't want to spend as many hours as the
accuser has grokking the stupidly arcane mysteries of a
1960's poor-excuse-for-an operating system. Un*x is too
hard to maintain, requiring far too much undocumented
knowledge, and that's *why* there are so many "incompetent"
adminstrators.
Your mentioning the KLH-10 in a pro-un*x message to
unix-haters (the charter of which specifically prohibits
saying anything nice about un*x or conveying useful
information: it's *supposed* to be biased) is the rough
equivalent of smearing the Torah with shite in a synagogue.
Expect flames.
From: IH
Date: Fri, 31 Jul 92 16:42:47 EDT
Subject: The Horror
Date: Fri, 31 Jul 1992 10:42:10 PDT
From: LK
This seems a variant on the old bug in /usr/ucb/mail
where the naive user types "mail" inside the mail
program, and it starts up a new mail job with no "TO"
argument, so somehow it takes the environment string as
the recipient and sends mail to
vt100@TERM
unix:0.0@DISPLAY
etc.
God. I actually remember enough of the unix internals to
guess why this is so. Kind of makes me want to get hit by a
car so that I can get amnesia.
From: PB
Date: Fri, 31 Jul 92 17:05:54 MDT
Subject: Standardized Brain Damage
I was looking in the man page for uname() on a sun and found
this at the end.
System administrators should note that systems with
node names longer than eight bytes do not conform to
IEEE Std 1003.1-1988, System V Interface Definition
(Issue 2), or X/Open Portability Guide (Issue 2)
requirements.
From: AB
Date: Fri, 31 Jul 92 23:38:22 EDT
Subject: [EDU: Returned mail: unknown mailer error 1]
Date: Fri, 31 Jul 92 12:53:22 -0400
From: BS
(the message points out my biggest gripe with the
messages i've seen forwarded from unix-haters: they
attribute bugs in *anything* which runs on *any* version
of UNIX to "the spirit of UNIX" rather than to the
incompetance of any particular programmer or system
administrator.
Good thing you didn't CC this apologistic aside to
Unix-Haters, else we would have had to chastise you... (And
please pardon me for CCing this reply to Unix-Haters -- it
inspired a flame.)
Of -course- mail to Unix-Haters fails to blame any
particular responsible individual. -Every- little bug or
problem is actually the responsibility of some individual,
if you could only figure out who. The problem is that
dealing with Unix seems like a grand game of finger pointing
and pass-the-buck (without Harry Truman). Is the real
problem that the programmer didn't check the array bounds?
Or is it ultimately the fault of the designers of C for
designing a language in which programmers must error check
array indices manually?
Eventually, you stop caring about the details that would let
you sort out who was responsible. Recently I was unable to
use FTP on a PC to send a file to my directory on a Unix
machine because on the Unix box I use the `bash' shell.
Heaven help me, I even understand why this restriction
plugged yet another security hole in Unix, and I was able to
remove the restriction as soon as I understood what was
happening, but after enough absurdities like that, your
average user has no energy left to assign blame. What do
all these bad experiences have in common? Unix! Thus, Unix
is the problem.
Hell, Unix even -encourages- this phenomenon. Contrast what
happens on ITS or a Lisp Machine or Multics when a program
error happens, with what happens on Unix. On ITS, Lisp
Machines or Multics your program suspends and you are given
the opportunity to debug the problem and perhaps fix it and
proceed. You are given the chance to assign some blame. On
Unix -- *blam* -- core dumped. -Maybe- you can debug it,
but you certainly can't proceed, so why bother? Ignore that
(huge) core dump file and move on to your next task.
Note that users -like- this behavior. No kidding. Ask half
the graduate students at MIT these days -- they -hate- the
Lisp Machine debugger. All those blasted -choices-. All
those explainations and questions. They don't want to know
who to blame -- all they want to know is that it what they
were doing didn't work so they can try something else.
So if I want to -think- about who to blame for my problems,
I'll go use a Lisp Machine (or an ITS or a Multics). But
these days I use Unix, where I don't have to think.
- A Satisfied Customer
From: JL
Date: Sun, 2 Aug 92 22:00:20 EDT
Subject: RE: Need your help.
Enclosed is your message, as it arrived here. Plenty of
">From"'s. (I've added an extra leading "-" to each line to
prevent any further damage along the way.)
I get my mail through MOLA, a commercial service. The exact
MOLA machines it goes through depends on such factors as the
phase of the moon, the sign of the zodiac, and so on. Some
of their machines consistently insert ">"; some don't. At
least one sometimes does and sometimes doesn't, in a pattern
I've never been able to discern.
I've sometimes received duplicate copies of messages from
mailing lists which happen to go through different paths
within MOLA. In that case, it's easy to compare the two and
see that one has ">"'s while the other doesn't.
I've argued with MOLA about this, but they refuse to
acknowledge that it's a problem - it's just "the way the
Unix mailer works". The RFC's are apparently just barely
vague enough in some sections to make it possible for them
to come up with interpretations that allow this ridiculous
broken behavior. (E.g., the RFC's say that messages
consists of ASCII text, and after all what was delivered was
ASCII text, so what am I complaining about?)
There is a another, less common, mailer lossage: If the
first character on a line is ".", it gets doubled.
Interestingly enough, the machines at MOLA that insert ">"
don't double dots, while those that don't insert ">" DO
double dots. At one time, I had a duplicate pair of mailing
list messages that showed both effects plainly. Needless to
say, MOLA doesn't consider THIS a problem either.
After much searching and talking with Unix mail experts, I
was able to determine exactly where the ">" is coming from.
In fact, the DESIGN is more or less (well, less) reasonable:
The Unix mailbox file format has no explicit indicator of
the beginning of a mail message other than a line starting
with "From". So a ">" is inserted by the final delivery
agent (smail, I think) to avoid ambiguity. The mail user
agent is, I suppose, intended to strip the ">" off, but
since leading ">From" lines aren't touched on delivery,
there's no CORRECT way to do this - and in any case I don't
know of any Unix user agent that bothers. I mean, what's
one little ">" between friends?
It is explicitly stated in the documentation (to interpret
that word in the very broad way that you have to when it
comes to Unix systems) that mail being routed THROUGH a
system should never be handed to the final mail delivery
agent, exactly to avoid having ">"'s inserted. However,
it's a common hack to arrange forwarding by having local
pseudo-addresses that simply mail right back out again.
Mail to such pseudo-addresses often gets passed through the
final delivery agent. Then again, given the wonders of Unix
mail, it's easy to pass even mail that ISN'T sent to a local
pseudo-address to smail. I suspect that what is happening
at MOLA is that they are using this hack to make my address
equally usable on all their machines, though I only REALLY
exist on one of them.
As for the doubled dot problems - that's a whole other
story. There is a standard convention for doubling leading
dots to allow a line consisting of just a single dot to
unambiguously terminate a message - the convention used on
some kinds of links. This is discussed in the RFC's, and if
applied properly, is transparent: The doubling is done at
one end of the link and stripped at the other; it exists
ONLY "on the wire". To see the doubling, you need to
misconfigure a link so that one end thinks dots should be
doubled, but the other doesn't know that's being done (as
there are other methods of indicating that the end of a
message has been reached).
BTW, the leading ">" bug has achieved immortality. I've
seen several papers printed in collections, including at
least one in a Springer-Verlag book, that have a line
starting with "<upside-down-question-mark>From". This is
what you get when you run ">From" through TeX. Clearly,
someone submitted TeX source through Email....
I wonder what scholars a hundred years from now will make of
this. An odd late-20'th-century affectation, perhaps?
Somehow related to smiley faces like :-) ?
[Copy of message received here.]
-Received: by lrw.UUCP (DECUS UUCP w/Smail);
- Sun, 26 Jul 92 17:42:16 EDT
-Received: from uu.mola.com by uu3.mola.com (5.65b/4.0.071791-MOLA/MOLANet)
- id AA13949; Sun, 26 Jul 92 16:24:54 -0400
-Received: from MC.EVE.RCL.EAR by uu.mola.com (5.65b/4.1.031792-MOLA/MOLANet)
- id AA15846; Sun, 26 Jul 92 16:24:38 -0400
-Received: by mc.eve.rcl.ear id ab12541; 26 Jul 92 16:20 EDT
-Received: from mc by mc.eve.rcl.ear id aa12517; 26 Jul 92 16:14 EDT
-Received: from life.one.two.thr by mc.eve.rcl.ear id aa12510; 26 Jul 92 16:13 EDT
-Received: from dolores.Stanford.EDU by life.one.two.thr (4.1/AI-4.10) id AA21660; Sun, 26 Jul 92 16:13:14 EDT
-Received: by dolores.Stanford.EDU
- (15.11/15.6) id AA04524; Sun, 26 Jul 92 13:13:10 pdt
-
-From: DW
-Date: Sun, 26 Jul 92 13:13:10 pdt
-Subject: Need your help.
-
-When this message was first delivered into my mailbox last year,
-I didn't get the joke because my "delivery agent" didn't >From it over.
-Could anyone who receives this with From changed to >From please
-forward the message back to me? I want to see if this still happens.
-
-
-From: Henry Minsky <
[email protected]>
-Date: Tue, 30 Apr 91 17:51:41 EDT
-To:
[email protected]
-Subject: Stop whining about the mailer.
-
-
->From what I can tell, the unix mailer is quite
-reasonable. I dont know where you are
->From but where I come
->From we are taught not to
-criticize ingeniously crafted system software, especially when it is comes
->From talented and dedicated individuals and corporations.
From: DH
Date: Mon, 3 Aug 92 08:04:53 EDT
Subject: Unix Hatred
Date: Fri, 31 Jul 92 23:38:22 EDT
From: AB
Date: Fri, 31 Jul 92 12:53:22 -0400
From: BS
(the message points out my biggest gripe with the
messages i've seen forwarded from unix-haters: they
attribute bugs in *anything* which runs on *any*
version of UNIX to "the spirit of UNIX" rather than
to the incompetance of any particular programmer or
system administrator.
Of -course- mail to Unix-Haters fails to blame any
particular responsible individual.
What a contrast to unix lovers, eh? Those weenies always
blame the victim!
[req'd unix flame: BS: it _is_ a problem with the "spirit of
unix" that unix programs must always be configured so that, by
default, they don't do anything useful (or worse...)]
From: MN
Date: Tue, 4 Aug 1992 09:54-0400
Subject: Re: Need Your Help.
This reminds me of something I once read, I believe it was
in the front matter of the Kernighan and Ritchie C book,
(circa 1979) which said that the book should not be treated
as a language specification but as a tutorial. The language
was specified by the behavior of the v7 pdp-11 C compiler.
From: DM
Date: Tue, 04 Aug 92 10:30:10 EDT
Subject: Re: [Returned mail: unknown mailer error 1]
> Date: Fri, 31 Jul 92 23:38:22 EDT
> From: AB
> ....
> So if I want to -think- about who to blame for my
> problems, I'll go use a Lisp Machine (or an ITS or a
> Multics). But these days I use Unix, where I don't have
> to think.
Well, you see, users really don't like open systems. They
would much rather use Unix.
From: TK
Date: Tue, 4 Aug 1992 11:39-0400
Subject: The Politics Of Unix (tm)
Date: Fri, 31 Jul 1992 23:38 EDT
From: AB
Of -course- mail to Unix-Haters fails to blame any
particular responsible individual. -Every- little bug
or problem is actually the responsibility of some
individual, if you could only figure out who. The
problem is that dealing with Unix seems like a grand
game of finger pointing and pass-the-buck (without
Harry Truman). Is the real problem that the programmer
didn't check the array bounds? Or is it ultimately the
fault of the designers of C for designing a language in
which programmers must error check array indices
manually?
Eventually, you stop caring about the details that
would let you sort out who was responsible. Recently I
was unable to use FTP on a PC to send a file to my
directory on a Unix machine because on the Unix box I
use the `bash' shell. Heaven help me, I even
understand why this restriction plugged yet another
security hole in Unix, and I was able to remove the
restriction as soon as I understood what was happening,
but after enough absurdities like that, your average
user has no energy left to assign blame. What do all
these bad experiences have in common? Unix! Thus,
Unix is the problem.
Hell, Unix even -encourages- this phenomenon. Contrast
what happens on ITS or a Lisp Machine or Multics when
an program error happens, with what happens on Unix.
On ITS, Lisp Machines or Multics your program suspends
and you are given the opportunity to debug the problem
and perhaps fix it and proceed. You are given the
chance to assign some blame. On Unix -- *blam* -- core
dumped. -Maybe- you can debug it, but you certainly
can't proceed, so why bother? Ignore that (huge) core
dump file and move on to your next task.
Note that users -like- this behavior. No kidding. Ask
half the graduate students at MIT these days -- they
-hate- the Lisp Machine debugger. All those blasted
-choices-. All those explainations and questions.
They don't want to know who to blame -- all they want
to know is that it what they were doing didn't work so
they can try something else.
AB, this excellent flame reminds me of the similarities
between our Federal Government and Unix (tm). Everyone
knows that it is broken. Everyone has effectively given up
any hope of fixing it. Those who suggest fixes radical
enough to have some impact are shouted down as extremists
and impractical dreamers. Meanwhile, patches to fix
particular problems are made at a furious rate, allowing the
continuous accretion of ill thought out features to suit the
various special interest groups.
The reaction of users to the helpful `core dumped' message
in Unix (tm) is really quite similar to the reaction of the
'90s citizens to problems such as the deficit. The problem
is so large, so complex, so riddled with politics and
special interest argument, that no sane person could attempt
to understand it. Rational self interest and
self-preservation requires denial and distancing yourself
>From the problem.
You KNOW that nothing you can do will fix any problem; even
if you, individually, understand it, there is such
widespread ignorance and intentional denial in the populace
that even convincing them there is a problem, let alone
proposing a solution, is hopeless.
The idea that you, individually, have some personal
responsibility for improving the operating system, or the
government, is dead. No one is expected to leave her
campsite cleaner than when she came. It must be so, for
what difference can it make when Government and Unix (tm)
ignore the now feeble efforts some continue to make toward
improvement.
Face it, we are not of this generation. The '90s have
arrived. Unix (tm), MTV, and the Washington PACs have won.
----------------
Unix (tm) is a registered trademark of the American
Telephone and Telegraph Company. Would you trust them with
YOUR telephone service?
From: EL
Date: Tue, 4 Aug 92 09:34:02 -0700
Subject: Re: [The Horror]
From: LK
Subject: [The Horror]
EL, this is your bug. Do you have the mail message
handy to send to unix-haters?
----- Begin Forwarded Messages -----
From: Anon
Subject: The Horror
Date: Fri, 31 Jul 1992 16:42 EDT
From: IH
Date: Fri, 31 Jul 1992 10:42:10 PDT
From: LK
This seems a variant on the old bug in
/usr/ucb/mail where the naive user types "mail"
inside the mail program, and it starts up a new
mail job with no "TO" argument, so somehow it
takes the environment string as the recipient
and sends mail to
vt100@TERM
unix:0.0@DISPLAY
etc.
God. I actually remember enough of the unix
internals to guess why this is so. Kind of makes me
want to get hit by a car so that I can get amnesia.
Just to satisfy my curiosity, is the mailier not
checking argc and then winding up nlooking at the
environment string when it thought it was looking at
argv[1] or something?
I don't have the mail message handy but is is all too easy
to reproduce despite the fact that we are running in yet
another flavor of unix.
Around here, this is caused by the following atom of
instruction. "...and use `mail -f' to read your old mail".
Naturally, it is only a matter of time before someone does
it inside of mail.
The really funny thing about it is that the mail relay host
seems to have a heuristic of "if I can't understand it, it's
probably a bitnet address". There's a moral in there
somewhere.
----- End Forwarded Messages -----
From
[email protected] Mon Aug 3 20:44:35 1992
Return-Path: <
[email protected]>
Received: by dewey (5.57/SMI-3.0DEV3.8)
id AA21174; Mon, 3 Aug 92 20:44:34 -0700
Received: from dewey.SoE.Berkeley.EDU by nettlesome.berkeley.edu (5.64.1/1.34.6)
id AA13408; Mon, 3 Aug 92 20:42:25 -0700
Date: Mon, 3 Aug 92 20:42:25 -0700
From:
[email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <
[email protected]>
To: <
[email protected]>
Status: RO
----- Transcript of session follows -----
>>> RCPT To:</bin/
[email protected]>
<<< 550 Host 'SHELL.BITNET' Unknown
550 </bin/
[email protected]>... User unknown
>>> RCPT To:<
[email protected]>
<<< 550 Host 'TERM.BITNET' Unknown
550 <
[email protected]>... User unknown
>>> RCPT To:<
[email protected]>
<<< 550 Host 'USER.BITNET' Unknown
550 <
[email protected]>... User unknown
>>> RCPT To:<../emst_a/ehl/bin./usr/ucb./bin./usr/bin./usr/local/bin./usr/bin/X11./usr/
[email protected]>
<<< 501 Syntax Error. Invalid Local Part of Address
554 <.:/emst_a/ehl/bin:/usr/ucb:/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/
[email protected]>... Remote protocol error
>>> RCPT To:<set.nows.ic.|map.#1.mz|map.#2.'
[email protected]>
<<< 550 Host 'EXINIT.BITNET' Unknown
550 <set nows ic |map #1 mz|map #2:'
[email protected]>... User unknown
>>> RCPT To:<
[email protected]>
<<< 550 Host 'fruit.BITNET' Unknown
550 <
[email protected]>... User unknown
>>> RCPT To:<
[email protected]>
<<< 550 Host 'name.BITNET' Unknown
550 <
[email protected]>... User unknown
>>> RCPT To:<
[email protected]>
<<< 550 Host 'inven.BITNET' Unknown
550 <
[email protected]>... User unknown
>>> RCPT To:<
[email protected]>
<<< 550 Host 'ROGUEOPTS.BITNET' Unknown
550 <
[email protected]>... User unknown
>>> RCPT To:<
[email protected]>
<<< 550 Host 'HACKOPTIONS.BITNET' Unknown
550 <
[email protected]>... User unknown
>>> RCPT To:<
[email protected]>
<<< 550 Host 'MORE.BITNET' Unknown
550 <
[email protected]>... User unknown
550 <i@dT:fs=E[?F:es:ds=E[?E:>... Host unknown
----- Unsent message follows -----
Received: from dewey.SoE.Berkeley.EDU by nettlesome.berkeley.edu (5.64.1/1.34.6)
id AA13406; Mon, 3 Aug 92 20:42:25 -0700
Received: by dewey (5.57/SMI-3.0DEV3.8)
id AA21161; Mon, 3 Aug 92 20:44:25 -0700
Date: Mon, 3 Aug 92 20:44:25 -0700
From: EL
Message-Id: <9208040344.AA21161@dewey>
To: -f
Subject: old lossage
Does this still lose ?
Date: Tue, 4 Aug 92 16:05:40 EDT
From: JL
Subject: OK, Now I've GOT To Know
In the midst of TK's wonder posting on "The Politics Of Unix
(tm)", the following paragraph appeared [leading tab added
in THIS posting]:
The reaction of users to the helpful `core dumped' message in
Unix (tm) is really quite similar to the reaction of the '90s
citizens to problems such as the deficit. The problem is so large,
so complex, so riddled with politics and special interest argument,
that no sane person could attempt to understand it. Rational self
interest and self-preservation requires denial and distancing yourself
>From the problem.
Note the famous ">From" in the last line. Question: Did
this start out as "from the problem" or "From the problem"?
That is, does the wonderous Unix software not only insert
the ">" but also force the first letter to upper case just
to help it stand out even more noticably?
Pst. Rumour: In the next release of System V, the mailer
software will check for any use of the word "Unix". It will
change the capitalization if you get it wrong ("unix"), and
insert a (tm) if you left it out. The new licensing terms
will forbid you from disabling this feature, or running any
other mailer that doesn't support it. Expect similar user
interface enhancements in subsequent versions of the Unix
editors, printer spoolers, text formatters, and so on.
You heard it here first. Pass it along.
From: JL
Date: Tue, 4 Aug 92 16:08:35 EDT
Subject: New book
I saw a new book at the bookstore today: "Unix Curses Explained".
Somehow, that just says it all, doesn't it?
From: SG
Date: Mon, 10 Aug 92 09:28:22 -0400
Subject: No Way To Do Moderated Mailing Lists
So I'm on this mailing list for TLA Ourorg Announcements
called, disturbingly enough, "ournet."
And they've continually had flames on the list for people
sending email to the list. You see, the list is supposed to
be "moderated."
The problem is that UNIX has no concept of how to have a
moderated mailing list. So they've resorted to giving the
list a reasonable name, "wimpy." They "moderate" the
list by sending e-mail to "wimpy" as a BCC.
I suspect that sendmail's inability to have a moderated
mailing list is a holdover from this region of the UC
Berkeley campus that is near Telegraph Ave, where lunatics
are allowed to rant and rave all day long. It has something
to do with Free Speach. People are allowed to shout as loud
as they want as passers-by. UNIX extends this concept by
not allowing you to create artificially restricted mailing
list.
Begin forwarded message:
Date: Sat, 8 Aug 92 23:28:37 -0400
From: JK
Subject: What Is This Mailing List About?
Date: Sat, 08 Aug 92 12:32:52 EDT
From: RK
Sorry to clutter your mailboxes, but I have found out by
using listmaint that I am on this list, but I do not
have enough access priveleges to
find out any other details about this list. What is is about?
1) When you want to find out the purpose of a list, you
should send mail to "owner-list-name", e.g.,
"owner-wimpy", not to the list itself.
2) The "wimpy" list is the redistribution list for the
"ournet" list. It was so named (i.e., obscurely named) so
that people would not send to it without getting Ourorg's
approval first, since only Ourorg-approved announcements are
supposed to be sent to it.
However, since it has caused some confusion, I have changed
the name of the list to "ournet-do-not-use", which should be
a bit more obvious.
JK
One of ournet's maintainers
From: RS
Date: Mon, 10 Aug 1992 10:54:32 -0800
Subject: FYI: Why Ask Why?
I got this from a guy I work with:
------ Forwarded Message
-rwxr--r-- 2 root bin 103416 Jun 8 1991 halt
I am confused as to why it takes 103416 bytes to do a halt?
------ End of Forwarded Message
From: SG
Date: Mon, 10 Aug 92 13:36:54 -0400
Subject: Re: No Way To Do Moderated Mailing Lists
AB,
Thanks for your message, but it doesn't do any good.
You see, the propeller-heads at Project Loki aren't
interested in running restricted mailing-list software.
They've got a HUGE system with thousands of users. And
they're not interested in developing specialized restricted
mailing list software, or using anybody else's software.
Begin forwarded message:
Date: Mon, 10 Aug 92 10:27:55 PDT
From: AB
Subject: Re: No Way To Do Moderated Mailing Lists
I have restricted mailing-list software that you may have if you like.
From: SG
Date: Tue, 11 Aug 92 10:19:54 -0400
Subject: No Way To Do Moderated Mailing Lists
Begin forwarded message:
Date: Tue, 11 Aug 92 10:17:18 -0400
From: SG
Subject: Re: no way to do moderated mailing lists
Oh, AB, I think that you're wrong here.
You see, Project Loki was designed from the beginning to
be an open, platform-independent system to develop
educational software. So what did they do? They decided to
go with UNIX. They bought the propiganda.
They then discovered that they had to rewrite large parts of
it. The decision to go with UNIX effectively subverted
Loki's goal of developing educational software into a goal
of trying to develop and maintain a networked system of
workstations.
Today, Loki's biggest contributions are the development of
the X window System and Kerberos. The first is a bad window
system that runs on a bad operating system. Nevermind that
there were better window systems than X when it was
invented, and that today there are even better ones than
those. And Kerberos, as you know, is designed to bring
security to an inherently insecure platform, UNIX. It is so
difficult to use and install that it fits UNIX to a T.
Loki has completely lost guidance --- it no longer
considers writing educational software to be the purpose of
the project (which has, incidently, been canceled). Just
like the purpose of UNIX is no longer a small, compact
research operating system.
Begin forwarded message:
Date: Mon, 10 Aug 92 20:47:09 EDT
From: AB
Subject: No Way To Do Moderated Mailing Lists
Date: Mon, 10 Aug 92 13:36:54 -0400
From: SG
Bandy,
Thanks for your message, but it doesn't do any good.
You see, the propeller-heads at Project Loki...
I don't think that bashing on Project Loki counts as
saying something bad about Unix. The committee on
discipline will be considering your case.
From: JA
Date: Wed, 12 Aug 1992 11:59-0400
Subject: [Unable to deliver letter]
This error returned from the mailer just epitomized unix
foibles' that I had to share it with you... Just painful to
watch. You know, unix is actually getting *worse* with
time. We wouldn't have seen *this* lossage three years
ago... Of course, I won't even be able to flame at
postmaster, because I'll just get the same error again!
Date: Wed, 12 Aug 1992 00:11 EDT
From:
[email protected]
Subject: Unable To Deliver Letter
Unable to deliver letter to the following recipient:
[email protected]:
SMTP error from host NOW.HERE.ELSE:
Expected reply: 220
Received reply: ld.so: warning: /usr/local/lib/libdsap.so.80.1 has older revision than expected 2
220 now.here.else PP Here - Pleased to meet you (Complaints/bugs to:
[email protected])
----- Text of letter deleted -----
From: RC
Date: Fri, 14 Aug 92 09:41:03 EDT
Subject: Arbitrary Limits And Definitive Documentation
From the manual page for Sun make:
include filename
If the word include appears as the first seven
letters of a line and is followed by a SPACE or
TAB, the string that follows is taken as a
filename to interpolate at that line. include
files can be nested to a depth of no more than
about 16.
From: WA
Date: Thu, 20 Aug 92 16:00:07 EDT
Subject: Spell Checker With An Attitude Problem
From the grapevine:
> When I was using the WordPerfect spell checker on my
> resume, the program stopped on the word UNIX. Among the
> synonyms suggested was "anus."
From: SS
Date: Thu, 27 Aug 1992 18:17:18 -0500
Subject: Freedom Is Slavery
From: OS
Subject: Freedom Is Slavery
------- Forwarded Message
Date: Tue, 25 Aug 1992 14:06:47 -0400
From: SC
Subject: Re: Some Thoughts On B9
[...]
I agree, in general. One of the strongest contrasts I notice
between X windows programs and Macintosh programs is all the
command line options, Xresources, Xdefaults etc. It seems
that X programmers are totally unable to make any kind of
user interface decision, and instead abandon their design
obligations, leaving the question unanswered and passing it
on to the end user to solve. This is done in the name of
'choice' or 'freedom', meaning that if you sit down in front
of someone else's X terminal to simply check your mail, you
have little chance of being able to use the terminal or any
of the applications effectively. I don't want my programs to
come like self-assembly furniture.
[...]
From: CM
Date: Fri, 28 Aug 92 12:34:10 EDT
Subject: Lame .Signature Du Jour
--
#define NAME CC
#define ADDRESS
[email protected]
#define SNAIL_MAIL 560 Youve Never #11, Heard Ofit, ZZ 58203
#define PHONE (999) 999-9999
#include <brain_cell.h> /* Adding this seems to help. */
From: RS
Date: Fri, 28 Aug 92 17:45:37 EDT
Subject: Lame .Signature Du Jour
Anyone who wants some sick-minded entertainment should check
out some of the questions people ask on comp.sys.sun.admin.
Nietzsche was wrong. It's *derision* that's the opiate of the masses.
And I feel *GRRRRREAT*! <barf, heave, puke>
From: RM
Date: Mon, 7 Sep 1992 13:26:51 PDT
Subject: Who Would Believe That Case-Sensitivity Could Case "Confusion"?
From: LH
Date: 7 Sep 92 19:16:52 GMT
Subject: Re: Are You Sure UNIX Is A Trade Mark?
In some article GL writes:
... Leave the name UNIX AT&T, USL or whatever they call
themselves this week, and refer to the operating system
family as Unix. Trademarks are case-sensitive.
From the section on filing requirements in "Basic Facts
About Trademarks" from the United States Patent and
Trademark Office:
"If the drawing [showing the mark to be registered] is in
typewritten form, the mark _must_ be typed entirely in
CAPITAL LETTERS. [Emphasis in the original.] Capital
letters must be used even if the mark, as used, includes
lower-case letters."
More importantly, it is likely that confusion would result
between the uses of UNIX and Unix, so the different
capitalization would meet one of the fundamental tests for
trademark infringement.
From: SS
Date: Mon, 7 Sep 1992 20:23:51 -0500
Subject: Parentheses In C - Just Ignore Them
From: RF
Date: Sat, 5 Sep 1992 13:20:39 -0400
Subject: Parens & C
KG writes:
C/C++ is hardly the best example of infix implementation!
By the way, where were the brackets in your example. My
golden rule is: when in doubt, parenthesise!
This would be OK if C didn't ignore parenthesis. The first
version of K&R explicitly states that the compiler need not
pay any attention to parenthesis if the operations were
arithmetically equivalent. Therefore a + (b + c) could
legally add a to b FIRST and then add in c. Which can be
very amusing when you are dealing with numbers of greatly
varying magnitudes.
ANSI may or may not ignore them I don't have a reference handy.
<...>
From: SS
Date: Tue, 8 Sep 1992 15:42:28 -0500
Subject: Tracking Unix Developments
From: SS
Subject: Mac Sound
> Date: 7 Sep 92 12:51:14 U
> From: "J. Pseudonym" <
[email protected]>
> Subject: Mac Sound
>
> I'd like to pass along this question...anyone have an
> answer?
>
>
> Macs still dont really recognize the internet, or perhaps
> I should say they dont track Unix mail developments.
JP, that's absurd.
I can also claim that Unix doesn't support Macintosh email
developments, and (I believe) there's about 5 times as many
Macintoshes in the world as unix machines.
How come most (all?) unix vendors don't support Applelink,
Stuffit compression, Quickmail, Appletalk zones, Macintosh
floppy disks, AppleShare file sharing, Quicktime, MacWrite
and MacDraw files, etc.? It's not because the formats are
secret or proprietary - all these formats are either public
domain or available at licensing fees far cheaper than
AT&T's.
It's equally absurd to equate the Internet with unix (though
the contamination is pretty pervasive). The Internet and its
essential protocols (finger, telnet, ftp, SMTP mail) were
developed on non-unix machines while unix was still wearing
uucp diapers. Unix is still wearing the same diapers, they
just leak more now and you get to smell it every time your
mail is returned with an incomprehensible error message, or
when you try rlogin on some new machine and your terminal
settings are all fouled up. Forget multimedia, why is it
after 20 years unix can't even get your rubout key right?
Never mind that, there are native Macintosh programs which
support finger, telnet, rlogin, SMTP mail, NNTP news, POP
mail, time, and every other Internet protocol you can think
of. Go over to some mac ftp sites like
sumex-aim.stanford.edu:/info-mac/comm/* and take a look.
> For instance, there's no support for Mime (multi media
> email).
> For you to hear Spark voice mail you would need two things
> 1) a program to decode the contents from the base64
> encoding to binary
> 2) a program to convert sun audio format to mac audio format.
>
> both of these are pretty simple, why hasn't someone done them?
There's at least three programs that convert sun audio
formats (of course there's more than one) on the mac - go
check out sumex-aim.stanford.edu:/info-mac/sound/program/*
But I imagine the real reason is that Macintosh users expect
a higher quality of integration, and wouldn't accept the
typical
"bag-of-utilities-glued-with-a-bug-laden-shell-script"
approach that sun users would put up with. Since practically
all Macintosh mail programs inherit multimedia capability
through Quicktime, which is a heck of a lot nicer and
doesn't even require any additional hackery, there's little
incentive to support MIME.
<... more actual helpful information removed in accordance with
unix-haters code of ethics...>
From: JL
Date: Wed, 9 Sep 92 17:49:02 EDT
Subject: Advisory Locks are Like Advisory Array Bounds
And like "advisory" type systems.
You know, the systems that check for problems only when it
the checks can't possibly fail. (That way, you can optimize
better, right?)
>From a Rutgers support newsgroup:
> The message is for users of "procmail". If you don't
> know what "procmail" is then you can ignore this message.
>
> I believe that there is a problem with the currently
> distributed version of "procmail" that can cause messages
> to be lost.
> The problem seems to occur when both procmail and a mailer
> program (eg, emacs rmail-mode and mm) are operating on the
> same mailbox. In the cases that have been examined,
> procmail believes that the delivery to your mailbox was
> successful even though it fails. No error is generated
> and mail is lost.
The problem was not caused by "procmail", it was with
emacs rmail-mode. Emacs rmail-mode does not lock mailboxes
that are not in the system mail spool directory. This means
it is not safe to have mailer programs write to these
mailboxes at the same time as emacs is reading from them.
> WARNING: Continued use of this version of procmail may
> cause the loss of messages. An announcement will be made
> when the problem has been fixed.
NOTE: It is safe to use procmail with mm. mm always uses
"movemail" to read mailboxes. It is definitely *not* safe
to use "procmail" with the emacs rmail-mode at this time. A
fix for emacs is being worked on.
From: DM
Date: Sat, 12 Sep 92 08:45:02 -0400
Subject: Yearning For Unix [With A Strangely Fitting Bullet From Sendmail]
From: MF
Subject: Re: Poetry
well, by coincidence, i recently happened to pick up a book
of poetry with which i am very impressed. it is _the
tongues we speak_ by patricia goedicke, published by
milkweed editions in minneapolis in 1989. attached are two
poems from this book that i found particularly interesting.
[first poem deleted for brevity]
_At the Center of Everything Which Is Dying_
You swear you are as healthy as the next person,
Like anyone else you despise pain,
At every election you are innocent of war
But inside you there's a swamp
That keeps pulling you towards it.
Waiting for the next outbreak of the disease,
The next rifle shot, the explosion
Almost as if you had a secret lover
Faceless, waiting for you in a closet
You keep looking for it everywhere,
At board meetings, at every planning session
Sucking possibility of a catastrophe
As if it were a sore tooth
At the center of everything, which is dying
The ooze of pus attracts you,
Soldiers and chronic invalids
Have nothing to do but obey orders,
All the difficulties of life are done for them
As on a sickbed one forgets everything,
centering on the self only
Even when the surface of the onion is pure
Gradually the soft spot, the delicious rot
Keeps seeping outwards
>From one layer to the next
Inside everyone it is possible there's a viciousness,
A lascivious finger beckoning
Pornographic as sex
Without love there's a stink
Inside everyone it is possible
There's a stagnant pool that wants to be fed
New bodies, every day.
From: JZ
Date: Sat, 12 Sep 92 23:58:07 PDT
Subject: Talk About Noncommittal...
------- Start of forwarded message -------
Date: Sat, 12 Sep 92 23:52 PDT
From:
[email protected] (Generic UUCP user)
Subject: Undeliverable Mail
This mail message is undeliverable.
(Probably to or from system 'ntmtv')
It was sent to you or by you.
Sorry for the inconvenience.
Sincerely,
amdahl!uucp
#############################################
##### Data File: ############################
>From uunet!lucid.com!thalidomide!jwz Sat Sep 5 00:07:48 1992 remote from amdahl
Received: by amdahl.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.11)
id <
[email protected]>; Sat, 5 Sep 92 00:07 PDT
..blither blather bother...
------- End of forwarded message -------
From: AR
Date: Mon, 14 Sep 92 12:18:56 EDT
Subject: What Else?
liszt:/mas/u/ar/file % fgrep ich@ ../Mail/outgoing/*
/usr/bin/fgrep: Arg list too long.
liszt:/mas/u/ar/file % foreach i (1 2 3 4 5 6 7 8 9)
foreach? grep ich@ ../Mail/outgoing/$i*
foreach? echo $i
foreach? end
1
2
3
./Mail/outgoing/457:To:
[email protected]
./Mail/outgoing/469:To:
[email protected]
./Mail/outgoing/470:To:
[email protected]
./Mail/outgoing/477:To:
[email protected]
4
5
6
7
8
9
From: BB
Date: Mon, 14 Sep 92 09:55:45 PDT
Subject: Unix Error Messages In German
-- An Even Better Way To Confuse People
Return-Path: <MAILER-DAEMON%
[email protected]>
Date: Mon, 14 Sep 92 07:53:00 +0100
From: Postzustellungs-System <athen!MAILER-DAEMON>
To:
[email protected]
To:
[email protected]
Subject: zurueckgeschickte Post: Benutzer unbekannt
----- Protokoll der Sitzung folgt -----
>>> RCPT To:<terry@d255s044>
<<< 550 <terry@d255s044>... Benutzer unbekannt
550 d255s044!terry... Benutzer unbekannt: Not a typewriter
----- Unzustellbare Nachricht folgt -----
Received: by sinix.uucp
at Fri, 11 Sep 92 22:22:18 +0100 (5.52.1/SIE-1.1)
Received: from mcsun.EU.net
by mail.Germany.EU.net with SMTP (5.65c/EUnetD-2.2.0.h)
via EUnet for sinix
id AA09625; Fri, 11 Sep 1992 20:12:53 +0200
...
From: AB
Date: Mon, 14 Sep 92 23:46:03 EDT
Subject: Re: What Else?
Date: Mon, 14 Sep 92 12:18:56 EDT
From: AR
liszt:/mas/u/ar/file % foreach i (1 2 3 4 5 6 7 8 9)
foreach? ...
Amazing, isn't it, that unix forces each user to rediscover
the same set of workarounds to the same stupid bugs. I've
had to resort to the above kludge myself a few times, so
I'll bet that its actually a well-known technique. You can
probably even find it described in -books- for "advanced"
unix users.
From: SM
Date: Tue, 15 Sep 1992 11:02-0400
Subject: Re: What Else?
From: AB
Date: Mon, 14 Sep 1992 23:46 EDT
The solution, as any well-seasoned unix veteran will
tell you, is to use "tar" if you want to copy a
hierarchy. No kidding. Simple and elegant, right?
For me, using "tar" to copy directory hierarchies is the
archetype of what is fundamentally wrong with Unix, the
fundamental wrongness being that in Unix the user is forced
always to say *how it is* s/he wants something done, rather
than *what it is* s/he wants to do.
From: RS
Date: Wed, 16 Sep 92 13:30:57 -0400
Subject: Re: What Else?
> From: AB
> Date: Mon, 14 Sep 92 23:46:03 EDT
> Subject: Re: What Else?
>
>
> The solution, as any well-seasoned unix veteran will tell
> you, is to use "tar" if you want to copy a hierarchy. No
> kidding. Simple and elegant, right?
>
The notion of using the tape archiver to move a directory
hierarchy is not inconsistent with the notion of using C to
write robust, maintainable programs. Think about it.
From: DH
Date: Thu, 17 Sep 92 12:52:04 EDT
Subject: Typical Unix Limitations
Our customer had some trouble trying to bring up some code
on the HP machines:
Apparently, gas is sufficiently complex that the HP
compiler runs out of "basic blocks" in trying to
compile it, and generates a warning message. You had
to go back and turn on an additional compiler flag and
then the problem with gas crashing goes away.
From: IH
Date: Thu, 17 Sep 92 21:31:13 EDT
Subject: How Do You Set The Time Zone On A SPARC?
From: RL
Date: Thu, 17 Sep 92 21:22:15 EDT
How do you set the time zone on a SPARCstation? I can't
find any mention in the manuals.
Mail it to California.
From: RK
Date: Fri, 18 Sep 92 10:54:01 EDT
Subject: They Just Don't Get It.
From: RD
Date: Thu, 3 Sep 92 18:00:07 GM
Subject: Re: Looking For Rshd, Telnetd, Ftpd Etc.
In an article MW writes:
>In another article PB writes:
>
> Once again, why stick with the unix model? Services are
> explicitly supported by Windows NT. When started they
> take on the ACE of the user that installed them. No login
> required. I'm pretty sure that you can start these
> services via RPC. It would be trivial to write a start
> server daemon (for RPC, telnet or whatever).
Why stick with the "UNIX" model? Because it works, and works well.
Hype
aside, why thow out basic ASCII streams as a fundamental network
primitive?
(i.e. virtual circuit model with call setup and tear down, more
commonly known
in the OS community as "login"/"logout"). NT Servers are going to
get awfully
lonely in mixed environmnets. Perhaps as lonely as Apple "servers",
if that
isn't an outright oxymoron.
It is along way from a kludged individual solution, to a clean and
supported
interface. Consider also that the most successful example of data
flow
programming in the world to day is shell scripts and pipes, including
the true
ease of integration via rsh. It can even be done under VMS. Your
might
change the script language, you might have many of them, but the
basic
requirements transcends all of them.
Finally, the Internet is not an accident, a foolish standard set by
committee,
nor an attempt at market dominance...and it has survived and
prospered on this
"UNIX" model (sic). Imagine writing your own client program for
every different
server on the net...of course that is exactly the case with
Compu$erve. All
this single source stuff, and where is the improvement...
I think that a new OS needs a little breathing room but that doesn't
mean its
advocates need to deny what they will be forced to provide by the
market place.
(You can bet your old friends at IBM once vowed never to violate the
purity of
MVS/SNA with TCP/IP and its upper level services).
From: JZ
Date: Fri, 18 Sep 92 12:41:46 PDT
Subject: Re: They Just Don't Get It.
I just don't get it either, because I couldn't force myself
to read a message which has alternating 70 character / 10
character lines. Is it bad Haiku?
(To keep the vitriol pointed in the right direction, I'll
suggest that this was the result of some braindead totally
losing piece of unix software written by someone from New
Jersey, even though that's probably not the case.)
From: JL
Date: Sun, 20 Sep 92 11:19:02 EDT
Subject: A new form of Unix mail lossage
I just had the following bit of wonderment mailed to me by
the Unix God in His aspect as "
[email protected]
(0000-uucp(0000))":
------------------------
Subject: Warning From uucp
phunt!mail phil (Date 09/18)
The job will be deleted in several days if the problem is
not corrected. If you care to kill the job, execute the
following command:
uustat -kphuntN7602
Sincerely,
mv!uucp
#############################################
##### Data File: ############################
[original message elided]
------------------------
So, anyone what to guess: Just what is it warning me about.
What is "the problem" that needs correction? Can I issue
that uustat command on any (Unix) system anywhere in the
world, or is "
[email protected] (0000-uucp(0000))" perhaps
offering me a free account on "mv.mv.com" to execute it on?
Inquiring minds want to know!
From: SS
Date: Sun, 20 Sep 1992 15:35:06 -0500
Subject: Dysacronymia
Check out the "From" field.
---------
Date: Sat, 19 Sep 1992 23:45:43 -0400
From: Unix-to-Unix Crud Protocol <
[email protected]>
Subject: Warning From uucp
Apparently-To:
[email protected]
We have been unable to contact machine 'phc' since you
queued your job.
mail phc!caresys.phc.com!malcolm_cook (Date 09/18)
Attempts will continue for a few more days.
Sincerely,
bulldog!uucp
<more barfage omitted>
From: SS
Date: Wed, 23 Sep 1992 11:48:21 -0500
Subject: Unix - The "Special Olympics" Of Business Software
Unix has been trying to pass itself off as a great OS to run
on all those stone-ugly PC clones out there. One handicap
has been the almost complete lack of useful
applications. One pundit called Unix the "special olympics"
of business software.
In other quality-control news (InfoWorld, Sept 21, Page 1):
SOLARIS 2 SHIPS SANS MULTIPROCESSING
OEMs desert OS; few users have it
by Cate Corcoran
Real gold doesn't rust, but the Bill Joy Golden Edition of
Solaris 2.0 - named after Sun's cofounder - is beginning to
look tarnished.
Symmetric multiprocessing, which was promised on Solaris
2.0, is not available, and hardware manufacturers said the
code is too buggy to ship to users.
Sun Microsystems Computer Corp., Sun's hardware arm and
SunSoft's sibling, is the only OEM currently shipping
Solaris 2.0, which SunSoft delivered to OEMs in June. Even
so, SMCC does not automatically bundle 2.0 with its
systems. Customers must special order it on disk.
Relatively few users, numbering in the "hundreds," have
Solaris 2.0, according to Bob Vieraitis, group marketing
manager of systems software and the marketing program for
SMCC.
"2.0 is a semi-beta version," said one manufacturere. "It
has a lot of real small bugs in it. It's nothing we'd want
to ship to a customer."
"... there are still some ragged edges where the road
suddenly runs out," said another.
.. <lame excuses omitted>
"We shipped out a 2.0 to customers," said a SunSoft
official. "It's up to them to decide when to put it into
their machines."
Analysts were skeptical about SunSoft's response. Commenting
on SunSoft's "we're there" campaign, which kicked off the
announcement of Solaris 2.0 in September last year, analyst
Andrew Allison said, in the words of Gertrude Stein, "There
is no there there." Allison is editor and publisher of RISC
Management Newsletter in Carmel, CA.
.. <lame promises omitted>
From: RK
Date: Wed, 23 Sep 92 15:56:26 EDT
Subject: The Way
From: PL
Date: Wed, 9 Sep 1992 14:47:36 GMT
Subject: Re: Bogus Warning Message
In an article ET writes:
> How do I stop gcc-2.2 from giving me the following message
> while still getting all of the others. I can't seem to
> find any option to get rid of it.
> warning: dbx info for template class methods not yet supported
dbx ... 2>&1 | fgrep -v 'info for template class methods not yet'
--
From: CL
Date: Thu, 24 Sep 92 15:58:12 -0400
Subject: Consistency Is Too Much Of A Drag For Unix Weenies
From: CL
Date: Thu, 24 Sep 92 16:25:49 -0400
Subject: Consistency Is Too Much Of A Drag For Unix Weenies
To exit the Bourne shell, type 'exit', unless it's a login
shell, in which case you must ctrl-d.
The first time I tried to send this message, I accidentally
typed v instead of ~v to get into the screen editor, and
losing unix Mail taunted me with "Null message body, hope
that's ok." and sent the message. Well, how amazingly
bright of it, after all, don't you often like to send people
empty mail messages? The least it could have done was ASK
if it really was okay -- then it could KNOW instead of
hope...
From: KP
Date: Thu, 24 Sep 1992 20:56-0400
Subject: Consistency Is Too Much Of A Drag For Unix Weenies
Date: Thu, 24 Sep 1992 16:25 EDT
From: CL
The first time I tried to send this message, I
accidentally typed v instead of ~v to get into the
screen editor, and losing unix Mail taunted me with
"Null message body, hope that's ok." and sent the
message. Well, how amazingly bright of it, after all,
don't you often like to send people empty mail
messages? The least it could have done was ASK if it
really was okay -- then it could KNOW instead of
hope...
This is probably some Unix implementor's idea of "modern
UI", modulo the window system part. They probably copied it
straight from the Macintosh. Maybe it looks more familiar
as:
+----------------------------------------+
| Null message body. |
| /----\ |
| | OK | |
| \----/ |
+----------------------------------------+
If I were you, I'd quit while I was ahead and probably not
send a bug report to the Unix implementors, lest you get a
fix that says:
Null message body. OK? (Y)
and that keeps asking over and over until you type "Y".
From: JL
Date: Fri, 25 Sep 92 06:58:25 EDT
Subject: Re: Consistency Is Too Much Of A Drag For Unix Weenies
This [warning about sending a mail message with a null
body] is probably some Unix implementor's idea of
"modern UI", modulo the window system part. They
probably copied it straight from the Macintosh. Maybe
it looks more familiar as:
+----------------------------------------+
| Null message body. |
| /----\ |
| | OK | |
| \----/ |
+----------------------------------------+
If I were you, I'd quit while I was ahead and probably
not send a bug report to the Unix implementors, lest
you get a fix that says:
Null message body. OK? (Y)
and that keeps asking over and over until you type "Y".
And it will have to be an UPPER CASE Y. At least for this
prompt. At others, it will have to be a lower case Y. At
still others, either will do.
And then you'll get to the one written by a budding Unix
multiculturalist, who, inspired by the Unix date parsing
routines, has gone through all the world's languages
(construed broadly) and accepts any letter that is begins a
word indicating agreement. Even in English, we have
Affirmative, Bitchin', Cool, Do It!, Execute, and so on.
Finally, of course, a True Follower of the Spirit of Unix
will realize that, since ANY letter means "go ahead",
Simplicity demands that the value not even be prompted for -
and we'll come full circle.
From: TK
Date: Fri, 25 Sep 1992 13:32-0400
Subject: Life on the Edge
From: BW
OK... /home/gn is back on-line and ready for use.
There were several read errors on the old disk
while the files were being transferred, and it's
impossible to tell exactly which files were
affected... If anyone finds any trashed or
incomplete files, let me know and I'll try to
retreive them from backup tapes.
Doesn't it give you that warm, confident feeling to know
that things aren't Quite Right, but that you'll have to wait
'til you need something to know Just What? Life on the
Edge.
Get with the program -- remember -- 90% is good enough. If
it's good enough for Ritchie, it's good enough for me!
From: DC
Date: Fri, 25 Sep 92 12:09:38 -0700
Subject: KRONOS
From: Someone
If you have a serial line between your mac and your unix
machine, then you can run emacs. The UW program, which
is in the public domain, will support multiple windows,
the meta key, and mouse-based text editing under emacs
(it turns mouse hits into escape sequences). It also
supports window resizing, etc. You run a program on the
unix end and it and the mac program conspire to do all
the i/o multiplexing for the different windows. The one
problem is that you have to quit out and run kermit if
you want to transfer files.
This reminds me of TSO and KRONOS. Remember them? For the
370 and Cyber 6700 respectively. They were ``time sharing
systems'' built on top of batch systems. You actually typed
at a channel, which took the command lines you typed,
macroexpanded them into a huge virtual card deck, and
submitted them to the mainframe as a regular MVS batch job.
The mainframe read the card deck, ran the program, and
dumped your output to what it thought was a line printer,
except it was actually a port on the channel. The channel
then read the dump and figured out what it meant and gave
you back output on your screen that resembled what you'd get
if you were running a real time sharing system. Except that
it couldn't always figure it out, like if for instance your
program ABENDed, in which case you'd get screens and screens
full of JCL and coredump.
Come to think about it, unix systems mostly seem to be like
this. X for instance. Immense piles of code trying to give
you modern functionality but failing to insulate you from
the fact that you are really running a vintage 1970 high
schooler's half-assed spacewar program. All done with
``shell scripts,'' i.e. virtual card decks.
From: IH
Date: Fri, 25 Sep 92 18:37:17 EDT
Subject: Re: KRONOS
Well, actually, KRONOS didn't have any vitual card readers
or anything like that. Command lines weren't virtual batch
jobs, although terminal sessions kind of were. There was a
PPU program called "1AJ", as I remember, which was in charge
of getting the next line from the command stream and in the
case of timesharing jobs, it would go off and talk to the
tty driver to get it. If I remember properly, it was kind
of unix-like in that everything looked like a file stream,
but it wasn't byte-oriented. Perhaps it was more like the
anti-unix: everything looks like a device, including files.
Anyhow, it was conceptually cleaner than TSO.
God, my lost youth...
P.S. The UW program isn't like that. It's more like
SUPDUP, but with multiplexed i/o so you can have multiple
ptys.
From: DC
Date: Fri, 25 Sep 92 15:56:38 -0700
Subject: Re: KRONOS
Huh. I distinctly remember KRONOS commands that didn't work
dumping the JCL they had expanded into on my screen. Mind
you this was somewhere in the Lower Permian, not to mention
Iowa, so maybe the relevant parts of my brain have
fossilized and will have to be reconstructed by
paleontologists using the polymerase chain reaction.
The other winNing thing about KRONOS, as I remember it, was
that the Cyber was a 60 bit machine with 6-bit byte
instructions. Fine for ASR-33s, not so fine for the zyzzy
new glass ttys with (wow!) lower case. So 8-bit ascii was
stored in 12-bit fields, not packed. The fake time-sharing
channel knew about this, but the Cyber didn't. So lower
case worked fine so long as the channel could parse what the
Cyber was saying, but if it didn't you'd get the raw six-bit
output, with every other character making sense. Rather
like the meta bit in unix.
Maybe KRONOS worked differently by the time you were using
it? I'd say I had it confused with TSO, but I only ever
used 370s the macho way, with a genuine 029 punch. Those
were the days.
From: JL
Date: Fri, 25 Sep 92 22:40:06 EDT
Subject: Re: Life on the Edge
From: BW
OK... /home/gn is back on-line and ready for use.
There were several read errors on the old disk
while the files were being transferred, and it's
impossible to tell exactly which files were
affected... If anyone finds any trashed or
incomplete files, let me know and I'll try to
retreive them from backup tapes.
Doesn't it give you that warm, confident feeling to
know that things aren't Quite Right, but that you'll
have to wait 'til you need something to know Just What?
Life on the Edge.
Get with the program -- remember -- 90% is good enough.
If it's good enough for Ritchie, it's good enough for
me!
"It's State of the Art!" "But it doesn't work!" "That IS
the State of the Art!"
Alternatively: "If it worked, it wouldn't be research!"
The only problem is, outside of the demented heads of the
Unix weenies, Unix is neither State of the Art nor research!
From: AB
Date: Sat, 26 Sep 92 01:25:32 EDT
Subject: Re: KRONOS
From: IH
Date: Fri, 25 Sep 92 18:37:17 EDT
Well, actually, KRONOS didn't have any vitual card
readers or anything like that....
***BBZZZATTT*** I don't hear enough Unix Hatred in these
messages! Come on, guys, I know you are both capable of
appropriate rabid frothing.
Actually, I do like reading reminiscences about how thing
worked in the good old days, but my role as Most Exalted
Enforcer of Unix Loathing and Detestation demands that I put
my personal prejudices aside and censure you both for this
transgression.
IH, your punishment will be to understand the reason for
the "-n" argument to the "rsh" command.
DC, your punishment is to read your local "sendmail.cf"
file.
From: RS
Date: Sat, 26 Sep 1992 13:11:35 -0500
Subject: Even the Washington Post Sees YP Clearly
I walked into my office this afternoon and found that
someone had left a copy of Friday's _Washington Post_ on my
desk open to the editorials page.
The lead editorial's headline was "Another Failure for the
NIS"
From: GR
Date: Sat, 26 Sep 92 16:02:24 -0400
Subject: cpio Really Knows That's Going On...
Of course, I ran into this because I was handed a couple of
old Unix backups written in unknown format, and I tried all
the random tools, none of which do everything (or even a few
things) right and I was getting desperate.
I can't understand how an OS that has survived so many years
(or propagated itself for so many years) and is supposedly
portable etc. could do so without a standard backup format.
Of course, Unix weenies probably never restore a backup (if
they even make them), they are too used to having 47 copies
of everything since they can't trust themselves not to type
``rm -rf'' accidentally, the file system not to clobber
their files on a crash, or NFS not to insert 0-pages in the
middle of their file because it is such a wonderful
stateless protocol.
Ultimately it probably doesn't matter to them since their
software is clearly not worth preserving.
Aargh!
From: DC
Date: Sat, 26 Sep 92 17:41:35 -0700
Subject: Re: KRONOS
I humbly beg your Most Exalted pardon for my unforgivable
transgression.
My site runs mmdf, so I am unable to properly abase myself
by reading sendmail.cf. Perhaps instead you will accept as
fractional atonement the following unworthy offering:
God damn it, why is it that, presented with a standard
mailer that doesn't work for shite, instead of fixing it or
writing a new one that does, unix weenies propagate new
mailers that don't work for shite? Every few weeks I get
some new kind of bogus error message that plainly comes from
some mailer I've never seen before. (Like that great new
message that runs ``The following message was probably sent
either by you or to you, and it failed for some reason, not
necessarily here.'') There have got to be dozens of unix
mailers out there, scurrying about dark corners of the
internet and multiplying about like cockroaches.
It's like when I was in fourth grade and found this keen
rubbish dump out in the woods that was full of abandoned
machinery and thought how neat it would be to build a robot
out of it all and went to class the next day and proudly
boasted that I had actually done so. It's the sort of
teenage attitude where you suddenly realize you can actually
do stuff and get big ideas and start on glorious projects
without having any conception of followthrough and get bored
in the middle when it doesn't go so great and leave a big
mess.
Unix is all written by these teenagers (chronological or
emotional) who say ``oh wow, I bet I could write a mailer,
wouldn't that be great, I'll add all these winning features,
and it'll be so fun and cool'' and then they graduate or
discover sex or something and we're stuck running their
half-assed code.
From: IH
Date: Sun, 27 Sep 92 14:17:59 EDT
Subject: Re: KRONOS
Date: Sat, 26 Sep 92 01:25:32 EDT
From: AB
From: IH
Date: Fri, 25 Sep 92 18:37:17 EDT
Well, actually, KRONOS didn't have any vitual card
readers or anything like that....
***BBZZZATTT*** I don't hear enough Unix Hatred in these
messages! Come on, guys, I know you are both capable of
appropriate rabid frothing.
Actually, I do like reading reminiscences about how
thing worked in the good old days, but my role as Most
Exalted Enforcer of Unix Loathing and Detestation
demands that I put my personal prejudices aside and
censure you both for this transgression.
Ian, your punishment will be to understand the reason
for the "-n" argument to the "rsh" command.
Oh, but AB, AB! I already understand the reason for the
"-n" argument. Can't you give me a worse punishment? Huh
huh? Oh please punish me. I use Unix because I love
punishment!
Hurt me, AB! Hurt me! Beat me! Whip me! Make me read
the named sources! Make me debug the -ms macroset! Make me
use a shell which uses question marks for both wild carding
AND command completion, so that I can't wild card without
typing control V!
From: EW
Date: Mon, 28 Sep 92 09:03:05 PDT
Subject: [UUCP Accounting for
[email protected]]
Speaking of new mailers that don't work for shite, The
following just came in to my box apparently sent to the
whole SLUG mailing list. Guess we're gonna have to chip in
for the euro-mail bill...
-----------------------------
Return-Path: <@IU.AI.SRI.COM:
[email protected]>
From:
[email protected] (UUCP administrator)
X-Mailer: SCO System V Mail (version 3.2)
To:
[email protected]
Subject: UUCP Accounting for
[email protected]
Date: Sat, 26 Sep 92 14:24:34 MET
Accounting information for
[email protected], please feel free to ignore it:
09/23 18:25 RX 2314 bytes from
[email protected]
Summary for user
[email protected]
Total for Belgium sites = 0 byte(s) = 0 BEF
Total for European sites = 0 byte(s) = 0 BEF
Total for Other sites = 2314 byte(s) = 14 BEF
Grand-total 2314 bytes = 14 BEF
New version of accounting. Please mail to
[email protected] in
case of problems
From: KH
Date: Mon, 28 Sep 92 17:40:47 EDT
Subject: We Don't Need No Stinking Debuggers
While linking a large C++ program on the HP 9000 family, the
following error occurs randomly:
pdbx: internal error, file won't be debuggable (still a valid executable)
No indication of where the error is or what caused it. Even
more despicable is the fact that the executable is not
necessarily valid either (i.e. code that is *known* to be
correct will fail in mysterious ways).
When this error occurred, we used to search our changes for
*anything* that might have caused the error (e.g. static
variables in function scope seem to confuse the poor
beast... sometimes). Of course, this is a recipe for
madness if you have just changed 15 files or so. Then one
of my coworkers told me his solution: he just keeps adding
more code (doesn't particularly matter what file you choose)
until the error goes away and the file becomes debuggable
again. Debuggers like this support Unix family value #1: if
a small piece of shite doesn't work, add more, maybe a big
ball of shite will work.
From: RM
Date: Tue, 29 Sep 92 22:44:17 -0400
X-Nsa-Fodder: DES genetic Nazi Kennedy Uzi colonel Ortega Rule Psix nuclear
Subject: an average day of unix hacking
/u: write failed, file system is full
/u: write failed, file system is full
/u: write failed, file system is full
/u: write failed, file system is full
/u: write failed, file system is full
/u: write failed, file system is full
/u: write failed, file system is full
/u: write failed, file system is full
/u: write failed, file system is full
/u: write failed, file system is full
/u: write failed, file system is full
/u: write failed, file system is full
/u: write failed, file system is full
/u: write failed, file system is full
/u: write failed, file system is full
/u: write failed, file system is full
read: Network is unreachable
Connection closed.
From: RA
Date: Sat, 3 Oct 92 20:04:26 EDT
Subject: Fun With Zone Transfers And Your Friend, BIND
Well, there's a new PD11:<CHIVES.V1.SOURCE>ZT.EXE, which
does have the bitvector stuff fixed. But it still can't
transfer the TURK.PICK zone from TACOM-EMH1.TURK.PICK, because
the TURK.PICK zone it receives has a bunch of WKS RRs with
the IP protocol field set to all ones. This is illegal per
RFC-1035 3.4.2 and the Assigned Numbers RFCs.
It appears that this is what BIND does when one enters a
completely bogus protocol keyword in the original master
file: BIND issues a syslog() warning but then goes on to
build a WKS RR with the -1 failure indicator as its protocol
field. BIND is the antichrist.
These values are also visible in DOMAIN:ARMY.ZONE, and in the output
of a "dig axfr turk.pick @tacom-emh1.turk.pick" command on unix. The
offending WKS RRs are:
CAMPBELL-IGNET.TURK.PICK. 518400 WKS 999.999.999.999
SHAPE-EMH1.TURK.PICK. 518400 WKS 999.999.999.999
VERONA-EMH1.TURK.PICK. 518400 WKS 999.999.999.999
NCAD-TEP1.TURK.PICK. 518400 WKS 999.999.999.999
FTRILEY-ACRIS.TURK.PICK. 518400 WKS 999.999.999.999
GREELY-TS1.TURK.PICK. 518400 WKS 999.999.999.999
Now, you guys have a decision to make. Do you want to try
to fix this right, ie, get the TURK.PICK administrators to
fix their zone files, or do you want a patch for CHIVES to
cope with this, or both? If you want a patch, what should
the patch do when it detects this error?
From: FW
Date: Sat, 3 Oct 1992 19:29 MDT
Subject: Re: Fun With Zone Transfers And Your Friend, BIND
In a way, BIND does the right thing in flagging the bogus
argument, leaving it up to the resolvers to ignore (or set
further flags to complain or call attention to the problem).
Following the philosophy of generous acceptance (i.e.,
idiotproofing), CHIVES should log, but otherwise ignore the
bogus argument, and, the faulty zone file should be fixed at
the source.
From: AB
Date: Sat, 3 Oct 92 22:56:46 EDT
Subject: Re: Fun With Zone Transfers And Your Friend, BIND
From: AB
Date: Sat, 3 Oct 92 23:05:22 EDT
Subject: Re: Fun With Zone Transfers And Your Friend, BIND
@*+#@$!@*+#!!! Sorry about the empty message I just sent.
What's especially annoying about having done that is that I
was trying to -reduce- the inappropriate traffic on the
Unix-Haters mailing list by reminding folks that this is
-not- the place to have design discussions about domain name
system software. Please be more careful than I am.
From: SG
Date: Sat, 3 Oct 92 23:40:05 -0400
Subject: Overdue Mail
Yes, but what does this have to do with SENDMAIL?
Got me. Why is it that an operating system running on a VAX
needs to have statically allocated disk buffers?
Begin forwarded message:
From: RB
Date: Sat, 3 Oct 92 21:51:02 -0400
Subject: Overdue mail
Several days ago, I had to reboot scylla; it apparently hung
(and was off the net). I couldn't even log into the
console. However, the network did return for a few minutes
prior to rebooting it, and I was able to remotely login (my
console login hung); I discovered that various processes
were waiting in mfree, and just after that discovery, it
hung again.
Summary: I believe the machine died because it ran out of
mbufs. If we believe we are going to be using this machine
for much longer, we should consider building a kernel with
more mbufs (ie. add an NMBCLUSTERS option to the kernel
config).
From: MP
Date: Sat, 3 Oct 1992 22:05:33 -0400
Subject: Re: Overdue mail
>Several days ago, I had to reboot scylla ...
>Summary: I believe the machine died because it ran out of
>mbufs.
This would be consistent with the log message from about that time:
% zcat /usr/adm/messages.0.Z | grep mbuf
Sep 30 00:32:16 scylla vmunix: mbuf map full
From: RS
Date: Sun, 4 Oct 92 10:45:00 -0400
Subject: Echo - Whip Me, Hurt Me, Make Me Bleed...
(excerpt from a Makefile...)
# Here in the future with advanced operating systems like
# UNIX(tm), you get to go through all sorts of groovy
# gyrations to implement this in a manner that works under
# both System V and BSD. Go figure.
date:
@echo "static char DateCompiled[] = '${DATE}'" | sed s/\'/\"/g > date.c
From: RM
Date: Tue, 6 Oct 1992 23:05:15 PDT
Subject: Bucket O'Bits Filesytems
From: DF
Date: 7 Oct 92 03:36:37 GMT
Subject: Re: Multi uP P5 Systems
In an article RF writes:
>
>In another article WD writes:
>|> [of VMS]
>|> I sure hope so. Any o/s which puts file types in the o/s
>|> instead of the program is really creating problems for the
>|> user, and I find that more of a problem than the user
>|> interface. If programs really want a "$ delimited left
>|> handed nybble swapped hexadecimal" file type, let it be
>|> done in the program or shared library, and not at a level
>|> when all user-written file transfer and backup programs
>|> have to deal with it. As my youngest says "yucky-poo!"
Huh? Let's think about this.
Tighter integration of file types to the OS are not a
problem. In my experience, UNIX offers the weakest file
maintenance offerings in the industry, save for MS-DOS. In
using Tandem Guardian and VMS I've found that ultimately,
one could:
* Back up files.
* Transfer files.
* Convert files.
..much more easily and safely than with UNIX. Yes, it was
between Guardian or VMS systems but instead of going into an
"open systems" (whatever THOSE are) snit, read on.
As a result:
* Each RDBMS has its own backup and restore facility of
varying functionality, quality, and effectiveness,
complicating support for sites adopting more than one
RDBMS.
* All existing UNIX backup and restore facilities are highly
dysfunctional compared to similar facilities under the
aforementioned operating systems. They can make only the
grossest assumptions about file contents (back it up or
not, bud?) and thus cause vast redundancy in backups; if
you change a single byte in the file, you back up the
whole thing instead of changed records.
* Transferring files from system to system under UNIX
requires that all layers of functionality be present on
both sides to interpret files of arbitrary form and
content. Embedded file systems ensure that file transfer
is enhanced because the interpretation and manipulation
facilities will be there even if the highest layers
aren't (ie: you can at least decompose the file). Find
me one person who guarantees they can decompose an Oracle
or Ingres file (ie: someone who has a product that will
always do it and guarantees it'll work for all successive
releases of these packages).
Once one strips away the cryptology, the issue is control.
UNIX is an operating system that offers the promise of
ultimate user control (ie: no OS engineer's going to take
<feature> away from ME!), which was a good thing in its
infancy, less good now, where the idiom has caused huge
redundancies between software packages. How many B*Tree
packages do we NEED? I think that I learned factoring in
high school; and that certain file idioms are agreed to in
the industry as Good Ideas. So why not support certain
common denominators in the OS?
Just because you CAN do something in user programs does not
mean it's a terribly good idea to enforce it as policy. If
society ran the same way UNIX does, everyone who owned a car
would be forced to refine their own gasoline from barrels of
crude...
From: RS
Date: Wed, 7 Oct 92 13:45:58 EDT
Subject: Lint Is Useless
rs@unit [7] % cat foo.c
main()
{
char foo[500];
(void) printf("%s", foo);
free(foo);
return(0);
}
rs@unit [8] % lint foo.c
rs@unit [9] %
From: SG
Date: Thu, 8 Oct 92 08:26:17 -0400
Subject: Re: Lint Is Useless
Of course Lint is useless. It's one of those programs that
was written as a student project N^2 years ago and has never
been debugged or brought up to date.
Try giving LINT ANSI-C and see what it does.
Try giving the Sun compiler ANSI-C, for that matter.
From: RS
Date: Thu, 8 Oct 92 08:54:01 EDT
Subject: Re: Lint Is Useless
From: SG
Date: Thu, 8 Oct 92 08:26:17 -0400
Of course Lint is useless. It's one of those programs
that was written as a student project N^2 years ago and
has never been debugged or brought up to date.
I was unaware that proscriptions against free()ing pointers
you had never malloc()ed and referencing uninitialized
variables were a recent development, but isn't it great that
we have (void) so that lint doesn't complain when I don't
check the return status from printf()? Even BASIC has
on-error-goto - too bad Kerninghan and Ritchie couldn't be
bothered to put an error handler hook into the language.
By the way, that free() didn't crash the program. Unix
memory allocation routines are so nice and trusting - they
just prepend a couple of bytes to your pointer and then add
it to the free list, regardless of where the pointer points
- if you own the memory, you just freed it
(congratulations). The real fun starts when you do your
next malloc and get a segmentation violation. In my case, I
was left scratching my head and wondering why 6 calls deep
into getpwnam(3) (a supposedly stable library call, but hey,
this is Unix - there are no guarantees), my program suddenly
segfaulted without the slightest indication why. Pfft.
Try giving LINT ANSI-C and see what it does.
Isn't it nice that all the different implementations of
ANSI-C are *less* compatible with each other than PCC-based
compilers? Standards are soooooo wonderful.
Try giving the Sun compiler ANSI-C, for that matter.
With the advent of Solaris, Sun will address that problem by
not giving you a C compiler.
From: RS
Date: Thu, 8 Oct 92 08:58:20 EDT
Subject: Re: Lint Is Useless
Date: Wed, 7 Oct 92 19:14:37 PDT
From: JZ
Wow, that's great, I've never been able to get lint to
do anything more productive than tell me that `printf'
is an unknown function or some such nonsense. You've
reduced its output to something readable, I congratulate
you.
Apparently I've been doing this too long. With a humble bow
in AB's direction, I submit myself for re-education.
From: DH
Date: Thu, 8 Oct 92 09:13:24 EDT
Subject: A Positive Development?
From: RS
Date: Thu, 8 Oct 92 08:54:01 EDT
With the advent of Solaris, Sun will address that
problem by not giving you a C compiler.
Sounds like a step in the right direction. Perhaps the next
fix will be to leave out register windows. Then they could
leave out Unix!
It's getting better all the time.....
From: DH
Date: Thu, 8 Oct 92 09:58:14 -0400
Subject: Re: A Positive Development?
Subject: A Positive Development?
From: RS
Date: Thu, 8 Oct 92 08:54:01 EDT
With the advent of Solaris, Sun will address that
problem by not giving you a C compiler.
Sounds like a step in the right direction. Perhaps the
next fix will be to leave out register windows. Then
they could leave out Unix!
It's getting better all the time.....
That would be the Bill Joy Golden Shower Edition, right?
From: DW
Date: Thu, 8 Oct 92 13:12:40 EDT
Subject: Re: Lint Is Useless
From: RS
Date: Thu, 8 Oct 92 08:54:01 EDT
By the way, that free() didn't crash the program. Unix
memory allocation routines are so nice and trusting
Actually, that depends on whether you're talking about Unix,
or Unix, or Unix, each of which behaves completely
differently with regard to this sort of thing.
From: JL
Date: Sun, 11 Oct 92 11:52:15 EDT
Subject: Re: It's Always Good News In Unix Land
You've failed to properly understand The All. Look, here
you are worrying about some silly no.such.file that you
haven't even gotten around to creating yet - I mean, if you
HAD gotten around to creating it, tar would have written it
to the archive for you, so what's the big deal? In all this
worrying, you are ignoring all the things that went well.
Unix didn't scribble all over the file system. It didn't
scribble all over main memory. It didn't clear your screen.
It didn't crash. It didn't forward all your pending mail to
the University of Inner Mongolia. Just THINK of all of the
non-errors during the execution of your silly little test of
tar. Why do you insist on looking at the trivial little
glitches, when so much is right with the world?
(Besides, we all know that "tar" stands for "tape ar", but
here you're using it without a tape - and it doesn't have
anything to do with ar anyway. Maybe you would have done
better by using rm instead.)
I know --- I shouldn't have expected anything
consistent, useful, documented, speedy, or even
functional...
Ah, you started off mentioning "consistent". Look, there
are a couple of broad classes of Unix tools. Two of the
biggest classes accept their options as "-" followed by one
or more letters. Of those commands, some require the
options to come first, while others let you write them
anywhere on the line, interspersed with file arguments. (Of
course, there are finer subdivisions: Single- or
multi-character option names? If single, can you use
multiple options with a single dash (-ab) or must you use
two dashes (-a -b). But we won't mention that.) Those
classes, and all the others I won't go into, form the
consistent Unix user interface. (Yes, it's consistently a
Unix user interface. I mean, when was the last time you saw
it change on you - at least between reboots?)
Anyhow, look at your command line. It's screaming "wash me
please". No, actually, it's screaming "where's the dash"?
If you're Mister Average American Joe, you know that Unix
options start with a dash. (Or maybe a plus; but let's not
worry about that now.) So how come tar's first argument is
an option, but has no dash?
Consistency. Feh, tar's command syntax isn't in the large
class of consistent Unix command input syntaxes; why would
you expect its output value to be in the similarly large
class of consistent result values? It's consistent in its
lack of willingness to surrender its freedom of reading and
speech to the petty tyranny of people like you.
From: IH
Date: Mon, 12 Oct 92 12:34:03 EDT
Subject: Creative Writing Project
This is an excerpt from a series I started writing last
summer called "Blood on the Bus," when I had to spend a
month installing a unix cluster. I don't think I'll ever
get around to writing any more of it, so I humbly submit
this miserable fragment of text to uberflamemeister Bawden
as penance for my detestable neglect of proper flamage in
the past.
Unix was a program gone bad. Born into poverty, its
parents, the phone company, couldn't afford more than a roll
of teletype paper a year, so Unix never had decent
documentation and its source files had to go without any
comments whatsoever. Year after year, Papa Bell would
humiliate itself asking for rate increases so that it could
feed its child. Still, unix had to go to school with only
two and three letter command names because the phone company
just couldn't afford any better. At school, the other
operating systems with real command names, and even command
completion, would taunt poor little Unix for not having any
job or terminal management facilities or for having to use
its file system for interprocess communication and locking.
Then, bitter and emasculated by its poverty, the phone
company began to drink. During lost weekends of drunken
excess, it would brutally beat poor little Unix about the
face and neck. Eventually, Unix ran away from home. Soon
it was living on the streets of Berkeley. There, Unix got
involved with a bad crowd. Its life became a degrading
journey of drugs and debauchery. To keep itself alive, it
sold cheap source licenses for itself to universities which
used it for medical experiments. Being wantonly hacked by
an endless stream of nameless, faceless undergraduates, both
men and women, often by more than one at the same time, Unix
fell into a hell-hole of depravity.
And so it was that poor little Unix began to go insane.
It retreated steadily into a dreamworld, the only place
where it felt safe. It took heroin and dreamed of being a
real operating system. It took LSD and dreamed of being a
raspberry flavored three-toed yak. It liked that better.
As Unix became increasingly attracted to LSD, it would spend
weekends reading Hunter Thompson and taking cocktails of
acid and speed while writing crazed poetry in which it found
deep meaning but which no one else could understand:
$sed <$mf >$mf.new -e '1,/^# AUTOMATICALLY/!d'
make shlist || ($echo "Searching for .SH files..."; \
$echo *.SH | $tr ' ' '\012' | $egrep -v '\*' >.shlist)
if $test -s .deptmp; then
for file in `cat .shlist`; do
$echo `$expr X$file : 'X\(.*\).SH'`: $file config.sh \; \
/bin/sh $file >> .deptmp
done
$echo "Updating $mf..."
$echo "# If this runs make out of memory, delete /usr/include lines." \
>> $mf.new
$sed 's|^\(.*\.o:\) *\(.*/.*\.c\) *$|\1 \2; '"$defrule \2|" .deptmp \
>>$mf.new
else
make hlist || ($echo "Searching for .h files..."; \
$echo *.h | $tr ' ' '\012' | $egrep -v '\*' >.hlist)
$echo "You don't seem to have a proper C preprocessor. Using grep instead."
$egrep '^#include ' `cat .clist` `cat .hlist` >.deptmp
$echo "Updating $mf..."
<.clist $sed -n \
-e '/\//{' \
-e 's|^\(.*\)/\(.*\)\.c|\2.o: \1/\2.c; '"$defrule \1/\2.c|p" \
-e d \
-e '}' \
-e 's|^\(.*\)\.c|\1.o: \1.c|p' >> $mf.new
<.hlist $sed -n 's|\(.*/\)\(.*\)|s= \2= \1\2=|p' >.hsed
<.deptmp $sed -n 's|c:#include "\(.*\)".*$|o: \1|p' | \
$sed 's|^[^;]*/||' | \
$sed -f .hsed >> $mf.new
<.deptmp $sed -n 's|c:#include <\(.*\)>.*$|o: /usr/include/\1|p' \
>> $mf.new
<.deptmp $sed -n 's|h:#include "\(.*\)".*$|h: \1|p' | \
$sed -f .hsed >> $mf.new
<.deptmp $sed -n 's|h:#include <\(.*\)>.*$|h: /usr/include/\1|p' \
>> $mf.new
for file in `$cat .shlist`; do
$echo `$expr X$file : 'X\(.*\).SH'`: $file config.sh \; \
/bin/sh $file >> $mf.new
done
fi
Eventually, Unix began walking down Telegraph Avenue talking
to itself, saying "Panic: freeing free inode," over and over
again. Sometimes it would accost perfect strangers and yell
"Bus error (core dumped)!" or "UNEXPECTED INCONSISTENCY: RUN
FSCK MANUALLY!" at them in a high pitched squeal like a
chihuahua with amphetamine psychosis. Upstanding citizens
pretended it was invisible. Mothers with children crossed
to the other side of the street.
Then one evening Unix watched television, an event which
would change its life. There it discovered professional
wrestling and knew that it had found its true calling. It
began to take huge doses of corticosteroids to build itself
up even bigger than the biggest of the programs which had
beaten it up as a child. It ate three dozen pancakes and
four dozen new features for breakfast each day. As the
complications of the steroids grew worse, its internal
organs grew to the point where Unix could no longer contain
them.
First the kernel grew, then the C library, then the
number of daemons. Soon one of its window systems was
requiring two megabytes of swap space for each open window.
Unix began to bulge in strange, unflattering places. But
Unix continued to take the drugs and its internal organs
continued to grow. They grew out its ears and nostrils.
They placed incredible stresses on Unix's brain until it
finally liquefied under pressure. Soon Unix had the mass of
Andre the Giant, the body of the Elephant Man, and the mind
of a forgotten Jack Nicholson character.
The worst strain was on Unix's mind. Unable to
assimilate all the conflicting patchworks of features it had
ingested, its personality began to fragment into millions of
distinct, incompatible operating systems. People would
cautiously say "good morning Unix. And who are we today?"
and it would reply "Beastie" (BSD), or "Domain", or "I'm
System III, but I'll be System V tomorrow."
Psychiatrists labored for years to weld together the two
major poles of Unix's personality, "Beasty Boy", an
inner-city youth from Berkeley, and "Belle", a southern
transvestite who wanted a to be a woman. With each attempt,
the two poles would mutate, like psychotic retroviruses,
leaving their union a worthless blob of protoplasm requiring
constant life support remain compatible with its parent
personalities.
Finally, unbalanced by its own cancerous growth, Unix
fell into a vat of toxic radioactive wombat urine, from
which it emerged, skin white and hair green. It smelled
like somebody's dead grandmother. With a horrible grin on
its face, it set out to conquer the world.
From: WA
Date: Mon, 12 Oct 92 16:21:24 EDT
Subject: Automatic Creation Of Aliases In ksh
The following came across my electronic desk, in the form of
a serious request for help:
I have a question about the cat command. It seems
that after you run the cat command the first time,
the ksh creates an alias for the cat command. This
seems to be a UNIX standard on HPUX, IBM and
Domain/OS. Anyone know why it does this, and can you
turn it off??
Weird....
From: RA
Date: Mon, 12 Oct 92 20:33:47 EDT
Subject: Automatic Creation Of Aliases In ksh
From: WA
Date: Mon, 12 Oct 92 16:21:24 EDT
I have a question about the cat command. It seems
that after you run the cat command the first time,
the ksh creates an alias for the cat command. This
seems to be a UNIX standard on HPUX, IBM and
Domain/OS. Anyone know why it does this, and can
you turn it off??
I believe this is an example of what ksh calls a "tracked
alias." The theory being that twinkie boxes don't have
enough spare cycles to actually look at the filesystem every
time you use an Important Program. Since "cat" is the
archtypical example of the unix "tiny tools that do one
thing well" (even if it's never used for that one thing and
its normal use is completely stupid), it is clearly an
Important Program, so ksh needs to track this for you to
allow you to do quickly things you never wanted to do at
all.
From: TM
Date: Mon, 12 Oct 92 18:56:53 -0700
Subject: [Another Reason To Hate Solaris]
------- Forwarded Message
From: BK
Date: Mon, 12 Oct 92 18:44:01 PDT
Subject: Another Reason To Hate Solaris
The ENOTEMPTY errno doesn't exist under System V Release 4.
So Sun made their rmdir() syscall set errno to EEXIST
instead. That makes you get
% rmdir fulldir
rmdir: File exists
%
when you try to remove a non-empty directory. That's not
intuitive to me at all.
------- End of Forwarded Message
From: GR
Date: Tue, 13 Oct 92 14:59:14 -0400
Subject: Directories Are Just Files
So everyone knows that files are just directories. So
everyone knows that this is a win, right?
Jinx! fgrep -i mips *
comp.pkg: (files "machines/mips/decls")
machines:^@^B0^]^@^L^@^A.^@^@^@^@^B^@^Y^@^L^@^B..^@^@^@^B`^A^@^L^@^AC^@^@^@^@^B0^^^@^P^@^Fbobcat^@^@^@^B0^_^@^P^@^Di386^@^@^@^@^@^B0 ^@^P^@^Dmips^@^@^@^@^@^B0!^@^T^@^Hspectrum^@^@^@^@^@^B0"^C\230^@^Cvax^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Jinx!
Clearly this is what everyone wants.
BTW, I had to replace the NUL characters (etc.) in the above
line with caret-atsigns because when I tried to send the
message the first time the line did not appear since some
Berserkely C blabberer with less than two fingers of
forehead decided to write a mailer that reads messages with
gets or some equally braindead substitute for an input
reader and just drop the non-printable characters (rather
than bounce and complain or something semi-reasonable).
From: AB
Date: Wed, 14 Oct 92 17:21:29 EDT
Subject: [Patch For scm4a12.tar.Z]
Date: 12 Oct 92 18:52:48 GMT
From: AJ
Subject: patch for scm4a12.tar.Z
Many people reported a bug in scl.c. The following is a
patch for scm4a12.tar.Z. The other corrections are from
[email protected]. I have just updated the versions
on altdorf.one.two.thr:archive/scm/scm4a12.tar.Z and
nexus.yorku.ca:pub/scheme/new/scm4a12.tar.Z
The lesson I just learned is: When developing with Make
on 2 different machines, make sure their clocks do not
differ by more than one minute.
[ ... diffs deleted ... ]
Raise your hand if you remember when file systems had
version numbers.
From: JL
Date: Wed, 14 Oct 92 17:24:35 EDT
Subject: Behind The Times, Or Ahead Of The Game?
While they didn't SAY Unix, it's clear that's what they had
in mind.
From: JR
Subject: Revisionism
------- Start of forwarded message -------
From: CB
Subject: [Yuck]
Date: Wed, 14 Oct 92 11:29:57 EDT
From: PW
Date: Wed, 14 Oct 92 10:12:01 EDT
Subject: Yuck
Copied from another sorce...
- -----------------------------
I stumbled across this little item in the current (October
1992) issue of Communication of the ACM:
"BANKS UNDERDRAWN... The banking industry spent over a
billion dollars on technology last year, yet they are not
even close to employing leading-edge tools. A new survey
.. indicates that over 75% of bank computer programs are
still written in Cobol and 84% of banking software is
designed for mainframes, not PCs. Moreover, 80% of the
software used by banks is over six years old and only 37% of
their locations are networked. The report reveals most
banks are simply not investigating new advances in computer
applications." [Communications of the ACM, Vol 35, No 10,
p.9]
A translation:
BANKS CONSERVATIVE... The banking industry spent over a
billion dollars on techology that works, rather than the
latest glitzy play toy. A new survey ... indicates that
over 75% of bank computer programs are written in a language
appropriate to the task as opposed to trying to force their
models into the latest Object Oriented fad and 84% of
banking software is designed to run on systems that have low
mean time between failures, juggle hundreds of users, handle
huge databases, and push megabytes at high rates, not tiny
little machines that crash with great regularity, are
designed for a single user, if even that, have miniscule
disks, and have bandwidth the approximating that of a
sclerotic soda straw. Moreover, 80% of the software used by
banks has been fairly well debugged and only 37% of their
locations are open to attack by thirteen year olds with
modems and a lot of time on their hands. The report reveals
most banks are simply not chasing the latest fad in confuser
science and piddling their money away on recoding working
applications unnecessarily.
- --------------------------
- --
------- End of forwarded message -------
From: JZ
Date: Wed, 14 Oct 92 19:05:07 PDT
X-Windows: Sometimes you fill a vacuum and it still sucks.
Subject: [Fwd: Returned mail: Deferred]
I must have gotten this little packet of joy a hundred times
in the last two days:
------- Start of forwarded message -------
Date: Thu, 15 Oct 1992 02:54:49 +0100
From: Mail Delivery Subsystem <MAILER-DAEMON%
[email protected]>
To:
[email protected]
Subject: Returned mail: Deferred
----- Transcript of session follows -----
554 procmail died because of segmentation violation (11)--requeueing message
----- Unsent message follows -----
Received: from lucid.com by sun0.thp.uni-koeln.de with SMTP id AA25354
(5.65c/IDA-1.4.4 for sk); Tue, 13 Oct 1992 20:30:12 +0100
Date: Tue, 13 Oct 1992 20:30:12 +0100
From:
[email protected]
Message-Id: <
[email protected]>
Apparently-To: <
[email protected]>
------- End of forwarded message -------
Yeah, that's the whole message. No message so brief has
even passed through here. I picture a gap-toothed cartoon
idiot repeatedly whacking itself in the head with a mallet.
Or a pair of five-year-olds having an argument: "Is not."
"Is too!" "Is not!" "Is too!" "Is not!" "Is too!" Well
if it got a segmentation fault this time, maybe it will work
the next time! Hey, it could happen.
From: RA
Date: Thu, 15 Oct 92 1:07:14 EDT
Subject: Re: [Patch For scm4a12.tar.Z]
Um, will raising a clawed forefoot do, AB? As everybody
keeps telling me, file systems so primitive that they needed
version number support in the operating system existed so
long ago that hands hadn't yet evolved.
From: AW
Date: Thu, 15 Oct 1992 09:22-0400
Subject: Re: [Patch For scm4a12.tar.Z]
Date: Wed, 14 Oct 1992 17:21 EDT
From: AB
Date: 12 Oct 92 18:52:48 GMT
From: AJ
Subject: Patch For scm4a12.tar.Z
Many people reported a bug in scl.c. The following
is a patch for scm4a12.tar.Z. The other corrections
are from
[email protected]. I have just updated
the versions on
altdorf.one.two.thr:archive/scm/scm4a12.tar.Z and
nexus.yorku.ca:pub/scheme/new/scm4a12.tar.Z
The lesson I just learned is: When developing with
Make on 2 different machines, make sure their clocks
do not differ by more than one minute.
[ ... diffs deleted ... ]
Raise your hand if you remember when file systems had
version numbers.
Don't. The paranoiac weenies in charge of Unix
proselytizing will shoot you dead. They don't like people
who know the truth.
From: BY
Date: Thu, 15 Oct 92 16:51:14 PDT
Subject: [Patch For scm4a12.tar.Z]
Date: Thu, 15 Oct 1992 09:22-0400
From: AW
Date: Wed, 14 Oct 1992 17:21 EDT
From: AB
Date: 12 Oct 92 18:52:48 GMT
From: AJ
Subject: patch for scm4a12.tar.Z
The lesson I just learned is: When developing
with Make on 2 different machines, make sure
their clocks do not differ by more than one
minute.
Raise your hand if you remember when file systems
had version numbers.
Don't. The paranoiac weenies in charge of Unix
proselytizing will shoot you dead. They don't like
people who know the truth.
Heck, I remember when the filesystem was mapped into the
address space! I even re<BANG!>
From: OS
Date: Sat, 17 Oct 92 01:01:50 HKT
Subject: Design Cretins
So, there's this hack in Unix whereby an executable that
begins with #! (the Unix kernel's clever approximation to
file types) is recognised by the exec syscall, and shifted
to an interpreter invocation. The name of the interpreter is
given on the first line, following the #!, and as an added
bonus you can specify an argument to follow the name of the
interpreter. One. One argument exactly. Well, and the
argument can't be too long. Like more than 10 characters.
And, uh, it can't contain spaces or anything, because the
"parser" just scans to the next space or newline. How do I
know the argument can't be longer than 10 characters? By
losing, that's how. And then going and looking at the
kernel sources.
How else would you know?
I guess the same guys that think "The network *is* the
computer" also believe "The source *is* the spec."
Well, OK. Let's grant these bozos this much lossage. It's
still kind of an interesting idea, no? You can transparently
interchange small, interpreted programs with large compiled
binaries.
Ha ha. You wish.
This is Unix, right? So we don't have to make it *really*
work. We'll just sort of fool around, and get it going for
our particular test cases, and hey, we're basically done.
Try the case where the interpreter specified on the #! line
is *itself* implemented by an interpreted script. Now if a
reasonable person were implementing this, it would just
work. Recursion is a concept understood by most 18-year-old
CS majors. Apparently this notion escaped the notice of the
BSD/SunOS guys, because on my Unix, one level is all you
get.
Best yet, when it fails, it just silently does nothing. You don't
get any interesting error msg.
No surprise there, I guess.
People like Bill Joy are the reason evolution is such a slow
process.
From: AG
Date: Fri, 16 Oct 92 17:51:49 -0400
X-Information-For-Weenix-Unies: Sender's Shell Is /bin/csh
Subject: fsck UNIX!
While trying to show a friend a standard UNIX bug involving
shells, I stumbled on yet another bug. Who knows what an
"error in phone numbering" is, and why does the person doing
the finger-ing want to know about it anyway? (These are
rhetorical questions.)
The original bug, anyway, is that a process created by
typing a looping command at csh cannot be suspended and
restarted:
% while (1)
? finger
? sleep 15
? end
finger: error in phone numbering
Login Name TTY Idle When Bldg. Phone
hacker 6.001 hacker s0 Fri 16:50
Here I typed C-z to suspend the process created by the while
command From above.
Stopped
% fg
sleep 15
After a pause lasting a few seconds, a new prompt:
%
Perhaps the authors of UNIX have solved the halting problem;
in their system, ALL programs halt, whether you want them to
or not. Believe it or not, following up on this theory, I
found the following, undocumented system call:
boolean halts (program p)
{
return (true);
}
Apparently, Microsoft isn't the only company guilty of using
undocumented system calls. There can be only one reason
that AT&T would hide the tremendous accomplishment of
solving the halting problem: they're busy patenting the
code.
From: AB
Date: Fri, 16 Oct 92 15:44:38 -0700
Subject: \!*
If I JUST TYPE OUT a certain file in my directory (using the
stupidly named "cat" command), the title of the window
changes to \!*. While this may reflect what I have to say
about unix, I'd rather not have the computer decide what to
say for me. Grrrr.
From: CM
Date: Fri, 16 Oct 92 21:13:12 EDT
Subject: Re: Design Cretins
Date: Sat, 17 Oct 92 01:01:50 HKT
From: OS
Try the case where the interpreter specified on the #!
line is *itself* implemented by an interpreted
script. Now if a reasonable person were implementing
this, it would just work. Recursion is a concept
understood by most 18-year-old CS majors. Apparently
this notion escaped the notice of the BSD/SunOS guys,
because on my Unix, one level is all you get.
You Just Don't Understand. Writing Code To Run Inside
Kernels Is A Hard Problem. (That's why we have
microkernels; so you can have programmers of average ability
writing system software and not necessarily crashing
everything when it breaks.) You can't just allow unbounded
recursion inside the Kernel. You might overflow your Kernel
stack which is of course set at some small wired in constant
in keeping with unix tradition (Simple!). And of course, No
One Would Ever Want To Specify Another Shell Script In The
#! Line.
I have a machine named EXXON-VALDEZ on my desk. This was
from when I nominally worked in fault tolerant computing; I
figured it would be good karma to name the machine after a
huge disaster as a precautionary measure. (I'm quite
superstitious in strange ways.) Now the hardware has been
replaced and I'm about to name the machine something else.
I'm thinking of the name MBUF. I suppose it wouldn't be
such a big change; the machine would still be named after a
huge disaster...
From: DE
Date: Sat, 17 Oct 92 14:58:30 -0400
Subject: Re: \!*
From: AB
Date: Fri, 16 Oct 92 15:44:38 -0700
Subject: \!*
If I JUST TYPE OUT a certain file in my directory
(using the stupidly named "cat" command), the title
of the window changes to \!*. While this may
reflect what I have to say about unix, I'd rather
not have the computer decide what to say for me.
Grrrr.
If I just type out a certain file in my directory (using the
stupidly named "cat" command), my terminal switches baud
rates (or locks the keyboard, or even BEEPS!).
The idea of using in-band "escape" sequences to do
out-of-band control functions is so far from being
Unix-specific that I'm not sure what you're trying to say.
Might the "certain file" contain a shell alias *designed* to
change your window title? If so, sue the author of that
alias.
Anxiously awaiting another Olin-class horror,
From: DE
Date: Sat, 17 Oct 92 15:08:46 -0400
Subject: Re: Design Cretins
Date: Sat, 17 Oct 92 01:01:50 HKT
From: OS
Try the case where the interpreter specified on the
#! line is *itself* implemented by an interpreted
script. Now if a reasonable person were
implementing this, it would just work. Recursion
is a concept understood by most 18-year-old CS
majors. Apparently this notion escaped the notice
of the BSD/SunOS guys, because on my Unix, one
level is all you get.
From: CM
Date: Fri, 16 Oct 92 21:13:12 EDT
Subject: Re: Design Cretins
You Just Don't Understand. Writing Code To Run Inside
Kernels Is A Hard Problem. ... You can't just allow
unbounded recursion inside the Kernel. ...
Am I missing something? Couldn't this have been handled by
a *loop*?
Sorry if I offended any highly-recursive folks,
From: DW
Date: Sat, 17 Oct 92 13:01:30 PDT
Subject: Re: Design Cretins
From: DE
Subject: Re: Design Cretins
Date: Saturday, October 17, 1992 3:08PM
You Just Don't Understand. Writing Code To Run
Inside Kernels Is A Hard Problem. ... You can't
just allow unbounded recursion inside the
Kernel. ...
Am I missing something? Couldn't this have been handled
by a *loop*?
And from another of your recent posts:
The idea of using in-band "escape" sequences to do
out-of-band control functions is so far from being
Unix-specific that I'm not sure what you're trying to
say.
Yes, you are missing something. The whole damn point. Here
we have an obviously losing piece of software that is as ad
hoc as all Hell. It doesn't work and it doesn't scale.
Typical Unix braindeath. That's the forest. You're looking
at trees.
Re the second point about of-band-control. It is stupid and
unwarranted to confuse keystrokes, cursor commands, and
output glyphs into a large smelly stew. ITS got this right,
so did other OS's. The fact that most everyone else farts
in public is NO EXCUSE for Unix to do so. This is software
that doesn't work. WHY THE H*LL SHOULD LISTING A FILE
CHANGE TERMINAL CHARACTERISTICS FOR GOD'S SAKE!?!
You have obviously been brainwashed. You can't tell working
software from broken software. If you don't have some
horror story, or some misdesign to point out, KEEP YOUR
POSTS OFF THIS LIST!! Kapeesh? We don't want to hear your
confused blathering. Go bleat with the rest of the sheep in
New Jersey.
Sincerely,
DW
From: SG
Date: Sat, 17 Oct 92 15:39:13 -0400
Subject: Re: \!*
>From: DE
>Date: Sat, 17 Oct 92 14:58:30 -0400
>Subject: Re: \!*
> Might the "certain file" contain a shell alias *designed*
> to change your window title? If so, sue the author of
> that alias.
THE FUNDAMENTAL PROBLEM WITH THE UNIX MENTALITY --- BLAME
THE AUTHOR OF THE PROGRAM, NOT THE TOOLS WHICH ARE THE CAUSE
OF THE LOSSAGE.
From: AB
Date: Sat, 17 Oct 92 20:45:38 EDT
Subject: Re: \!*
Date: Sat, 17 Oct 92 14:58:30 -0400
From: DE
...
The idea of using in-band "escape" sequences to do
out-of-band control functions is so far from being
Unix-specific that I'm not sure what you're trying to
say....
Suppose every time you wrote a file out to disk you had to
worry that the disk controller would try to interpret some
of the data you were trying to store as commands that might
reposition the disk heads. You might have a file named
something like "/etc/diskcap" that every program that used
the disk would have to read and decode before it could use
the disk safely.
Weenies would tell you it was your own fault when you
destroyed your file system because you accidentally tried to
store some data that contained some disk controller escape
sequences. You might feel that there was an important level
of abstraction missing, but the weenies would
condescendingly explain that ``in-band "escape" sequences''
were a well established idea. When you explained that
twenty years ago there were operating systems that didn't
have this problem, they would reply: ``What problem? I'm
not sure what you're trying to say.''
I understand that our representatives at TLA are now in the
process of re-educating Mr. DE.
By the way folks, the traffic on Unix-Haters seems to be
increasing of late. I'm not threatening to do anything
about it, but you all might want to think twice before just
firing off a quick note to this list. Let's keep the volume
low and the quality high.
From: JL
Date: Mon, 19 Oct 92 18:47:54 EDT
Subject: Sometimes Unix Users Say The Damnest Things
One of the best things about Unix is that you don't even
have to rage at it yourself. The most loyal users do it for
you. Of course, they don't understand that that's what they
are doing. Sometimes, they even think they are pointing out
how MODERN, ADVANCED, and PERFECT Unix is. Other times,
they ask questions, and get answers, that look oh so
reasonable to those whose minds have been subjected to the
repeated electroshock therapy of Unix use.
Case in point is the following colloquy, from a Rutgers
support bboard (names changed for no really good reason):
From:
[email protected] (Innocent Victim)
Subject:Re: `which foo` error message
Date: 18 Oct 92 17:25:29 GMT
Verrrry weird!
If I have no .cshrc, echo `which vacation` works
fine. If I have one consisting of one line:
bind transpose-chars "^T"
Then echo `which vacation` includes a bogus error
message about xinit.
It also appears to go wrong if I use other bind
commands.
I can live without bind commands in my .cshrc, but
this is verrrrry strrrrange!
Which draws the response:
From:
[email protected] (Support Guru)
Subject:Re: `which foo` error message
Date: 19 Oct 92 06:41:24 GMT
I'm able to duplicate your problem. Would you
consider using ntcsh as your shell? It doesn't
have this bug. This is the free version of tcsh,
which seems to have replaced it at most sites. The
current tcsh is rather unportable. It's currently
not being maintained, and I'd rather not try to fix
it. We're going to be trying to move everyone to
ntcsh shortly. (I think we're going to rename it
to tcsh, and do something about converting people's
startup files.) It's fairly compatible with csh
and tcsh, except that the bind command has a
different syntax. The command you would want in
ntcsh is
bindkey '^t' transpose-chars
For the moment, you don't need it. However when we
finally install ntcsh as the default, we're going
to bind ^T to show a status message by default, so
you'll want that command.
"Fairly compatible"?!?!?!
Then there's the following, from the same source, which I
suspect may qualify the author for membership in this august
company - though I'm not sure he's yet made the mental
breakthrough and reached the understanding that his problem
is with something rather larger than a couple of debuggers:
From: SG
Date: 17 Oct 92 21:04:28 GMT
Subject: x11ups, xdbx, and gdb/emacs
I'm giving up on x11ups. The first time I tried it
a long while ago, it consistently died the first
time I wanted to inspect a variable. Of course I
dropped it like a hot potato. Since xdbx's buggy
communications with its inferior dbx have recently
gotten a _lot_ worse, I thought x11ups might be
worth a second look. Fatal internal error unknown
size range (aborting) the first time I trie to
expand a function, exit status 131. In neither
case did I `push' the program very hard. The code
is simple, the data is simple, the request is
simple, boom. Oddly, the one debugger I haven't
tried is the one people who know me would most
expect me to be using, gdb/emacs. Now I'm going to
blow time on gdb as well. Oh, I need this. I
really need this. (Bitching at no-one in
particular.) Maybe I can convince myself that
adding printfs all over the place wasn't so bad.
Regards, [SG]
WHY DO WE HAVE TO PUT UP WITH THIS SHITE !!!!!! Are we
being collectively punished for some bad karma left over
from a previous incarnation as robots? Is it a hint that,
if God had meant us to compute, He would have given us an
operating system? Is Unix just a conspiracy of the
Trilateral Commission to help keep the population under
control?
From: BW
Date: Tue, 20 Oct 92 04:39:49 -0700
Subject: Joe Bob Unix
Date: 19 Oct 92 23:30:05 GMT
Newsgroups: rec.humor.funny
Keywords: chuckle, original, computers
Subject: Joe Bob Goes to the Computing Center
[This one's original; it's a parody]
[Note for non-US readers: Joe Bob Briggs is the nom de plume
of a Texas newspaper columnist who only reviews drive-in
movies. His columns are known for stereotypical "redneck"
style, and he rates movies on a sliding scale of breasts,
blood, and rolling extremities. He's also a big fan of
kung fu (or, as he calls it "chopsocky".......]
_Demon Seed_ Ain't Got Nothing on These Boys
I've never trusted computers; my bank makes too many
mistakes with theirs. Anyway, I found myself in Lexington,
Kentucky awhile back (those dadburned fools turned the
Kentucky Theatre into an indoor pile of bullstuff; it used
to be the only indoor place worth a trip), so I dropped in
on a guy who'd sent me a couple of letters recently.
Well, my knowledge of computers comes from _Demon Seed_, so
I was expectin' eerie red lights and strange things sticking
out from cabinets with lots of beeps and whistles. I wasn't
disappointed with the Engineering Computing Center; they had
blinkin' lights and beeps to spare. They *said* that
nobody'd been impregnated by their computers, but the darn
things just sat there and gave off a self-satisfied hum.
The guys there started telling me about "walking disk
drives" and "zombie processes", and I said to myself "Joe
Bob, these guys are working in a digital Drive-In."
These computers have it down pat. You get to use commands
like "kill" and "chill", and they actually DO SOMETHING! My
pal typed in "kill 29382", and somebody across the room
screamed in pain! This was all right by me, and getting
better all the time. He typed in "chill" and everything
started slowing down, just like old Dr. Freeze in _Batman_
(the original, not the Micheal Keaton bullstuff). They
chant in weird languages (one thing sounded like
"foo-bang-bar-percent-baz-at-uunet", and it did some voodoo
thing), and they have all these books that nobody but them
can read. They've got their heart in the right place, too;
every command gives you a dollar sign back, and that's the
'Merican way!
I started to think that some of these guys were Commies,
though, 'cause they were writing in chickenscratch that HAD
to be a Secret Red Code. I'm talkin' stuff like "int
(*(*(*x)[4])())[4];", and I was sure that the Reds were
gonna send an Eye-Cee-Bee-Em over soon as spit. Well, they
told me that they were really telling the computers what to
do, just like they did in _Logan's Run_. That put my mind
at ease, let me tell you. Then one of 'em started saying
"there is another system", and I thought I was smack dab in
the middle of _Colossus: The Forbin Project_; turned out it
was their idea of a joke.
Then they started talking about 'retiring' a computer; I was
about to ask what kinda pension a chunk of metal got. They
took some big thing called a 'degausser' and started waving
it over everything. Well, they told me that it could erase
any tapes or magnetic stuff, and I decided that I'm gonna
get one and head over to the Commie Video people and wipe
'em out.
Well, anyway, I was mucho impressed with the boys at UK, and
I've got some ideas for new movies; I'm gonna call Tobe with
these.
Four quarts blood (the students tryin' to use these things).
One half breast (they printed it out on the line printer
thingy). Three zombies, one of which *refuses to die*.
Gratuitous JCL. Gratuitous 3B2. Punch card fu. Diskette
fu. Degausser fu. Drive-In Academy Award nomination for
the user who said "the computer ate my program, and it won't
give it back!".
Three stars. Joe Bob says check it out.
--
From: MP
Date: Tue, 20 Oct 92 12:52:50 EDT
Subject: What's The Right OS For A Packet Switch?
... why Unix, of course. Packet switches for the major
backbone network of the United States don't need to be
reliable, they don't need to be flexible, they need to be
Unix... Herewith the proof, an excerpts from a recent
trouble ticket ...
[Original report:] On the ENSS rcp_routed has crashed:
Oct 20 00:58:55 enss134 syslog: rcp_routed must be restarted
Oct 20 00:58:55 enss134 syslog: rcp_routed must be restarted
Of course having detected that a vital system daemon needs
restarting, our good little Unix just lets you know rather
than doing it... And why did it need restarting?
[The entire T3 NSFnet backbone went unusable for an
hour] Merit believes the problem tonight was related to
ESNET trying to come up on the T3 backbone-- they
reached a threshold.
Right. A fixed length array overflowed and the packet
switch crashed. I guess I didn't really want reliable
networking...
From: JL
Date: Wed, 21 Oct 92 07:30:26 EDT
Subject: Nice Comparison
I know most people on this list are more LISP-M oriented
than VMS oriented, but even so I thought you'd like the
following paragraph, extracted from a long article:
Five years ago there was a good reason to get out of
VAX and into UNIX, if you needed price performance then
UNIX was better. Now this is no longer the case but
there are a lot of people who have drawn their battle
lines and got into the fortifications and are fighting
the old battle. Now the urgent need is to get rid of
UNIX, the operating system that succeeded only because
Kellogs gave it away free with packets of cornflakes.
It's due to "PH", whose address I can't give you because the
message reached me via the UUCP "network" - one does "use
the word lightly" so often when talking about Unix - with
the following "return path":
From: pasteur!agate!usenet.ins.cwru.edu
!magnus.acs.ohio-state.edu!zaphod.mps.ohio-state.edu
!darwin.sura.net!paladin.american.edu!news.univie.ac.at
[email protected]
though one can at least tell where he is from:
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei
HERA
Message-Id: <
[email protected]>
From: CL
Date: Wed, 21 Oct 92 11:12:33 -0400
Subject: Re: Nice Comparison
Well with the USL vs. UCB lawsuit, I think AT&T has finally
realized what a ghastly mistake it was foisting UNIX upon
the world, and they are finally seeking to kill it. I wish
them luck.
From: AG
Date: Sat, 24 Oct 92 15:02:59 -0400
Subject: The Wonders Of X
Here is clear evidence that X is the Unix of window
"systems." From the manual page for xset (a Unix program
for controlling X server options):
OPTIONS
...
bc The bc option controls bug compatibility mode
in the server, if possible; a preceding
dash(-) disables the mode, otherwise the mode
is enabled. Various pre-R4 clients pass
illegal values in some protocol requests, and
pre-R4 servers did not correctly generate
errors in these cases. Such clients, when run
against an R4 server, will terminate
abnormally or otherwise fail to operate
correctly. Bug compatibility mode explicitly
reintroduces certain bugs into the X server,
so that many such clients can still be run.
This mode should be used with care; new
application development should be done with
this mode disabled. The server must support
the MIT- SUNDRY-NONSTANDARD protocol extension
in order for this option to work.
"Such clients... terminate abnormally or otherwise fail to
operate correctly" is an understatement. In fact, in
earlier versions of one X server, it was possible to crash
the X server (and all its clients) simply by setting the
bell volume to zero -- using xset itself!
From: RM
Date: Mon, 26 Oct 1992 16:27:55 PST
Subject: Serious Network Programming
The other night a distinguished and celebrated Doctor of
Computer Science told me he'd be hacking network software
``in C, because nobody takes you seriously if you use
anything else.''
Isn't C the language -you'd- pick for hacking network
protocols and implementations? The "systems programming"
language with no way of expressing "vector of bits",
complete with the "implementation-independent" inability to
state something as fundamental as "32 bits, unsigned", the
"portable" inability to state "little-endian" and "defacto
standard" mess of the "volatile" declaration?
I know, how about a preprocessor (written in YACC, of
course) which takes C code with embedded "comments" which
look like
/*(define-octet-structure (gif-screen-descriptor :access-type :unsigned-8)
(width integer-16)
(height integer-16)
(* (* cardinal-8
(pixel-size-1 (load-byte 0 3))
(color-resolution-1 (load-byte 4 3))
(color-map-p (boolean-bit 7))))
(background-pixel cardinal-8)
(* (padding cardinal-8 1)))
*/
and spits out code for the real, winning C preprocessor to
have its way with? If only I could do something about the
confusing, parenthesis-afflicted syntax, perhaps I'd have a
shot at a paper at USENIX in, say, 1998.
From: JZ
Date: Tue, 27 Oct 92 16:06:07 PST
X-Windows: A moment of convenience, a lifetime of regret.
Subject: Fun With Ptys
So there I was, just trying to visit a file, which happened
to be on a different machine. Find-file waits a while, and
then tells me "connection refused." I have a hard time
believing this, and "M-! ping" tells me that yes indeedy,
that machine is alive. I switch to my shell buffer and run
ftp, and it connects fine. So why is emacs hosed? Well,
after a while, I tried to create a second shell buffer, and
it responded with
<jz@cardinal:~/>
Use "exit" to leave csh.
<jz@cardinal:~/>
Use "exit" to leave csh.
<jz@cardinal:~/>
Use "exit" to leave csh.
(and so on, some
round-number-in-base-two-because-of-rampant-weenieism
times)
Process shell finished.
You know what that is, right? It means that I've disabled
the TOTALLY LOSING feature that typing ^D at a shell makes
it blow you out of the water. But apparently the shell
can't be bothered to make a distinction between the
character ^D and a real honest-to-god EOF on its input
stream. So it decides that if it gets N ^D's in a row,
really what's happening is that its input stream is closed,
and it should blow you out of the water anyway.
And, of course, those TOTALLY LOSING monstrosities known as
ptys often get hosed in just such a way. So one of my ptys
is hosed. The one it keeps trying to allocate next, over
and over. The one that gets added back to the list of
available ptys after a brief but violent tryst with my
shell, or my inferior ftp process, or whatever.
Well, the only real fix I knew of for this was to reboot,
but I had a lot of state that I didn't want to lose just
because everyone's favorite excuse for an operating system
had developed a hacking cough. So to figure out which pty
was hosed, I added the line "tty" to the front of my .cshrc,
and started a shell again. Then, after glancing at the
/dev/ directory, I guessed that chmodding all permissions
away from that pty would make it look allocated. So I held
my nose and tried it, and what do you know, it worked.
After all, everything is a file. If you can't express a
concept in the file system idiom, it must not be worth
thinking about.
So blah blah blah, life goes on, and later I decided to
visit a file which happens to be both compressed, and a tar
file. It uncompressed fine, but then tar-mode couldn't
parse it. I stared at the raw tar file for a while, and it
really did look like a mess: pieces of the files were
misordered, there were random stretches of nulls in the
middle of the text. So I was going to tell the person who
had sent me the file that they had botched it before
compressing it, but even though I've occasionally seen NFS
do this, it did seem kind of unlikely, so I tried using the
real uncompress and tar programs just to make sure.
Well guess what. It worked fine. It seems the output of
that "tty" line in my .cshrc file was being prepended to the
tar data, because the only real way to run a program is to
start a shell and have it run it for you, and because the
tar format has no magic number or any other way of telling a
valid tar file from a recipe for chocolate chip cookies, it
was only giving up the ghost when it reached the very end.
So why was it that the raw tar data looked like such a mess,
instead of simply looking like it was shifted by the length
of the string "not a tty"? Because part of the de-facto
specification for what tar files look like is that they are
padded to a multiple of twenty "blocks", meaning 10240
bytes. Isn't that special. And what are they padded with?
That's right. Random data that, in this case, looked
deceptively like what the non-random parts of the file
looked like.
Happy happy, joy joy.
Even if you never leave emacs, you just can't win.
From: DM
Date: Wed, 28 Oct 92 10:54:34 EDT
Subject: Re: Fun With Ptys
> Date: Tue, 27 Oct 92 16:06:07 PST
> From: JZ
>
> Isn't that special. And what are they padded with?
> That's right. Random data that, in this case, looked
> deceptively like what the non-random parts of the file
> looked like.
Check it out -- that seemingly meaningless padding is
actually where George Bush's plans for selling bombs to
Saddam Hussein are kept.
Date: Wed, 28 Oct 1992 14:31:36 PST
From: LK
Subject: Re: Fun With Ptys
> (and so on, some
> round-number-in-base-two-because-of-rampant-weenieism
> times)
Ah, you were not on this list in its founding days:
if (++sincereal > 25) goto oops;
From: JZ
Date: Mon, 2 Nov 92 18:37:13 PST
X-Windows: A Terminal Disease.
Subject: #'truename? What's That?
% touch foo
% ln foo bar
% realpath foo
/tmp/foo
% realpath bar
/tmp/bar
I'm sure any other behavior would be considered a BUG.
From: PB
Date: Tue, 3 Nov 92 19:30:42 EST
Subject: Re: #'truename? what's that?
Names and paths are the thinnest layer of filth that allows
you to get files open... "hard" links create two "names" for
one file... Files don't REALLY have names at all, they have
numbers! I'm sure it all seemed clever at the time....
Suns don't have a realpath command, but the realpath library
routine looks like it's only use is to find the final path
of a file hidden behind a maze of twisty "symbolic" links,
Berzerkley's sad excuse for ITS translations. They're even
a sad excuse for DEC logical names!
From: NE
Date: Tue, 3 Nov 92 21:11 EST
Subject: Oh Yessir! I *Really* Wanna Read Those 800 Pages! Please, Sir!
I'm trying to read the documentation for the PHIGS
Extensions to X (otherwise known as PEX), a 3-d graphics
library for X. Someone in the X Consortium very kindly
pointed out that this thing (a) exists and (b) that the doc
could be had somewhere on export.
So there's about four things in the contrib
directory calling themselves PEX, none of which are the
right thing. Similarly, in the R5untarred directory (god
forbid you should forget to capitalize that R!), there are
four separate trees of likely-looking things. Finally,
after 30 minutes of wandering around I stumble more or less
by accident onto the correct thing. Thank god for ange FTP,
doing this in regular FTP (outside emacs) would have taken
four times as long.
Surprise! the .ps files mentioned in the README(s)
are gone, guess I'll have to run troff. Oh good, there's an
Imake file, this'll be *easy* ...
Well, the Makefile it generates (god forbid you
should forget to capitalize that M!) sort of expects to see
the whole directory structure 'cause it uses some macros
from other parts of the tree. You know how FTP has this
wonderful option to recursively mget subdirectories?
You mean it doesn't have that option? There's no
way to copy an entire tree? Well, hmm, let's see about
running 'rftp', an expect script that gives you (among other
things) this functionality. I snarf a copy of rftp from my
machine, stick it my bin dir (on my path), rehash, and:
> % rftp export
> rftp: Command not found.
Hmmm. After some futzing it turns out that #! scrod
me again, what it means is that *expect* doesn't exist on
this machine. I back out to another machine that has it,
snarf the tree, and do
> ghoti% xmkmf
> imake -DUseInstalled -I/usr/lib/X11/config
> ghoti% make
> Make: Makefile: Must be a separator on line 216. Stop.
So much for imake. Oh wait! There's a PHIGS
subdirectory, with another Makefile. And it actually *does*
something!
> ghoti% make
> Warning: NAMES changed after being used
> psroff -rj$FORTRAN -ms cover.phigs > draft/cover.PS 2>/dev/null
> *** Exit 2
Fortran? Exit 2? What's this? Oh, there's this
corefile here - looks like a psdit corpse ...
Oh wait. The machine that had expect is running R4!
Hah! I quickly rcp -r it to an R5 machine, and imake does
me right this time. Why is it invoking cc? Oh, I see. It
needs these 11 C programs in order to properly print the
documentation ...
Sigh. Now it's complaining that there's no program
named 'pic'. I guess that wasn't one of the 11 they thought
they needed. So I remove the reference to pic (so what if
the figures are screwed up? It's only a graphics library),
xmkmf again, and make. Now it's missing some stupid slush
file it probably forgot to create. I'm touched. No
'ditroff' either, let's link 'psroff' instead. A little
more twiddling and aha! It's off and running a psroff ...
Half an hour later and I'm suspicious. I run a ps:
No more processes. I run another. Everything looks fine,
maybe 40 processes in the Q. I run a third: hordes of 'sh
ditroff's. A fourth: No more processes. Ps is *so* useful.
I Give Up. Rm -r *.
No wonder people think computers are hard. I've
just wasted bloody *hours* trying to print the freaking
documentation. They need better documentation on how to
generate the documentation. Did I forget to mention that
it's supposed to be 800+ pages?
We now return you to our regularly scheduled
professionalism.
From: CM
Date: Wed, 4 Nov 92 14:16:14 EST
Subject: Re: Oh Yessir! I *Really* Wanna Read Those 800 Pages! Please, Sir!
You know, the unix weenies have come up with just the tool
for you! It's an expert system for printing files in unix.
It's written up in the AAAI-88 conference proceedings. The
title is something like "How to Print a File."
From: HM
Date: Wed, 4 Nov 92 23:57:02 EST
Subject: And This Is Certainly Reasonable Behavior.
hm@gloria>lpr -Plw7 punidraw.ps
/: write failed, file system is full
lpr: punidraw.ps: temp file write error
OK. So I can't print my file. Oh well. I'll look at the man
page. Hmmm, I must have wanted the "-s" option to
lpr. OK. I'll just queue the job again. But oh, hey wait,
the printer is actually doing something already. And wow
it's printing my document. Oh, actually make that the first
three quarters of my document.
Gee, let's look a little closer at that man page:
NAME
lpr - send a job to the printer
SYNOPSIS
lpr [ -Pprinter ] [ -#copies ] [ -Cclass ] [ -Jjob ]
[ -Ttitle ] [ -i [ indent ] ] [ -1234font ] [ -wcols ]
[ -r ] [ -m ] [ -h ] [ -s ] [ -filter-option ]
[ filename ... ]
DESCRIPTION
lpr creates a printer job in a spooling area for subsequent
...
...
DIAGNOSTICS
lpr: copy file is too large
A file is determined to be too "large" to print by
copying into the spool area. lpr TRUNCATES THE FILE,
AND PRINTS AS MUCH OF IT AS IT CAN. The maximum file
length is specified by the mx capability of the
printcap(5) entry for the printer. If no mx capability
is specified, the default limit is 1000 Kbytes. Use
the -s option as defined above to make a symbolic link
to the file instead of copying it.
Gee, that's useful. Now if I can just find the flag to lpr
to let me just print the last quarter of my document.... Oh
heck, I'll just print the whole thing again. Too damn many
trees on this continent already.
From: BY
Date: Thu, 5 Nov 92 10:55:07 PST
Subject: Re: And This Is Certainly Reasonable Behavior.
From: HM
Date: Wed, 4 Nov 92 23:57:02 EST
hm@gloria>lpr -Plw7 punidraw.ps
/: write failed, file system is full
lpr: punidraw.ps: temp file write error
Gee, that's useful. Now if I can just find the flag to
lpr to let me just print the last quarter of my
document.... Oh heck, I'll just print the whole thing
again. Too damn many trees on this continent already.
I remember the first time I wanted to print a subset of a
document. I read the lpr man page looking for options to
specify start and end pages. When I didn't find them, I
looked harder, chasing references, looking in the manuals,
etc. It didn't occur to me that there just wouldn't be a
way to get what I want. This was in my inferiority complex
phase of Unix use, in which my assumption was that if I
couldn't figure out how to do something or couldn't find
what I wanted, then I must not be looking hard enough or
must just be too stupid.
I am reminded of the Charles Addams cartoon depicting a
college reunion. Underneath the "Welcome Class of '54"
banner sit the alums, all of whom are bums and winos. One
bum turns to another and says "I used to think it was just
me, but maybe it's the damned school!"
From: AW
Date: Fri, 6 Nov 1992 09:58-0500
Subject: Re: And This Is Certainly Reasonable Behavior.
Date: Thu, 5 Nov 1992 13:55 EST
From: BY
From: HM
Date: Wed, 4 Nov 92 23:57:02 EST
hm@gloria>lpr -Plw7 punidraw.ps
/: write failed, file system is full
lpr: punidraw.ps: temp file write error
Gee, that's useful. Now if I can just find the flag
to lpr to let me just print the last quarter of my
document.... Oh heck, I'll just print the whole
thing again. Too damn many trees on this continent
already.
I remember the first time I wanted to print a subset of
a document. I read the lpr man page looking for
options to specify start and end pages. When I didn't
find them, I looked harder, chasing references, looking
in the manuals, etc. It didn't occur to me that there
just wouldn't be a way to get what I want. This was in
my inferiority complex phase of Unix use, in which my
assumption was that if I couldn't figure out how to do
something or couldn't find what I wanted, then I must
not be looking hard enough or must just be too stupid.
I suspect that the True Un*x Way to do this is to print, not
to the printer, but down an Intestine (this is what I call
p*pes) that leads to some parser "utility" that is just
barely general enough to scan for the page headings and
suppress pages that don't have the right page-numbers at the
top. The result is intestined directly to the stool file --
uh, that's "spoop file" -- DAMMIT! "SPOOL file" -- whose
name you have to know and is different on every machine. Of
course if you don't do it right (and you won't) a couple of
blank lines will sneak in, and your page headings will come
out about five lines down, preceded by text from the south
end of the preceding page. Your true weenie won't even try
again, he'll be so pleased at having made this cludge almost
work.
I need hardly say that I do not want to see a gleeful
posting explaining how to do this in gory detail. I remind
all listening weenies that I have a Symbolics machine. I
can network to your Ux*x, and when it asks me whether my
local machine has authorized my UID and GID before it lets
me delete your directory, I can simply, and truthfully, say
"yes". And it will believe me.
I am reminded of the Charles Addams cartoon depicting a
college reunion. Underneath the "Welcome Class of '54"
banner sit the alums, all of whom are bums and winos.
One bum turns to another and says "I used to think it
was just me, but maybe it's the damned school!"
From: AB
Date: Sat, 7 Nov 92 08:02:49 PST
Subject: Re: And This Is Certainly Reasonable Behavior.
If you're going to print on unix, you use pr, nroff or
troff. Weenies may use TeX. I'm sure that TeX must have a
"print only pages N through M" command. Pr has a "start
printing at page N" command. N/Trof allow you to list a set
of pages to print.
Bitch bitch bitch. Whine whine whine.
From: OS
Date: Sat, 7 Nov 92 16:10:06 EST
Subject: Oh, I Don't Know, Just Reboot And It Should Work
The following message (whose identifying marks I have, for
the most part, excised) illustrates how resistant UNIX is to
traditional (i.e., "bigger hammer") repair techniques:
[The problem was that when I sent mail to an address of
long-standing validity at the offending machine, it got
returned back saying "user not found". I later learned
that it's been doing this, sporadically, for months.]
From:
[email protected] (Name Withheld)
To:
[email protected]
Subject: sendmail problem on xxxxxxxxx
Date: Mon, 02 Nov 92 07:50:54 EST
I fixed it when I came in yesterday afternoon (Sunday).
For whatever reason, sendmail is unable to recognize
valid user ids after a reboot. Killing and restarting
the daemon fixes the problem. SysGuy and I are
investigating, but so far haven't been able to figure
out what's wrong.
Clearly, the "off" switch remains an even more effective cure for UNIX
than simply rebooting.
From: GB
Date: Sat, 7 Nov 92 17:08:48 -0500
Subject: Re: And This Is Certainly Reasonable Behavior.
I came across this of vapid unix apologia in my mailbox, and
figured it was a prime example of unixoid mentality that
should be passed on to unix-haters. Then I saw that it had
already been sent to unix-haters.
Date: Sat, 7 Nov 92 08:02:49 PST
From: AB
Subject: Re: And This Is Certainly Reasonable Behavior.
If you're going to print on unix, you use pr, nroff or
troff. Weenies may use TeX. I'm sure that TeX must
have a "print only pages N through M" command. Pr has
a "start printing at page N" command. N/Trof allow you
to list a set of pages to print.
Bitch bitch bitch. Whine whine whine.
From: HM
Date: Sat, 7 Nov 92 19:57:26 EST
Subject: And This Is Certainly Reasonable Behavior.
Upon receiving this little gem, my first reaction was to
dash off a short note congratulating the author on their
keen sense of humor, and their incisive skill in
constructing a convincing parody of the typical reasoning of
your garden variety imbecile unix-weenie. I was impressed by
the author's ability to combine, in such a short amount of
space, the trademark combination of knee-jerk 'blame the
victim' mentality, condescending smugness, with the
hilarious 'solution to the wrong problem' ploy.
From: AB
Date: Sat, 7 Nov 92 08:02:49 PST
If you're going to print on unix, you use pr, nroff or
troff. Weenies may use TeX. I'm sure that TeX must
have a "print only pages N through M" command. Pr has a
"start printing at page N" command. N/Trof allow you to
list a set of pages to print.
Bitch bitch bitch. Whine whine whine.
However, in the remote possibility that this note was
written in earnest, I thought I would offer the following
life-furthering quote which I was given recently. It seems
to have been written specifically for the sad followers of
the Unix way...
our thoughts and desires and our relations to one another
never fit, completely or definitively, within the
structures we impose upon belief and action. sometimes we
conduct ourselves as exiles from a world whose
arrangements exclude no true insight and no worthwhile
satisfaction. but more often we treat the plain,
lusterless world in which we actually find ourselves, this
world in which the limits of circumstance always remain
preposterously disproportionate to the unlimited reach of
striving, as if *its* structures of belief and action were
here for keeps, as if *it* were the lost paradise where we
could think all the thoughts and satisfy all the desires
worth having. when we think and act in this way, we
commit the sin the prophets call idolatry. as a basis for
self-understanding, it is worse than a sin. it is a
mistake.
roberto mangabeira unger
*social theory: its situation and its task* 1987.
From: SG
Date: Mon, 9 Nov 92 07:18:05 -0500
Subject: Re: And This Is Certainly Reasonable Behavior.
Clearly, UNIX has a dozen different commands with two dozen
different syntaxes necessary for accomplishing your goal.
Let's keep this kind of drivel off UNIX-HATERS.
Begin forwarded message:
Date: Sat, 7 Nov 92 08:02:49 PST
From: AB
Subject: Re: And This Is Certainly Reasonable Behavior.
If you're going to print on unix, you use pr, nroff or
troff. Weenies may use TeX. I'm sure that TeX must have a
"print only pages N through M" command. Pr has a "start
printing at page N" command. N/Trof allow you to list a set
of pages to print.
Bitch bitch bitch. Whine whine whine.
From: SS
Date: Mon, 9 Nov 1992 15:45:59 -0500
Subject: What The DEBUG Flag Is For
Oh, I get it. C programmers use DEBUG to add more bugs to a
program.
>Date: Mon, 9 Nov 1992 12:00:02 -0600
>Reply-To: Eudora mailing list <
[email protected]>
>Sender: Eudora mailing list <
[email protected]>
>From: SD
>Subject: Old News: Popper 1.7 Bug
>To: Multiple recipients of list EUDORA <
[email protected]>
>
>This is old news, but I've had several reports recently,
>so I'm going to warn everyone again:
>
>If you are using the POP3 server "popper", version 1.7, BE
>SURE you did NOT compile it with the DEBUG flag turned on.
>If the DEBUG flag is turned on, popper 1.7 WILL lose all
>your mail if a connection goes down during a session.
>
> You can fix the problem by recompiling popper 1.7 without
> the DEBUG flag, or by getting popper 1.831 from
> ftp.cc.berkeley.edu, pub/popper subdirectory.
>--
>
>
From: LF
Date: Wed, 11 Nov 92 03:05:13 -0500
Subject: Spot The Hidden Flaw...
I was all set to ask somebody here why I was losing so badly
trying to do something simple (besides the obvious
explanation that springs to mind, of course). After all,
one of the Secret Ninja Winning Feechurs about UNIX is that
you can stick parts of the filesystem together with links,
just like the adhesions in endometriosis, right?
Clearly, everyone who reads this will see instantly what I
was doing wrong, so here's what I was about to send:
This works:
[marble] /u/fubar/Dirs> ln -s /net/mc/u/fubar mch
[marble] /u/fubar/Dirs> la
total 5
drwxr-xr-x 2 fubar 512 Nov 11 02:10 ./
drwx--x--x 24 fubar 2560 Nov 11 02:06 ../
lrwxr-xr-x 1 fubar 15 Nov 11 02:10 mch@ -> /net/mc/u/fubar
.. but this doesn't (and gives weird diagnostics):
cd /mas/el/microhome/microworld/MediaMOO
[marble] /u/fubar/Dirs> ls -n /mas/el/microhome/microworld/MediaMOO moo
moo: No such file or directory
/mas/el/microhome/microworld/MediaMOO:
code/
[marble] /u/fubar/Dirs> la
total 7
drwxr-xr-x 2 fubar 512 Nov 11 02:11 ./
drwx--x--x 24 fubar 2560 Nov 11 02:06 ../
lrwxr-xr-x 1 fubar 15 Nov 11 02:10 mch@ -> /net/mc/u/fubar
.. and this was the same thing again, which gave me
different output and still didn't work:
[marble] /u/fubar/Dirs> ls -s /mas/el/microhome/microworld/MediaMOO moo
moo: No such file or directory
/mas/el/microhome/microworld/MediaMOO:
total 1
1 code/
... and this is a try a different way, and still didn't work:
[marble] /u/fubar/Dirs> ls -s /mas/disks/microworld/microworld-home/MediaMOO moo
/mas/disks/microworld/microworld-home/MediaMOO: No such file or directory
moo: No such file or directory
[marble] /u/fubar/Dirs>
... even though a `df' from the relevant directory seems to show that one
or the other of the above _should_ have worked:
[marble] /mas/el/microhome/microworld/MediaMOO> df .
Filesystem Total kbytes kbytes %
node kbytes used free used Mounted on
microworld:/ 592502 445810 87441 84% /tmp_mnt/mas/disks/microworld/microworld-home
So what's going on here?
That's right, I was all set to blame NFS and all sorts of
things like that, when I suddenly spotted that -n up there.
"Uh oh," I thought, "I wonder what -n means when you're
making a link?" I figured maybe the unrecognized option was
simply ignored without a warning; hey, isn't that the UNIX
way?
Then finally, moments before sending the mail, I suddenly
realized that I wasn't typing `ln' at all, but `ls' instead.
Yes, I had misattributed the blame for my lossage. It
wasn't the magic of "distributed" filesystems at all, but
instead the shortage of vowels. LIST and LINK don't differ
by too much when you throw away all the vowels and a
consonant apiece, and of course `ls' takes more options than
you can shake a stick at (quick! which ones _doesn't_ it
take? In which "compatible" version of UNIX?), so of course
even the totally screwy call to it didn't reveal a
problem...
The astute among us will realize that what I was _really_
trying to do was to compensate for the lack of a logical
name system by applying pliers to my local copy of the
distributed filesystem, so I could navigate around in this
MUD-like mess without spending the vast majority of my
working day typing pathnames instead of thinking about my
research.
I've since added Yet Another Stupid Alias to my ever-growing
behemoth of aliases that tries to compensate for the lack of
interactive prompting, sanely-named commands, and reasonable
defaults (right, "alias link 'ln -s \!*'", complete with a
comment reminding me that "link fn1 fn2" will actually
create the link fn2@ -> fn1, backwards just like PIP from
DOS/BATCH, RT11, and OS/8 days, what fun, though of course I
can't actually _see_ the comment while I'm typing the
command, oh no, I've gotta go back to the dotfile I defined
the damned alias in to see the comment which tells me how to
use it, so maybe I want a version that insists on two args
and swaps them so it makes sense again), but it's all
hopeless. All I can say is that the internationalized
version of UNIX in Hebrew won't have to worry about the
vowels, either...
Date: Wed, 11 Nov 92 10:01:21 EST
From: DM
Subject: Re: Spot The Hidden Flaw...
list_otals forever!
(non-Multicians press d now)
From: CM
Date: Thu, 12 Nov 92 09:42:03 EST
Subject: No Shite, Sherlock
I can just picture this guy's furrowed brow and look of
surprise and consternation as he discovers the forbidden
knowledge that, yes, the man pages are incomplete.
From: DH
Date: Tue, 10 Nov 92 16:26:31 -0800
Subject: Re: (Was Persistent Resources; Risks Of Thinking Hypertext Complete)
In RISKS-14.03 I saw mention of an earlier post in which I
described my discovery that BSD shared memory segments
persist; people who know better will be reassured to find
out that I have since understood 1) that this persistence
can be a feature, not a bug and 2) the SysV libraries allow
one to use mmap() calls to implement shared memory, without
the 100 segments of 1MB each limitation (*).
But I discovered along the way two interesting things:
first, you can't trust the man pages' SEE ALSO section to
give you complete cross-referencing on all related topics,
especially between the BSD and SysV camps. Second, the Net
and Local Smart People (who turned me on to the mmap()
calls) are really great resources.
(*) It was pointed out to me that the BSD segments can be
made contiguous, which is helpful; but I also might
conceivably need more than that (yes, seriously.)
From: ME
Date: Thu, 12 Nov 92 12:59:43 EST
Subject: It Was The Fortune Program That Sold Them
>From the New York Times, 11/11/92, page D5:
CHINA CHOOSES UNIX AS SOFTWARE STANDARD
(AP) Unix System Laboratories Inc., a software company
controlled by AT&T, said yesterday that it had reached an
agreement under which China would adopt the company's
technology.
. .
Under the agreement, the version of the Unix operating
system software promoted by Unix Systems will be adopted as
the standard in China for "open systems" computing. Open
systems are computers that are not dependent on any one
company's technology. Unix systems is promoting a version
of Unix that all computer makers and software writers can
use.
Unix software will the standard for government, banking,
transportation, communications, and other areas in China,
the company said.
. .
--
From: CM
Date: Sat, 14 Nov 92 02:39:41 EST
Subject: [Re: Eliminate TCP Input Demuxing]
It's really amazing. The paper referred to in this message
concludes that O(n) search is bad for demultiplexing tcp
connections. What a surprise! If berkeley tcp wasn't so
widely used and at the same time so gd braindead, a paper
like this would never have been considered for publication.
Date: Fri, 13 Nov 1992 16:07:28 -0800
From: BB
Subject: Re: Eliminate TCP Input Demuxing
> From: SW
> Date: Thu, 03 Sep 92 08:08:39 -0600
> Subject: Re: Eliminate TCP Input Demuxing
>
>
>
> |One paper that was recently published in measuring the PCB
> |lookup overhead was:
> |
> | 1992 ACM SIGCOMM Conference Proceedings
> | August 17-20, 1992, Baltimore, Maryland
> |
> | Efficient Demultiplexing of Incoming TCP Packets
> | Paul McKenney and Ken Dove
> | Sequent Computer Systems
> |
> | The paper covers a number of different algorithms and
> | presents some analytical approximations to describe the
> | behavior of various TCP demultiplexing algorithms when
> | presented with packet traffic resulting from running the
> | TPC/A benchmarks.
I'm just getting around to responding to this, with an
historical note which I cannot resist. Paul's paper is a
good, thorough, and competently done analysis, but the
conclusion takes me back about 14 years. Are we always
destined to reinvent the same stuff every N years?
I wrote one of the 6 original experimental TCP's
commissioned by DARPA, starting about 1978, and my
implementation used exactly the (standard) chained hashing
algorithm that Paul concludes is best. It seemed to me
then, and still seems, even without elaborate analysis, that
using such an algorithm is simply good software engineering.
I would expect any graduate with a CS degree (and I mean
*undergraduate*) to do the same. Doing a linear search for
demultiplexing is clearly wrong.
BTW, my TCP was implemented in IBM BAL for the IBM MVT/MVS
operating systems. What an incredible luxury a good C
compiler would have been!
From: TK
Date: Sun, 15 Nov 1992 17:55-0500
Subject: Re: [Re: Eliminate TCP Input Demuxing]
I'm just getting around to responding to this, with an
historical note which I cannot resist. Paul's paper is
a good, thorough, and competently done analysis, but
the conclusion takes me back about 14 years. Are we
always destined to reinvent the same stuff every N
years?
There is a well known effect in the computer architecture
community, which in summary states that all major
architectural mistakes must be and have been made at least
three times: once in the design of mainframes, once in the
design of minicomputers, and once in the design of
microcomputers. Perhaps a similar rule applies to operating
systems.
The same mistakes are made once in mainframe OS's, twice in
microcomputer OS's, and N times in Unix (tm) operating
systems. What seems surprising and different is that they
don't get fixed in Unix. Mostly people don't even realize
they ARE mistakes.
From: PW
Date: Mon, 23 Nov 1992 11:19-0500
Subject: Clever Signature Lines We Wish We Didn't Get
[From recent mail]
Sincerley,
XXXXXXXXXXXXX
% cat murphy.law
Murphy's law: "Whatever can go wrong, w
Segmentation fault: core dumped.
From: AD
Date: Wed, 25 Nov 92 15:13:00 EST
Subject: The True Nature Of Unix
I had to check the headers twice to make sure the
following message wasn't really destined for this list.
Obviously, it should be, so here it is (along with part of a
reply). ...and to think we are training our current crop of
TLA students to live with and accept this drivel. Perhaps
it's time for that Just Say NO campaign....
------- Forwarded Message
From:
[email protected]
Date: Wed, 25 Nov 92 10:12:12 -0500
To:
[email protected]
Subject: hardware questions
> 2. Not getting another RS/6000 is annoying but survivable
> as we do have sneezy. Were the problems associated with
> using it as a login/build server (screwed up ptys or
> whatever) resolved?
Sneezy is no longer useable as a build engine, and hasn't
been for a long time. Right now it requires that one start
3 concurrent telnet's to `eat' enough dead pty's to try to
get a real one with rlogin, and this only works if you stand
on one foot and chant `I know it's a 520 in a server
configuration with no head and a huge case, but it's *still*
a client machine' six times; three forward and three
backward. I can not count on sneezy as a build engine;
right now, if I have to build something, I end up punting
the rs6k until I can find one somewhere else; (personally, I
usually use one of the two client rs6k's that consulting has
available). I'm not sure what other people do, but I
haven't seen too many people standing on one foot and
chanting in the XXXX office in a while...
As for `fixing' the problem, when I last cornered
Lusing-IS-type about it, he said that no one, including
himself and IBM, knew what the problem was, but there wasn't
a prayer of getting it fixed for AIX3.1.6, since IBM has had
newer versions of the OS out for so long. Admittedly, this
was probably a couple months ago.
-X
<and a part of a reply>
From:
[email protected]
Date: Wed, 25 Nov 92 10:12:12 -0500
Sneezy is no longer useable as a build engine, and
hasn't been for a long time.
I have not found that to be the case. It is useable, just a
pain in the ass.
When I need to do a build, I log into sneezy by opening 10
telnet connections to it in the background, and then
connecting to it with rlogin. This hasn't failed for me
yet.
Yes, it sucks rocks to have to do this, but it is an
exaggeration to say that the machine is "no longer useable
as a build engine."
xxx
------- End Forwarded Message
From: SS
Date: Sat, 28 Nov 1992 19:12:27 -0500
Subject: Those Zany Aussies
Hmm, they're looking for mistakes, disasters, and sick
twisted jokes... I think the tar man page should do the
trick.
---
Date: Fri, 27 Nov 1992 11:53:46 +1100
From: AD
Subject: Humorous Submissions
CALL FOR SUBMISSIONS FOR A NEW BOOK Tentatively titled:
"Humour the Computer:
Humorous Writings concerning Computing"
We seek contributions of a humorous nature for a new book
called `Humour the Computer', an anthology of the comic,
amusing and laughable aspects of Computing. It is scheduled
to be published by TLA Press early in 1994.
Topics of interest include:
* computing experiences: e.g. `a day in the life',
computing jobs - industry, commerce, teaching, research, etc;
getting funded in the 90's, getting a job in the 90's,
home computing, how computer people relax, exam marking stories,
getting published, office politics
* the history of computing: e.g. the mistakes, the
disasters, the egos gone mad (with names changed to
prevent law suits), folklore (not necessarily true)
* the future of computing
* computing in the Real World: e.g. in the media, computer
salesmen, misconceptions about computing, the misuse
(abuse) of computing, faulty software/hardware, the
`training' course
* fake journal articles: e.g. AI, expert systems, machine
architectures software engineering, new programming
languages, semantics; surveys of `important' fields:
Virtual Reality, neural nets, OO, what-ever, etcl
* jokes and cartoons (these will only occupy a small portion
of the book)
* suggestions for a better name for the collection
Contributions will be judged on clarity, insignificance,
irrelevance, incorrectness, originality, but most of all for
their ability to make the editor laugh. Authors should make
their papers understandable to a broad audience - not too
many `in-jokes' please.
Authors should submit three (3) copies (preferably
double-sided) of the prospective article to the editor;
people without access to a photocopier may submit a single
copy. Electronic submissions are *not* encouraged.
Each manuscript should have a title page with the title of
the essay, full name(s) and affiliation(s) of author(s),
complete postal and electronic addresses, telephone
number(s), and a 150 word summary.
Contributions must *not* exceed 4000 words (approximately 8
A4 pages typeset 10-point on 16-point spacing, or 12 pages
if typewritten double-spaced). Shorter articles will be
viewed more favourably than longer ones.
Previously unpublished material is preferred. Contributors
of published material must have copyright to it. All
contributors will be asked to sign a permission letter
giving TLA Press the right to print the material but NOT
transferring copyright.
Submissions must be received by April 3rd, 1993. Authors will
be notified of acceptance or rejection by July 1st, 1993. Full
versions of the accepted articles must be formatted according to TLA Press
conventions, and camera-ready copy must be received by the editor
by August 24th, 1993.
For further information, contact the editor:
Summary of Important Dates:
April 3rd, 1993: Due date for 3 copies of submission
July 1st, 1993: Notification of acceptance
August 24th, 1993: Due date for final manuscript
Early 1994: Publication
From: KP
Date: Mon, 30 Nov 1992 14:58:53 PST
Subject: Re: Sigh.
PD writes:
Why am I at all surprised by these things? You'd think I
should know but now. Perhaps my brain refuses to accept that
stuff like this is still so broken. There's hope for me yet.
I suppose we should take it as a good sign that first year
undergraduates are being exposed so early in their career to
the canonical examples of bad design practice.
---- Start of forwarded text ----
From: TK
Date: Thu, 26 Nov 1992 16:01:55 GMT
Subject: HELP!
I just did: cc -o doit.c doit
instead of cc -o doit doit.c
Needless to say I have lost doit.c
Is there anyway I can get it back? (It has been extensively
modified since this morning).
:-(
tk
---- End of forwarded text ----
PD:
You should abandon hope. What the first year undergraduates
must conclude is that this is the way life is meant to be,
since it is obvious that if it could be better, it would be.
What you may have neglected to take into account is that
there is now a multi-billion dollar industry providing
thousands of jobs to system administrators, sub-system
administrators, network administrators, gurus, managers,
professors, and consultants in an effort to keep the monster
alive. They seem to be succeeding.
Sigh, indeed.
From: SG
Date: Tue, 1 Dec 92 16:50:12 -0500
Subject: sleep 5
Don't you just love it? sleep 5. I mean, there's no easy
way to tell UNIX to do one thing, wait for it to finish,
then do another thing. No synchronicty. No REAL job
control. So we just wait for five seconds, and we hope that
the X server has started up.
The worst thing is that these hacks are now enshrined as
"good technical support." They've become the standard way
for getting one's work done.
I think I'll go break all my fingers.
From: HV
Date: Mon, 30 Nov 1992 17:47:10 GMT
Subject: Re: SUMMARY: Alternate and Command Emacs Key Bindings
I sometimes use emacs in coXist 3.0. To get coXist to
recognize the Alt key as the metakey, coXist tech support
told me to put these lines in .xinitrc:
# these 3 lines make the Alt key the meta key in Emacs
sleep 5
xmodmap -e "keysym Alt_L = Meta_L"
xmodmap -e "keysym Alt_R = Meta_R"
From: NP
Date: Tue, 1 Dec 92 17:43:28 -0500
X-Switzerland: Neutral -- but heavily armed.
Subject: Seen On A Whiteboard
UNIX: Unbearably Not ITS eXtended
From: LF
Date: Wed, 2 Dec 92 02:15:56 -0500
Subject: Every Comment Tells A Story, Don't It...
See, you can tell that I'm only a neophyte weenix unie,
because I try to comment my code. And I just noticed that
the comments seem to tell a story, below, in some simple
tools I was trying to write:
# Can't add a "< \!*" to the below or I can't easily use
# them in filter chains... But then again, they're
# unusable anyway! See below. So I'll stick in the "<
# \!*" to make them easier to use on their own (and so I
# don't wonder why it's taking forever when it's
# actually waiting for input...).
# alias words "tr -cs A-Za-z '\012' < \!*"
# alias lowercase 'tr A-Z a-z < \!*'
# These are all a crock, because you basically can't
# make a filter chain by combining simpler verbs if any
# of them require an input redirection instead of a
# filename, because you get "Ambiguous input redirect"
# whenever you actually try to string them together,
# regardless of types of quoting parens, etc. So each
# command has to be _replicated_ in its entirety, rather
# than calling each individual alias. Small, reusable
# tools?
# What a gd crock.
# # Input redirection is a problem for the below.
# # Do I have to stick them in their own file to make them work? Argh.
# alias wl 'lowercase | words'
# alias uniqwords 'lowercase | words | sort -u -'
alias wl "tr A-Z a-z < \!* | tr -cs A-Za-z '\012'"
alias uniqwords "tr A-Z a-z < \!* | tr -cs A-Za-z '\012' | sort -u -"
# God f__king dammit! Embedded parens around this whole
# mess STILL doesn't cause the shell to figure out that
# I want this whole thing run as a single command, hence
# doing "tolines foo > bar" gives "Ambiguous output
# redirect". Doesn't matter whether outside quotes are
# double (with change of inside quotes to single) or
# single, or whether parens have a backslash before
# them. I just have to do "(tolines foo) > bar" to it
# to work. Jesus!
alias tolines 'fgrep "To:" \!* | sort -u -'
..although the more I look at this file of mine, the more I
notice things along the same theme...
# Stupid but simple. Works if nobody has a peculiar
# name or location. The story of UNIX: Something that
# almost works, most of the time. Ignoring even the
# possible screw cases in the grep, the only reason the
# sort even works right is because most finger programs
# tend to use headings that begin with spaces or
# uppercase alphabetics, which will sort before the
# lowercase alphabetics of most UNIX usernames.
alias dayactive 'f \!* | egrep -v "d (Mon|Tue|Wed|Thu|Fri|Sat|Sun)" | sort -'
alias houractive 'f \!* | egrep -v "(d|:[0-9]*) (Mon|Tue|Wed|Thu|Fri|Sat|Sun)" | sort -'
# alias minuteactive 'f \!* | egrep -v "(d|[0-9]*) (Mon|Tue|Wed|Thu|Fri|Sat|Sun)" | sort -'
# Not dayinactive etc because that would make completion harder.
alias -dayactive 'f \!* | egrep "d (Mon|Tue|Wed|Thu|Fri|Sat|Sun)" | sort -'
alias -houractive 'f \!* | egrep "(d|:[0-9]*) (Mon|Tue|Wed|Thu|Fri|Sat|Sun)" | sort -'
# The whole thing, sorted.
alias sf 'f \!* | sort -'
..then we have this winner, because I'm sick and tired of
reading the same damned man page eight times in a row every
time I have to do the same operation (and, of course,
because the _obvious_ command to do this doesn't work in
some lurid way that I recall being discussed here
recently)...
# Yecch on CP for the fact that I can't use it to copy
# things! First arg is fromdir, second arg is todir.
# You must specify both pretty carefully, especially the
# todir, since we cd to the fromdir before expanding the
# todir. Leaves you in the todir. Expect to see
# "tar: Warning: The 'p' option will only restore the
# modes of files you own"
# emitted as a "harmless" diagnostic at the very start.
alias copy_tree 'cd \!:1; tar cf - . | (cd \!:2; tar xvpf -); cd \!:2'
Of course, most of the entries in my .aliases file are there
to modify the syntax of commands so I can remember how to
use them (or to insulate myself from the common screwups I'd
otherwise make), since there's no such thing as interactive
prompting, noise words, argument checking, or any of those
other wimp things that mere lispheads like myself have been
taking for granted since... oh, when did Twenex first
become popular? Before most of the current crop of weenix
unies were born, you say?
Who knows? Maybe there's some tricky way to do what I want
in all the above mess, and I'm sure that asking the local
Twinkie & Jolt addicts would probably get me some plausible
answer. Or maybe I could spend another five hours or so
poking & prodding at things, staring it these tremendously
useful error messages that the various shells emit. Of
course, I could always read the twenty-five THOUSAND words
of nonetheless peculiarly useless description that make up
the man pages for sh, csh, and tcsh, in the vain hopes of
finding something usable in the zillions of ridiculous
little special-case rules about how each little piece of a
command line gets teased apart, in what order, with what
special-case syntax for each part, with the exceptions
listed in the most obscure and offhanded way possible, far
from the actual point at which they'd be useful... (All the
while, of course, beating myself on the head with a mace,
screaming, "It's _not_ a waste of my time to spend hours
learning this stuff! _Really_ I'll use this arcane
knowledge again in some _other_ little shell tool. Who
_cares_ if it took me ten hours to do a task that it would
have taken me about five minutes to write in Lisp?")
The hell with it. Maybe I'll just throw in the towel and
start learning Perl. Who was it who called it "like a
vise-grips: the wrong tool for every job"?
From: JL
Date: Tue, 1 Dec 92 21:41:59 EDT
Subject: Nice Bit Of Ranting, From Comp.Arch
From: ZE
Date: 29 Nov 92 19:15:44 GMT
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
In an article FL writes:
> DS writes:
>
>> I don't know much about HP except that I have been told
>> that their operating system isn't really UNIX. Maybe
>> someone else might want to comment?
>
> HP-UX is real UNIX. HP-UX isn't BSD UNIX, but BSD is no
> longer a standard in demand (it was only ever a
> pseudo-standard in the first place). Even Sun knows this:
> the OS they're going to push for the rest of the decade
> (Solaris) is System V Release 4.
I don't regard it a "real" UNIX, then again I wouldn't buy a
"real" UNIX, 1970s software technology is not something I
would want to buy today.
Getting caught up in the "pure" UNIX war will lead you to
restrict yourself to "pure" SVR4 implementations, in the
mainstream camp *only* SUN have gone for this. That in my
view does not make it much of a "standard".
If a vendor decides to do something about the crass
inadequacies of UNIX we should give them three cheers, not
start a flame war about how the DIRECTORY command *must*
forever and ever be called ls because that is what the great
tin pot Gods who wrote UNIX thought was a nice, clear name
for it.
The most threatening thing I see in computing today is the
"we have found the answer, all heretics will perish"
attitude. I have an awful lot of experience in computing, I
have used six or seven operating systems and I have even
written one. UNIX in my view is an abomination, it has
serious difficulties, these could have been fixed quite
easily, but I now realize nobody ever will.
At the moment I use a VMS box, I do so because I find that I
do not spend my time having to think in the "UNIX" mentality
that centers around kludges. I do not have to tolerate a
help system that begins its insults of the user by being
invoked with "man".
Apollo in my view were the only UNIX vendor to realize that
they had to put work into the basic operating system. They
had ACLs, shared libraries and many other essential features
five years ago.
What I find disgusting about UNIX is that it has *never*
grown any operating system extensions of its own, all the
creative work is derived from VMS, Multics and the
operating systems it killed.
> From my experience if you're writing new code, you're
> smart to implement in Standard C making only calls to the
> Standard C library, the Posix.1 interface, and industry
> standard graphics interfaces. That kind of code is
> maximally portable to HP-UX, Solaris, OSF/1, AIX, DG/UX,
> and SVR4 (hell, it'll probably even work under Windows/NT
> if that ever materializes).
If you do that properly it *will* work under windows NT, and
under VMS too. That is what POSIX is all about. From now on
UNIX will no longer be able to exist as a lowest common
denominator system, the pressure will be to implement the
higher POSIX levels such as threads.
In the long term basing your choice of hardware on the
operating system will no longer be necessary, for VMS to
survive against Windows NT, it will have to be ported to
other platforms. For SUN to continue to sell hardware they
will have to support Windows NT as will HP.
From: LK
Date: Wed, 2 Dec 1992 16:35:26 PST
Subject: Emacs, Ghostscript, GDB, and strings
In Ghostscript in GDB mode in Emacs, I typed a command which
printed out a short string:
GS>12 frobstring ==
( &*y
Later, I yanked this string back into an expression, and got
what appeared to be a fatal error:
GS>/Courier 14 mungefont ( &*y Program received signal 3, Quit
0x1a7eb4 in read ()
(gdb)
Only slightly daunted, I tried to continue, and found it
worked. Of course, this is Unix, so you can continue from
Quit.
But as soon as I typed in the expression, the error happened
again:
(gdb) c
GS>/Courier 14 mungefont ( &*y Program received signal 3, Quit
0x1a7eb4 in read ()
(gdb)
Well, by shortening the command line more and more, I found
the problem: The string I had yanked into the command like
contained a CTRL-\ character in it, which caused the signal
whenever I pressed return.
The story you have just seen is true. Function names have
been changed to protect the innocent.
From: GR
Date: Thu, 3 Dec 92 10:58:46 -0500
Subject: Unix Really Wants A Terminal To Deliver Mail
We've all seen the "not a typewriter" spurious error
messages in mail bounced by Unix. Apparently some Unix
weenie has noticed that typewriters/teletypes are no longer
in common use, so has updated the mail delivery software to
require a newer technology, namely a display terminal of
some recognized sort. For what purpose, of course, I have
no clue. The best part, of course, is that it tries to
instruct the recipient of the bounced mail message to
correct the situation, twice.
Return-Path: <
[email protected]>
Date: Thu, 3 Dec 1992 04:17:55 -0500
From: Mail Delivery Subsystem <
[email protected]>
Subject: Returned mail: unknown mailer error 1
To:
[email protected]
Cc:
[email protected]
----- Transcript of session follows -----
lock t (scheme-atics) permanently locked - consult a guru
lock t (nfmaint) permanently locked - consult a guru
You have no TERM environmental variable. This variable
tells the system what type of terminal you are using so it's
features may be used.
To set this variable:
From csh type 'setenv TERM <term-type>'.
From sh type 'TERM=<termtype>;export TERM'.
Where <term-type> is the system designation for your terminal.
(E.g. hp2621, adm3a, aaa40, etc).
You have no TERM environmental variable. This variable tells the
system what type of terminal you are using so it's features may be used.
To set this variable:
From csh type 'setenv TERM <term-type>'.
From sh type 'TERM=<termtype>;export TERM'.
Where <term-type> is the system designation for your terminal.
(E.g. hp2621, adm3a, aaa40, etc).
554 "| /usr/spool/notes/.utilities/nfmail -s scheme-atics"... unknown mailer error 1
----- Recipients of this delivery -----
Bounced, cannot deliver:
"| /usr/spool/notes/.utilities/nfmail -s scheme-atics"
Sent successfully:
<
[email protected]>
<
[email protected]>
From: JA
Date: Thu, 3 Dec 1992 15:01-0500
Subject: Re: Unix Really Wants A Terminal To Deliver Mail
Not only can the weenix unies not get this "not a
typewriter" bit right, evidently they did not attend schools
in which English grammar is a required subject.
Date: Thu, 3 Dec 1992 10:58 EST
From: GR
----- Transcript of session follows -----
lock t (scheme-atics) permanently locked - consult a guru
lock t (nfmaint) permanently locked - consult a guru
You have no TERM environmental variable. This variable
tells the system what type of terminal you are using so
it's features may be used.
----
From: MF
Date: Thu, 3 Dec 92 15:42:40 -0500
Subject: Privacy
I recently read the following remark in the smalltalk
newsgroup:
Everytime I create a private method, I cringe knowing
that it isn't _really_ private, and I could make a
dreadful mistake in utilising it when I shouldn't.
Now I know that this wasn't a weenix uny who said this but I
couldn't help thinking that maybe this is a problem with
Unix developers. If they can't even trust themselves to use
their own code, how can they possibly use and fix anybody
else's code. Everything in Unix is private - the design
(non-existant), the code (no source), the programmatic
interfaces (obscure), even the documentation (non-existant,
incorrect or incomprehensible).
From: RS
Date: Thu, 3 Dec 1992 19:49:19 -0500
Subject: FYI: [*GRUMBLE!*]
------ Forwarded Message
From: DA
Date: Wed, 2 Dec 92 23:50:58 EST
Subject: [*GRUMBLE!*]
I log on. I notice that I am over quota. I delete a core
file. I am now under quota. I decide to delete several
lines of a log file, the rest of which I want to save. I
cannot save the edited version, because _when_I_logged_in_ I
was over quota. Am I left with the previous version of the
file? No, because the editor erased the old one in the
process of trying to save the new one, _after_ which the
write failed. I lost the parts I wanted to save.
*grumble*
Is this an Ultrix thing, or do disk quotas behave like this
on all flavours of UNIX?
I am _not_ amused.
And as far as I can tell, the weekly backup wasn't run last week.
------ End of Forwarded Message
From: JL
Date: Thu, 3 Dec 92 23:13:33 EDT
Subject: RE: Unix Really Wants A Terminal To Deliver Mail
Not only can the weenix unies not get this "not a
typewriter" bit right, evidently they did not
attend schools in which English grammar is a
required subject.
Date: Thu, 3 Dec 1992 10:58 EST
From: GR
----- Transcript of session follows -----
lock t (scheme-atics) permanently locked - consult a guru
lock t (nfmaint) permanently locked - consult a guru
You have no TERM environmental variable. This
variable tells the system what type of terminal
you are using so it's features may be used.
It's worse than that: The last sentence also has a usage
error. "May" refers to permission; "can" refers to ability.
Setting TERM provides the system with the ABILITY to use
various terminal features; it has nothing to do with
permission, a concept fairly alien to the Unix mindset in
any case.
But the BIGGEST joke is that there is yet another error here
- an error in the use of Unix terminology! TERM is an
"environment" variable. There is no such thing as an
"environmental" variable. (Perhaps that would be a variable
that, if set, prevented you from printing, so as to preserve
trees?)
From: LF
Date: Fri, 4 Dec 92 01:34:23 -0500
Subject: No Further Comment Necessary
- - - Start of forwarded message - - -
From: CH
Date: Fri, 4 Dec 1992 00:32:22 -500 (EST)
Subject: AIX Updates
Seen on comp.unix.aix:
In the pathetic descriptions of fixes that come with the
tape (most of which don't tell you what they're for but tell
you they don't take effect until you reboot...), was this
prize winner:
IX30126
This defect will replace your current rule files. You
will need to save them off before you install this
defect.
Now they're shipping us supplementary defects, in case we
didn't get enough with the original system.
- - - End of forwarded message - - -
From: LF
Date: Fri, 4 Dec 92 00:58:05 -0500
Subject: I'll Bet This Is How UNIX Filesystems Get 110% Full
- - - Start of forwarded message - - -
Date: Fri, 4 Dec 92 00:55:43 -0500
From: LF
To: [Recipients deleted to protect the, well...]
Subject: Hey! [Later: Never mind---I hate UNIX flame number 57]
[Why is it I always get these bright ideas _after_ I've sent
in
a bug report?]
This problem has been fixed:
Date: Fri, 4 Dec 92 00:45:10 -0500
From: LF
Subject: Hey!
Two days ago, /mas/mc/re has 186meg or more of free
space. Now there is absolutely no space left on the
device. What the hell happened? How can we re-free
that space? This is my primary file storage space
(having just relocated myself there two or three weeks
ago from /u), so this is pretty critical for me.
Several hours ago, I started a grep over a medium-sized
directory, writing its output into a file. I then
immediately took off to a seminar, leaving it running (from
someone's console in Tech Square), came back frm the
seminar, and logged out the job without looking at the
output---I figured I'd do that later.
Suddenly (just after I sent the above bug report), I had a
horrible thought.
I'll bet the more astute among us have already grasped the
problem. The output file was IN the directory I was
searching, and grep merrily infinite-looped, finding targets
in its OUTPUT file and stuffing evidence of them back into
the output file.
File locking? Not seeing output files in "ordinary"
directory listings until their output is finalized? Version
numbers? Common sense in coding? Gee, these concepts are
only 30 years old (some are older). Any one of the above
would have prevented this problem. It's a real pity that
UNIX still hasn't managed to grasp these concepts.
(I know that the deficiencies of UNIX aren't your folks'
problem per se. You've got to deal with what the iron
vendor dishes out, as do we all. I just figured that, as a
member of the Learning and Common Sense group, it sure
doesn't bode very well that our computational environment
show no evidence of either.)
See you on the UNIX-Haters mailing list...
- - - End of forwarded message - - -
From: BS
Date: Fri, 4 Dec 1992 05:29:49 -0500
Subject: Robust Development Environments...
Hi all...
I first had an inkling that something wasn't right with
weenix when, in 1984, I was compiling a version of CCA Emacs
(yeah, yeah, I know), on a Convergent Technologies MegaFrame
(don't even start)...I noticed that for some strange reason,
emacs was jumping right smack dab into the middle of the
data space. Well, as it turned out, the compiler or library
routines, or someone, (they never did fess up) had decided
that "sigtrap" should be an undocumented global variable. I
would have continued a life of blissful ignorance if CCA
hadn't chosen to use it as the name of a function. (Oh,
yeah, I forgot to mention - they only had "adb" as a
debugger. It took a while to figure out just what was going
on...)
With regard to weenix, it's been downhill from there...
I also have to second RS's comment to me that "programming
in C is like smoking cigarettes out behind the schoolhouse
as a kid - you have to keep looking over your shoulder to
see if you're going to get busted..."
From: JL
Date: Fri, 4 Dec 92 07:09:04 EDT
Subject: Re: FYI: [*GRUMBLE!*]
------ Forwarded Message
Date: Wed, 2 Dec 92 23:50:58 EST
From: DA
Subject: [*GRUMBLE!*]
I log on. I notice that I am over quota. I delete
a core file. I am now under quota. I decide to
delete several lines of a log file, the rest of
which I want to save. I cannot save the edited
version, because _when_I_logged_in_ I was over
quota. Am I left with the previous version of the
file? No, because the editor erased the old one in
the process of trying to save the new one, _after_
which the write failed. I lost the parts I wanted
to save.
*grumble*
Is this an Ultrix thing, or do disk quotas behave
like this on all flavours of UNIX?
Mr. A is being hurt by a Unix bug, a bug accidentally
introduced into the file system code when Unix was first
written.
You see, a file is internally described by an inode entry,
which contains 13 pointers to the disk blocks that
constitute the file. The first 10 of these pointers behave
normally, but a strange mutation occured in some code left
sitting overnight on a disk in a room where the air
conditioning had failed. As a result of this mutation, the
eleventh pointer came to point, not to a block of the file,
but to a block containing a whole bunch more (like 256)
pointers. Later on, replication of the erroneous code
fragment due to gamma ray damage made things even worse:
Now, the twelfth pointer points to a block of pointers to
blocks of pointers, and the thirteen to a pointer to blocks
of pointers to blocks of pointers to blocks of pointers (or
something like that).
A result of this bug was the cancerous growth in Unix file
sizes. Remember that a cancer is uncontrolled growth, in
the wrong place at the wrong time. In the intended scheme,
no file could be more than 13 blocks long, and most of Unix
was designed around that assumption. The mutations
introduced the potential for growth way beyond this design
parameter. Needless to say, nothing has worked quite right
since. The X window system is probably the worst of example
of metastasized Unix code. I think it's safe to say that no
piece of X would have managed to survive on a Unix system
with only the original 13 block pointers.
I am _not_ amused.
And as far as I can tell, the weekly backup wasn't
run last week.
It wouldn't have helped even if it had been run.
From: MF
Date: Fri, 4 Dec 92 12:51:25 -0500
Subject: New and Improved!
I know that I've seen SG mailing to this list, otherwise I
wouldn't have left his name in the following. Maybe he's
being ironic.
-Mark
****Revolving Seminar****Revolving Seminar****Revolving Seminar****
The NeXT Programming Environment
SG
Senior Editor, NeXTWORLD Magazine
December 8
4:00-5:00 PM
Refreshments at 3:45
NE43-8th Floor Playroom
NeXTSTEP is the object-oriented environment that runs on
NeXT and 80486-based computers. It has been under
development and under marketed by NeXT Computers, Inc., for
the last seven years.
Writing programs for NeXTSTEP is fundamentally different
than writing programs for other computers, because NeXTSTEP
represents a radical departure from conventional programming
environments. One writes NeXTSTEP programs by building
systems of related but distinct parts, called objects, and
connecting them together to form an integrated whole.
Confining different aspects of a program to different pieces
makes those pieces easier to design, implement, debug, and
reuse. This is what is known as object-oriented programming.
NeXTSTEP embodies the principles of object oriented
programming from its user interface down to its very
core. This greatly simplifies the task of interfacing
application programs with the NeXTSTEP operating
environment. The downside is that it makes the NeXTSTEP
environment very different from the environments to which
most programmers are accustomed: there's a steep curve to
climb when learning to program in this easy-to-program
environment (sounds strange, but it's true).
From: PR
Date: Fri, 04 Dec 92 13:24:34 -0500
Subject: Re: FYI: [*GRUMBLE!*]
Date: Wed, 2 Dec 92 23:50:58 EST
From: DA
I log on. I notice that I am over quota. I delete a
core file. I am now under quota. I decide to delete
several lines of a log file, the rest of which I want to
save. I cannot save the edited version, because
_when_I_logged_in_ I was over quota.
Ordinarily, I wouldn't dare to post an operational work
around for a case of Weenix dain bramage.
However, in this case, the problem to be solved and my
method of solution are both so supremely heinous, that I
think this is the strongest condemnation of Weenix I could
generate, short of vomiting in your mailbox.
I will give no caveats or disclaimers about the reliability
of the following code. If you use it, I hope it DOES fail
on you. I hope it destroys all your files, one helpless
screaming bit at a time. I hope it causes you to swear off
Weenix, and perhaps computers in general and go become a
beet farmer in Montana.
And people say that automation can't improve your quality
of life...
--------
#! /bin/csh -f
# This shell script allows you to ignore your soft quota and continue
# ramming files into your account all the way up to your hard limit.
# Drop this into your .login file, or invoke as needed.
# Invoke with a filename whose size is sufficiently large to bring you
# below soft quota.
set tmpdir="/tmp"
set fdefault=""
if ($#argv != 1) then
if ("$fdefault" == "") then
set tmp=$0
echo "Usage: $tmp:t filename"
exit(1)
endif
set fname="$fdefault"
else
set fname="$1"
endif
mv $fname $tmpdir
mv ~/.cshrc ~/.c
#@ this is the only way I can find to make a rlogin exit automatically:
echo "exec echo ''" > ~/.cshrc
# if we're down to our last warn, then we don't need this:
rlogin `hostname`
rm ~/.cshrc
mv ~/.c ~/.cshrc
mv $tmpdir/$fname:t $fname
quota
From: IH
Date: Fri, 4 Dec 92 17:53:24 EST
Subject: Re: FYI: [*GRUMBLE!*]
Gods, that's a disgusting kludge.
From: SG
Date: Sat, 5 Dec 92 00:02:21 -0500
Subject: Re: FYI: [*GRUMBLE!*]
WRONG
VERY WRONG
Trying to post information TO UNIX HATERS on how to fix such
a crazy, broken operating system as UNIX is just UTTERLY
WRONG. Don't you understand, PR? Our goal is to destroy
UNIX.
One of the problems of UNIX is that every lousy user has to
have some sort of magic shell script or alias or
dot-something else and there's all of this knowledge
alegedly floating around, so we spend all of our time
passing around these secrets instead of getting our work
done.
Other operating systems (Macintosh, NeXTSTEP) basically work
out of the box with no tweaking.
UNIX DOESN'T. That's why it must die.
From: AB
Date: Sat, 5 Dec 92 19:55:30 EST
Subject: Warning.
TOO MUCH UNIX-HATERS MAIL! Come on guys, let's cut down on
the me-tooism. Unix-Haters is not a place for conversations
-- even flaming ones. Don't respond to other people's
messages to Unix-Haters unless you have a genuinely -new-
piece of Unix braindamage to contribute at the same time.
A good rule of thumb: If you are composing mail to
Unix-Haters, and you stared with the "reply" command (you
typed "r" in emacs rmail mode), then stop right there, your
message probably doesn't belong here. Think: "would the
message I am sending still seem appropriate next week?". If
your answer is "no", then don't send it. If your answer is
"yes", then send it next week.
From: CM
Date: Sun, 6 Dec 92 13:21:37 EST
Subject: Re: FYI: [*GRUMBLE!*]
From: IH
Date: Fri, 4 Dec 92 17:53:24 EST
Gods, that's a disgusting kludge.
Gods, how horrible for you that you were able to understand
it.
From: PM
Subject: [C++ Compilers Considered Harmful]
Date: Mon, 07 Dec 92 13:22:48 -0500
From: JB
Subject: C++ compilers considered harmful
Date: Fri, 04 Dec 92 14:25:21 -0800
Here is an error message I got from my C++ compiler today:
line 25: error: static class member declared static
Now, I've long been aware that C++ uses the word "static" to
mean several essentially unrelated things, but that error
message is still ridiculous.
To: JL
Date: Mon, 7 Dec 1992 11:39:16 PST
Subject: Re: Unix Really Wants A Terminal To Deliver Mail
Oh, it's even worse than that. It's sending *you*, the
sender of mail from a machine far, far away, an error
message about a problem with a program (not sendmail, this
time) that can only be fixed by someone on the local
machine.
From: JW
Date: Mon, 7 Dec 92 19:30:19 -0500
Subject: Re: Unix Really Wants A Terminal To Deliver Mail
Date: Mon, 7 Dec 1992 11:39:16 PST
From: CK
Oh, it's even worse than that. It's sending *you*, the
sender of mail from a machine far, far away, an error
message about a problem with a program (not sendmail,
this time) that can only be fixed by someone on the
local machine.
Right. This is an Important Unix Concept known as
Distributed Responsibility, or Blame Load Management. I,
personally, feel that whoever first enunciated this
principle captured the essence of the True Unix Gestalt, and
should be given some sort of prize, such as an AT&T 3B2
computer all their very own.
Now, what is going on here is that, if you think about it,
it would make no sense to send that error message to anyone
on the "local machine", because -they've already received-
1873 error messages just today alone, and (here's the key)
-they've come to think it's normal-. They expect them.
Think about it. When you saw that message, did you say
"Gee, Bob (this is assuming your office mate's name is Bob),
that mailer over on nohost.nodomain.edu sure is broken; it's
sent us an error message!"? Did you?? Noooo. You said
"heh heh, it's the not-a-typewriter thing again. Haven't
seen that in at least a week!".
Now think what you'd have done if it was the 1873rd time
you'd gotten that message today. What you'd say, if I had
to guess, is "sh*t, my gd 'd' key is worn out again.
Anybody got any contact cleaner?"
So you see, sending that message to the local machine
wouldn't help at all. Instead, they've sent it off to Some
Other Person, chosen at random. (Well, sort of. The Unix
RAND (3C) function is not, how shall we say, entirely
modern). The hope is that that other person will take an
action which will cause this particular error message to
Stand Out, and thus be acted upon. Perhaps, for example,
the person receiving the message will find themself thinking
"gees, you know, I spent 4.3 years writing that paper, and
if it isn't published I will be thoroughly hosed, and now
the copy I sent to Eminent Senior Professor Billy-Jo
Globular at his request has been delivered to "not a
typewriter". At which point you will FedEx a paper copy to
Dr. Globular, along with a remarkably humble note of
apology, and the honorable Dr. Globular will do the only
possible right thing, which is to trundle off to the
Sendmail Administrator and feed him to a python.
Unix. It may not work, but it knows its limits.
From: MC
Date: Tue, 8 Dec 92 22:57:04 EST
Subject: The AIX Environment.
% unsetenv TERM
% telnet idiocy
No environment-specified terminal type.
%
% setenv TERM VT100
% telnet idiocy
No terminfo entry for "VT100".
%
% setenv TERM vt100
% telnet idiocy
telnet: Unknown host idiocy
From: SH
Date: Thu, 10 Dec 92 15:24:47 -0500
Subject: lockd(eath)
As you may know, lockd is Sun's miserable excuse/bandaid for
a file system that allows two processes to clobber the same
file simultaneously. So, we use it, since we don't want
this to happen to our users. We have HP's and we have a
Motorola M88K SVR4 machine.
We have found that any HP can lock a file on any other HP.
The Motorola can lock any file on itself or any HP. But if
an HP attempts to lock a file on the Motorola, the HP's
lockd server crashes every time.
Since we are calling the lockf function by the book, I
figure the two servers don't speak the same language and
that there must be a log message somewhere. Fat chance. So
I read up on lockd and discover the logging option. So I
restart lockd on the HP with logging. I then crash the lock
server and look in the log, NO FRIGGING MESSAGE! (although
it gives me a *truly* useful core dump). I still don't know
what's wrong. Why does the market put up with this shite!
From: DW
Date: Fri, 11 Dec 92 10:40:09 EST
Subject: Re: lockd(eath)
You think this is bad? Recent queries at my company about
this feature turned up the following helpful advice:
From someone:
Network file locking is a disaster area. NFS does
support it; but the code is unbelievably buggy. Sun
releases jumbo patches monthly. Other vendors have
more problems.
I'd recommend that we have a separate server process,
deployed optionally, to handle this. If you want
protection over the net, you have to run our lock
server.
NFS file locking over the network is routinely and
consistently broken. Not just the PC NFS forms, but on
the workstation products. We should avoid the use of it
if we possibly can.
From someone else:
I'd like to second this observation. At my previous
company we found that each new release of SunOS seemed
to break lockf and file locking; we implemented our own
semaphore system to circumvent the problem.
To write software under Unix is one part writing software
and nine parts battling Unix.
From: CM
Date: Fri, 11 Dec 92 14:10:24 EST
Subject: Re: lockd(eath)
Date: Thu, 10 Dec 92 15:24:47 -0500
From: SH
As you may know, lockd is Sun's miserable excuse/bandaid
for a file system that allows two processes to clobber
the same file simultaneously. So, we use it, since we
don't want this to happen to our users. We have HP's
and we have a Motorola M88K SVR4 machine.
We have found that any HP can lock a file on any other
HP. The Motorola can lock any file on itself or any HP.
But if an HP attempts to lock a file on the Motorola,
the HP's lockd server crashes every time.
Since we are calling the lockf function by the book, I
figure the two servers don't speak the same language and
that there must be a log message somewhere. Fat chance.
So I read up on lockd and discover the logging option.
So I restart lockd on the HP with logging. I then crash
the lock server and look in the log, NO FRIGGING
MESSAGE! (although it gives me a *truly* useful core
dump). I still don't know what's wrong. Why does the
market put up with this shit!
My theory is this: Sun and HP are out in California and for
many years have been infiltrated by radical left wing
ecoterrorists.
Finding and fixing a bug in software requires many hours of
programmer and computer time. This translates into
thousands of tons of pollutants generated by power plants
that generate the fuel for the computers and the twinkie
factories that generate the fuel for the programmers.
To cut down on the amount of pollution, the radicals are
making Sun and HP recycle on the sly. The fact that Sun's
lockd can't talk to HP gives it away: this sounds
suspiciously like the old bug with Sun's talk program that
only let it talk to other Sun boxes. That's right --
they're recycling software bugs.
I suppose it's for the good of the planet. This may also
provide clues as to why Sun and HP claim to have these
incredibly fast RISC cpu's and yet their computers still
feel like Vax 11/780's on valium. Maybe it's not just
software...
From: SL
Date: Fri, 11 Dec 92 10:48:33 -0800
Subject: Another Mail Story
My machine was switched to Solaris. Of course, everything
stopped working: my .login file failed; emacs wouldn't run;
there was no compiler; I couldn't print; I couldn't run ps,
or even shutdown.
This is known as "progress."
But that's not what this note is about. This is a note
about mail.
Along with most every other useful tool on the system, the
mailer didn't work. When I tried to send a test message to
myself, it kindly informed me that it was having a hard
time, and it wrote the message to the file dead.letter in my
home directory. Twice. It also mailed me a message about
its troubles, just to make sure I knew. Of course this also
failed, so _it_ was written to dead.letter.
At some point this recursion stopped, but not before it had
written multiple copies of useless gibberish to dead.letter,
which now contains:
From glibber Wed Dec 9 04:14 GMT 1992
Return-Path: <glibber>
Received: by pla.nes.leng (5.0/SMI-SVR4)
id AA07273; Wed, 9 Dec 92 04:14:03 GMT
Date: Wed, 9 Dec 92 04:14:03 GMT
From: glibber (SGlibber)
Message-Id: <
[email protected]>
Apparently-To: glibber
Content-Type:
Content-Length:
This is a test.
From glibber Wed Dec 9 04:14 GMT 1992
Return-Path: <glibber>
Received: by pla.nes.leng (5.0/SMI-SVR4)
id AA07273; Wed, 9 Dec 92 04:14:03 GMT
Date: Wed, 9 Dec 92 04:14:03 GMT
From: glibber (SGlibber)
Message-Id: <
[email protected]>
Apparently-To: glibber
Content-Type:
Content-Length:
This is a test.
From glibber Wed Dec 9 04:15 GMT 1992
Return-Path: <Mailer-Daemon>
Received: by pla.nes.leng (5.0/SMI-SVR4)
id AA07275; Wed, 9 Dec 92 04:14:03 GMT
Date: Wed, 9 Dec 92 04:14:03 GMT
From: Mailer-Daemon (Mail Delivery Subsystem)
Subject: Returned mail: unknown mailer error 15
Message-Id: <
[email protected]>
To: Postmaster
Content-Type:
Content-Length:
----- Transcript of session follows -----
mail: /var/mail/glibber
mail: Return to glibber
mail: /var/mail/glibber
mail: Cannot return mail.
mail: Mail saved in /usr/home/glibber/dead.letter
mail: Mail saved in /usr/home/glibber/dead.letter
554 glibber... unknown mailer error 15
----- Message header follows -----
Return-Path: <glibber>
Received: by pla.nes.leng (5.0/SMI-SVR4)
id AA07273; Wed, 9 Dec 92 04:14:03 GMT
Date: Wed, 9 Dec 92 04:14:03 GMT
From: glibber (SGlibber)
Message-Id: <
[email protected]>
Errors-To: glibber
Apparently-To: glibber
content-length: 16
From glibber Wed Dec 9 04:15 GMT 1992
Return-Path: <Mailer-Daemon>
Received: by pla.nes.leng (5.0/SMI-SVR4)
id AB07275; Wed, 9 Dec 92 04:14:03 GMT
Date: Wed, 9 Dec 92 04:14:03 GMT
From: Mailer-Daemon (Mail Delivery Subsystem)
Subject: Returned mail: unknown mailer error 15
Message-Id: <
[email protected]>
To: glibber
Content-Type:
Content-Length:
----- Transcript of session follows -----
mail: /var/mail/glibber
mail: Return to glibber
mail: /var/mail/glibber
mail: Cannot return mail.
mail: Mail saved in /usr/home/glibber/dead.letter
mail: Mail saved in /usr/home/glibber/dead.letter
554 glibber... unknown mailer error 15
----- Unsent message follows -----
Return-Path: <glibber>
Received: by pla.nes.leng (5.0/SMI-SVR4)
id AA07273; Wed, 9 Dec 92 04:14:03 GMT
Date: Wed, 9 Dec 92 04:14:03 GMT
From: glibber (SGlibber)
Message-Id: <
[email protected]>
Errors-To: glibber
Apparently-To: glibber
content-length: 16
This is a test.
From glibber Wed Dec 9 04:15 GMT 1992
Return-Path: <Mailer-Daemon>
Received: by pla.nes.leng (5.0/SMI-SVR4)
id AA07275; Wed, 9 Dec 92 04:14:03 GMT
Date: Wed, 9 Dec 92 04:14:03 GMT
From: Mailer-Daemon (Mail Delivery Subsystem)
Subject: Returned mail: unknown mailer error 15
Message-Id: <
[email protected]>
To: Postmaster
Content-Type:
Content-Length:
----- Transcript of session follows -----
mail: /var/mail/glibber
mail: Return to glibber
mail: /var/mail/glibber
mail: Cannot return mail.
mail: Mail saved in /usr/home/glibber/dead.letter
mail: Mail saved in /usr/home/glibber/dead.letter
554 glibber... unknown mailer error 15
----- Message header follows -----
Return-Path: <glibber>
Received: by pla.nes.leng (5.0/SMI-SVR4)
id AA07273; Wed, 9 Dec 92 04:14:03 GMT
Date: Wed, 9 Dec 92 04:14:03 GMT
From: glibber (SGlibber)
Message-Id: <
[email protected]>
Errors-To: glibber
Apparently-To: glibber
content-length: 16
From glibber Wed Dec 9 04:15 GMT 1992
Return-Path: <Mailer-Daemon>
Received: by pla.nes.leng (5.0/SMI-SVR4)
id AB07275; Wed, 9 Dec 92 04:14:03 GMT
Date: Wed, 9 Dec 92 04:14:03 GMT
From: Mailer-Daemon (Mail Delivery Subsystem)
Subject: Returned mail: unknown mailer error 15
Message-Id: <
[email protected]>
To: glibber
Content-Type:
Content-Length:
----- Transcript of session follows -----
mail: /var/mail/glibber
mail: Return to glibber
mail: /var/mail/glibber
mail: Cannot return mail.
mail: Mail saved in /usr/home/glibber/dead.letter
mail: Mail saved in /usr/home/glibber/dead.letter
554 glibber... unknown mailer error 15
----- Unsent message follows -----
Return-Path: <glibber>
Received: by pla.nes.leng (5.0/SMI-SVR4)
id AA07273; Wed, 9 Dec 92 04:14:03 GMT
Date: Wed, 9 Dec 92 04:14:03 GMT
From: glibber (SGlibber)
Message-Id: <
[email protected]>
Errors-To: glibber
Apparently-To: glibber
content-length: 16
This is a test.
From glibber Wed Dec 9 04:16 GMT 1992
Return-Path: <Mailer-Daemon>
Received: by pla.nes.leng (5.0/SMI-SVR4)
id AB07299; Wed, 9 Dec 92 04:16:38 GMT
Date: Wed, 9 Dec 92 04:16:38 GMT
From: Mailer-Daemon (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <
[email protected]>
To: glibber
Content-Type:
Content-Length:
----- Transcript of session follows -----
554 glibber... Recipient names must be specified
----- No message was collected -----
From glibber Wed Dec 9 04:16 GMT 1992
Return-Path: <Mailer-Daemon>
Received: by pla.nes.leng (5.0/SMI-SVR4)
id AB07299; Wed, 9 Dec 92 04:16:38 GMT
Date: Wed, 9 Dec 92 04:16:38 GMT
From: Mailer-Daemon (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <
[email protected]>
To: glibber
Content-Type:
Content-Length:
----- Transcript of session follows -----
554 glibber... Recipient names must be specified
----- No message was collected -----
I am not interested in hearing that I have mis-analyzed the
situation, or that somehow somewhere it was all-my-fault.
If you have any such inclination, you will be punished by
being given the job of sysadmin on my machine. And yes, it
is a full-time job.
From: CM
Date: Sun, 13 Dec 92 17:12:29 EST
Subject: Aurora Software Christmas Special
When NeXT decreed that command line interfaces were out,
they created a whole market for point-n-click front ends to
the usual manure pile of unix utilities that we know and
love so much. You can wrap shite up in shiny paper and silk
ribbon but it's still shite.
From: VB
Date: 8 Dec 92 04:36:44 GMT
Subject: Aurora Software's Christmas Special
20% Off
All Software From
Aurora Software
12/1/92 to 12/24/92
Between now and Christmas purchase any software product from
Aurora Software at 20% off the regular price! Software
products include:
QuickStart(TM) Dock extender/application organizer.
QuickStart provides the software power
user with a convenient window to place
software applications in. Unlike the
dock, QuickStart is not limited to only
11 applications; you can place an
unlimited number of applications in
QuickStart. Furthermore, QuickStart's
"Hide on Launch" feature gives QuickStart
power to the user without occupying more
than a single icon's worth of screen
space. QuickStart is the one piece of
software no NeXT computer should be
without.
FileStart(TM) The ultimate file, folder and application
organizer. Gain instant access to
frequently used files, folders and
applications by organizing them with
FileStart. Save time and energy by not
interrupting your work to look for files
or applications. Simply drag a file,
folder or application into FileStart and
it will always be conveniently within
reach. Moreover, by strategically
grouping related files and folders into
projects you can open multiple files with
a single double-click of the mouse. Get
organized with FileStart!
Tarre(TM) Compression & archive utility.
Compress and backup your files on a
regular basis with Tarre, the easy-to-use
compression and archive utility from
Aurora Software. Compress files by as
much as 93% by simply dragging them into
the Tarre application icon. Or, backup
files and folders into archive files,
which can be stored on removable media
for safekeeping. Tarre uses the standard
UNIX(TM) programs "tar" and "compress" to
read and write archive files that are
compatible with virtually every UNIX
system. Gain access to the plethora of
free software stored on the ftp archives
in tar format!
LoadEye(TM) System load monitor.
LoadEye displays your NeXT's system load
in a Load Monitor that you can place
anywhere on your screen. By observing
how your actions affect your computer's
system load you can learn to use your
computer more efficiently and
effectively. For the software developer,
LoadEye provides an indication of how
much load your application puts on a
system, thus allowing you to decide
whether further optimizations are
necessary.
SuffixRecycler(TM) Search and recycle.
Are you losing disk space to
automatically generated backup files?
Many applications automatically backup
files as they are edited.
Unfortunately, a large number of such
backup files can dramatically reduce
your available disk space. The
solution? Simply drag a folder into
SuffixRecycler, enter the suffix you
wish to recycle by
(e.g. ".frame.backup" or "~") and click
on the recycler button. All files in
the folder that have names ending in
the suffix will then be moved to the
recycler---automatically.
These software products make great gifts for anyone using a
NeXT computer, be it colleague, spouse, offspring or friend.
For more information on any of these products, to order, or
for gift suggestions, contact Aurora Software:
Toll free: 1-999-999-9999
Phone: (999) 999-9999
FAX: (999) 999-9999
Email:
[email protected]
__
Copyright (c) 1992 Aurora Software. All rights reserved.
QuickStart, FileStart, Tarre, LoadEye and SuffixRecycler are
trademarks of Aurora Software. All other trademarks are the
property of their respective owners.
From: JL
Date: Mon, 14 Dec 92 07:23:51 EDT
Subject: Finally, A Good Use For All Those Silly Extra Mail Headers
Relevant portion from a mailing I received recently:
From: BM
X-Windows: Some voids are better left unfilled.
Of course it then proceeds to include one of those annoying:
X-Face: h~X8+M9ij%8t43w1:^tB#%)'a0+Z<\9]d-%fIR"f8ux"ZxpX7t/]m<g'{nHGENJ4i/xbFW^
;Mpso<c``f78J5.23MLTr3GN&=)2kix'lw^"k}9Vm{es1Dy'@]WK}Y}?Xv'rzd`O?o-SnG'^MO.{$U
]$S]Nb3St_e_'RUu?Ha_3"]&&A%<s(1lYY-KF;rLtez{JK6gN~t/Pp-Yom_r:bPQ!}%|P.BmE!
I don't really WANT to know what's behind that.
From: RC
Date: Mon, 14 Dec 92 09:40:43 EST
Subject: Consistent Behavior Of Commands
This happened a while back and I mailed it to a friend. He
said I should send it to this mailing list, so here it is.
$ lpq
lpq: bozo: printer/tcp: unknown service
Hmm. Weird printer error I haven't seen before. Should I
notify the systems administrators? Nah, this is Unix.
Maybe I should just try exactly the same thing again and
see what happens.
$ lpq
bozo is ready and printing
Rank Owner Job Files Total
Size active quezon 773 /tmp/ESa20256
87656 bytes $
From: RS
Date: Fri, 18 Dec 1992 02:08:20 -0500
Subject: Happy, Happy, Joy, Joy... NOT!!
F__KING LOUSY, NO-GOOD, PIECE OF SHITE SORRY-ASSED EXCUSE
FOR AN OPERATING SYSTEM...
What do you suppose
csh# rm -rf /tmp/.*
does?
If you said "Csh expands that on the command line and tries
to recursively remove the directory above /tmp (root)", you
were right.
Too bad the shithead who wrote rm couldn't be BOTHERED to
special case obviously bogus commands like "Recursively
remove the directory above me, please". Undoubtedly,
though, the Unix weenies will maintain that this is the
right thing.
Too bad I decided to swallow my pride and whore myself to
make a little cash on the side by doing UNIX CONSULTING so
now I look like an idiot in front of clients.
Too bad I didn't OWN the Sparc 2 in question so I could
HEAVE IT THROUGH THE PLATE GLASS WINDOW, and watch it
PLUMMET THREE STORIES TO THE CONCRETE SIDEWALK BELOW AND
SMASH INTO A MILLION BILLION TINY PIECES.
There, I feel better now.
From: RC
Date: Fri, 18 Dec 92 07:24:39 EST
Subject: Re: Happy, Happy, Joy, Joy... NOT!!
RS writes:
What do you suppose "csh# rm -rf /tmp/.*" does?
If you said "Csh expands that on the command line
and tries to recursively remove the directory above
/tmp (root)", you were right.
Too bad the shithead who wrote rm couldn't be
BOTHERED to special case obviously bogus commands
like "Recursively remove the directory above me,
please". Undoubtedly, though, the Unix weenies will
maintain that this is the right thing.
Very nice. Particularly in view of the manual page for rm
which states:
WARNING
It is forbidden to remove the file `..' to avoid
the antisocial consequences of inadvertently doing
something like `rm -r .*'.
There is no indication that anything overrides this. What
useful protection! How nice to have a system which knows
better than I what I really meant to do.
Incidentally, I tried this out for myself just to see if it
worked the same way on my system. This is Unix, and
consistency is not guaranteed. It did the same thing, but
with one other delightful addition:
lancet% mkdir foo
lancet% cd foo
lancet% mkdir bar
lancet% cd bar
lancet% /bin/rm -rf `pwd`/.*
Segmentation fault
lancet%
After all, what Unix feature is complete without the ever
popular Segmentation Fault?
From: RC
Date: Fri, 18 Dec 92 07:49:31 EST
Subject: Re: Happy, Happy, Joy, Joy... NOT!!
***** ***** *****
Incidentally, I tried this out for myself just to see if
it worked the same way on my system. This is Unix, and
consistency is not guaranteed. It did the same thing,
but with one other delightful addition:
lancet% mkdir foo
lancet% cd foo
lancet% mkdir bar
lancet% cd bar
lancet% /bin/rm -rf `pwd`/.*
Segmentation fault
lancet%
***** ***** *****
Sorry to clutter up this list but in case it isn't obvious
in light of the original complaint I guess I ought to add a
"do not attempt this at home" here. I tried it out
somewhere where it wouldn't really matter.
Date: Fri, 18 Dec 1992 09:22-0500
From: AW
Subject: Re: Happy, Happy, Joy, Joy... NOT!!
Date: Fri, 18 Dec 1992 07:49 EST
From: RC
***** ***** *****
Incidentally, I tried this out for myself just to
see if it worked the same way on my system. This is
Unix, and consistency is not guaranteed. It did the
same thing, but with one other delightful addition:
lancet% mkdir foo
lancet% cd foo
lancet% mkdir bar
lancet% cd bar
lancet% /bin/rm -rf `pwd`/.*
Segmentation fault
lancet%
***** ***** *****
Sorry to clutter up this list but in case it isn't
obvious in light of the original complaint I guess I
ought to add a "do not attempt this at home" here. I
tried it out somewhere where it wouldn't really matter.
Right. He tried it on a Unix.
Go ahead. Attempt this at home. I have a real computer.
From: IH
Date: Fri, 18 Dec 92 11:04:53 EST
Subject: Re: Happy, Happy, Joy, Joy... NOT!!
<sorry, AB. This is a reply, but it's about a different
obnoxious feature>
Right. Well if you understood ANYTHING, then you would know
that the correct incantation was:
ian@reamer> rm -rf /tmp/.??*
But then you find that some wize wizzard has overloaded the meaning of
?, at least here at MIT-AI, so that when you TYPE "rm -rf /tmp/.??*",
you GET:
tla@reamer> rm -rf /tmp/.
../ ./ .X11-unix/ .getwd
tla@reamer> rm -rf /tmp/.
../ ./ .X11-unix/ .getwd
tla@reamer> rm -rf /tmp/.*
If you don't notice that ? has now been overloaded with
"list possible file name completions", in time to stop
typing and avoid hitting return, then it will do "rm -rf
/tmp/.*" ANYWAY. After you get screwed with this a few
times you learn that what you should REALLY type is "rm -rf
/tmp/.^V?^V?*". This is why we should all use Unix(tm)
instead of ITS: unix doesn't require you to type arcane
combinations of control keys to manipulate your files. You
bash yourself in the head, take a large drink of Ripple and
say "Of course! A child could figure it out!" And after
deleting your directory a few times, you get it right.
Of course this won't work if you have files with names like
".x", in which case you have to type "rm -rf /tmp/.[^.]*", I
THINK. You see there's this problem in unix: there are
REGULAR EXPRESSIONS, which are one thing, and then there are
REGULAR EXPRESSIONS, which are a different thing, and I
sometimes get them confused for some reason, so I'm not sure
whether "/tmp/.[^.]*" is a regular expression or a regular
expression. They're really very different in appearance,
which is good because they have incompatible semantics.
Pop quiz: identify the types of the following patterns:
(a) "a*"
(b) "a*"
(answers: (a) is a regular expression, but (b) is not - it's
a regular expression).
Note the difference in spelling: the patterns used by the
shell are called "regular expressions", whereas the patterns
used by everything else are called "regular expressions."
You should never get them confused. You see regular
expressions are used for matching in the shell and are
documented in the section "REGULAR EXPRESSIONS", whereas
regular expressions are used for match, a very different
task, in grep(1), and are documented in the section on
"REGULAR EXPRESSIONS". The former look like strings, but
have special wildcard characters like "?", "*", and "[]",
whereas the latter also look like strings but have special
wildcard characters which look like "?", "*", and "[]". Be
sure to notice the differences in appearance because they
have different semantics. For example, the regular
expression "[a-z]*" matches all strings consisting of
lower-case letters, whereas the regular expression "[a-z]*"
matches all files begining with a lower-case letter.
I hope this had made everything clear to everyone.
From: LK
Date: Fri, 18 Dec 1992 11:08:44 PST
Subject: Tar And Feathers Vs. Feathers And Tar: Which Works Better?
We long ago resigned ourselves to using Unix, and with it
we've resigned ourselves to its odd syntactic idioms.
We've all long ago resigned ourselves to using TAR to copy
files. It no longer seems a travesty, only a wart.
In the midst of all this resignation, only unix-haters
causes us to stop and wonder, where we would otherwise
merely give up and move on.
I'm pausing to share my wonder with you at this gray hair on
a wart on a mole. (Please, no informative replies.)
% cd /adoc/ruble/src/xloadimage-3.01
% (cd /project/pagemill/utils/xloadimage-3.01/; tar cf - . ) | tar xBpf -
tar: directory checksum error (0 != 4451)
% cd /project/pagemill/utils/xloadimage-3.01/
% tar cf - . | (cd /adoc/ruble/src/xloadimage-3.01 ; tar xBpf - )
%
From: NP
Date: Tue, 22 Dec 92 12:38:56 -0500
X-Switzerland: Neutral -- but heavily armed.
Subject: [The _Globe_ on UNIX]
From: JC
Date: Tue, 22 Dec 1992 11:21:52 EST
Subject: The _Globe_ on UNIX
>From the December 22 Boston _Globe_:
"The AT&T operation, Unix System Laboratories,
designs and promotes Unix software, a so-called
operating system..."
Date: Tue, 22 Dec 92 23:18:15 EST
From: AB
Subject: Time To Go Home Now.
I am so happy that Kerberos has informed me that I have been
working for 8 hours by suddenly yanking my permission to
write files over the network, thus blowing away the
complicated recursive makefile that I got from somebody else
that I don't really understand. A novice Unix user would
probably have sent a bug report to the makefile's author,
thus making a fool of himself, but I am an -experienced-
Unix user, and so I know that when ever anything
inexplicable happens, the -first- thing I should do is check
to see if it is close to 8 hours after I logged in. Thank
you Mr. Kerberos Sir, I shall certainly go home now.
From: CL
Date: Wed, 23 Dec 92 01:18:45 -0500
Subject: Or Should At Least Carry Warning Labels
Lately I've noticed a lot of people with buttons that read
SEX,
DRUGS,
and UNIX
and I think, "Yep, three things that can mess up your life..."
--
From: JL
Date: Fri, 25 Dec 92 08:36:58 EDT
Subject: Yes, C *Does* Rot The Brain
I was looking through a C program - it's a Unix tar file
reader for VMS, nicely implemented by several experienced
programmers over the years - when the following bit of code
struck my eye:
if (!inbytes && inbytes)
{
fprintf( stderr, "tar: unexpected EOF on tar file.\n" );
perror("tar");
close( outfd );
return;
}
That wonderful "idiom" of C - using integers as "Booleans"
to test for zero/ no-zero! What a way to hide complete
nonsense as apparently clever code! Had it been written as:
if ((inbytes != 0) && (inbytes == 0))
it would have been immediately obvious that something was
wrong. As it was, I stared at the line for the longest time
trying to understand what strange new idiom the author had
invented. Bizarre test for inbytes < 0? But why? Explicit
test for inbytes == -1? Again, why? Despite the fact that
I'm an experienced programmer (hell, when I started FORTRAN
IV was still competing with the older FORTRAN II, which I
learned; I'm no stranger to "idiomatic programming", having
used APL for several years; and I've been using C heavily
for some 13 years - what a horrible thought!) I *still*
ended up writing a little test program to make sure I
understood this expression correctly.
That its "A and not A" appearance doesn't IMMEDIATELY and
obviously condemn it as clearly wrong is just another sign
of how badly C's cavalier use of integers as "Booleans" can
twist the mind.
(Of course, if this had been written in C++, it would have
been:
if (!inbytes && inbytes)
{
stderr << "tar: unexpected EOF on tar file.\n"
}
or something like that, and the error would have been clear,
right?)
I long ago made it a personal rule to use Boolean operators
only on Boolean variables. I'm willing to use a language
without all the wonderful safety features, after all, I *am*
a *power programmer*. But there's no point being a damn
fool about it.
From: JL
Date: Tue, 29 Dec 92 07:54:39 EDT
Subject: Interesting Signature Line
If David Cutler had been a heavy drug user in the 60's, he
probably would have written Unix instead ...
(For those who don't know, Dave Cutler designed RSX, VMS, and most
recently Windows NT.)
From: AB
Date: Tue, 29 Dec 92 19:02:19 -0500
Subject: Should I Laugh Or Cry?
Today I noticed that my mail reader was having trouble
properly separating the messages in my inbox from each
other. I am not certain, but I think I have identified the
problem. Normally messages in a sendmail inbox are
separated from each other by lines of the form:
From
[email protected] Tue Dec 29 16:11:52 1992
But today, half the messages in my inbox start with lines
that look like:
From TERM=xterm HOSEHEAD.eve.rcl.ear:@iu.su.tla.com,@dawn.su.tla.com:rpg%
[email protected] Tue Dec 29 18:20:27 1992
(This is an actual example.) I presume the extra space in
the line is what confuses the inbox parser.
From: JD
Date: Sat, 2 Jan 1993 20:10:02 -0500
Subject: Wonderfull security
The esu rpct ultrix box has a suitably paranoid BOFH, who
when he noticed people logged on from lcp.money.com,
promptly added that machine to the hosts.deny file (which
appears to have about 100 entries)... since this was not an
official act, there of course was no appeal.
we could call the rpct dialup (at $6/hr to ma bell), but there was
an easier way - use rsh rather than telnet, and avoid all that nasty
hosts.deny stuff...
From: MD
Date: Sun, 3 Jan 93 01:31:25 -0500
Subject: [Waiting Mail]
Date: Sun, 3 Jan 93 00:00:41 EST
From:
[email protected]
Reply-To:
[email protected]
Subject: Waiting Mail
After 0 days (23 hours), your message to the following people:
host.deleted.deleted!deleted (host=deejay)
has not yet been delivered. Attempts to deliver the message will
continue for 0 more days. No further action is required by you.
----- Queued message begins -----
[etc. etc. etc. - hostname deleted by me]
OK. Does this mean my message has been byte-bucketed, or
no?
From: JL
Date: Thu, 7 Jan 93 19:55:37 EDT
Subject: Sign The Man Up :-)
[I'm not sure exactly where this came from; it reached me
after several forwards].
The ever-amusing RP wrote the following letter to the editor of
";login:," The USENIX Association Newsletter, Nov./Dec. '92.
Dear Rob,
I was surprised that you disagreed on the headline [in the
Sept. issue of BYTE magazine] reporting the death of UNIX.
Not only is UNIX dead, it's starting to smell bad. If not
for the advanced state of decomposition, I'd recommend an
autopsy. Even without one, though, I can predict what an
autopsy would have revealed:
Cancerous pockets throughout; the entire system ravaged by
malignant growths.
Opportunistic parasites in all major organs.
A grossly enlarged liver due to frequent systemic
poisonings.
A failed immune system unable to respond to the onslaught.
Cause of death: a system utterly drained of vitality by
the constant struggle of fighting the diseases.
One can only speculate on the mental health of the patient.
RP
From: JL
Date: Fri, 8 Jan 93 07:54:06 EDT
Subject: Re: Sign The Man Up :-)
[RS and I exchanged a couple of private messages about my
posting of RP's anti-Unix article. As I was writing this
one, I thought others might find it enlightening as well.]
Nah. I don't need any stomach medication. I think things
are looking up. When even the Unix rags are publishing
things like this, from people like RP, the recognition is
finally coming to everyone that Unix is dying, and quickly.
Unix reminds me of Communism: The original belief that this
was the paradise on Earth; the conviction of inevitability;
the long, dull grinding intermediate years, as the
intellectuals keep finding positive features in something
that those really involved know has none; the recognition
that collapse is inevitable, but the warning that it could
take many, many years. My prediction is that, as with
Communism, we will see the final sudden total collapse.
One could actually expand this into a nice allegory, with
the two centers of Communism (USSR vs. China) and the two
centers of Unix (BSD vs. System V). Clearly BSD is like
Maoism, remaining pure through it all, while System V is
Soviet attempts at compromises with reality, doomed to fail
because the core is rotten. I don't know where exactly OSF
fits in; I suppose it's what we would have gotten if a
government of real left-wing intellectuals and apologists
had gotten into power in the early '70's. Posix is
Eurocommunism: Keep some of the basic ideas, but compromise
to be accepted by the rest of the world. It'll die when the
core dies.
Plan 9 and such are the Peruvian Sendoro Luminoso: The
intellectuals build a new movement from pieces of the old
and generate great enthusiasm, at least among some. But
Sendoro has been crushed, and no one can seriously think
that Plan 9 is going anywhere as a widely-use operating
system.
The great laugh is that, just as Communism has been
supplanted by capitalism, the system it used for all its bad
examples, Unix is going to be supplanted by Windows NT, a
re-done version of the OS Unix weenies hate the most, VMS.
From: PS
Date: Fri, 8 Jan 93 09:54:40 EST
Subject: Re: Sign The Man Up :-)
Abimael Guzman's imprisonment has not defeated Sendero
Luminoso. It will be impossible to defeat Sendero Luminoso
without addressing the root problem in Peru, which is that
the poor are terribly poor and the rich are laughing all the
way to the bank, while the army and police are a bunch of
brutal thugs who commit utterly horrifying crimes with
complete impunity.
If we were to compare this government to an operating
system, we would somehow have to communicate that it is the
standard model exported by our masters for use in Latin
American countries. Let's see -- the United States
oligarchy could be AT&T, small Latin American countries
could make up the hapless user community, and the
U.S. military personnel who "advise" all the most repressive
and criminal armies in the hemisphere could be Unix System V
hackers.
The Europeans could be purveyors of "Unix with a human
face": Motif and its ilk, so that the EC corresponds to OSF.
The Clinton administration and the nascent NAFTA community
could be the Sun/AT&T axis: same old shite, slightly dressed
up.
As for Windows NT, it has no equivalent in this scenario.
From: SS
Date: Mon, 11 Jan 1993 19:11:22 -0500
Subject: The Darker Side of C++
[lecture in Finland next week - maybe the cited papers are
worth getting]
Swiss Federal Institute of Technology in Lausanne
Department of Computer Science
Software Engineering Laboratory
ANNOUNCEMENT OF A LECTURE
-- "THE DARKER SIDE OF C++" --
Wednesday, January 27, 1993
15.15 o'clock (end at 17.00 at the latest)
Ecole Polytechnique Federale de Lausanne - Site Ecublens
Batiments du Departement d'informatique - room INR 219
by MARKKU SAKKINEN, University of Jyvaskyla, Finland
About the lecturer:
------------------
Markku Sakkinen is a member of the Department of Computer
Science and Information Systems, University of Jyvaskyla,
Finland. He has been an active researcher in
object-oriented programming since 1988, with several
published papers in international journals and conference
proceedings. He has been on the programme committees of
ECOOP'91, EastEurOOPe'91, ECOOP'92 and ECOOP'93, and
reviewed papers for other conferences and journals.
Content:
-------
The talk is mostly based on paper [1] augmented by ideas
from [2]. Because of its C heritage, C++ is both weakly
typed and weakly structured. Because of the basic design
decisions that were made in its object-oriented extensions,
I claim that C++ is also weakly object-oriented. I will
discuss several aspects and consequences of what I call the
Fundamental Defect: that objects do not carry inambiguous
type information at run time, in contrast to almost all
other OO languages. The undisciplined handling of pointers
(as in C) makes the problems worse. I will also mention
some interesting problems of multiple inheritance, mostly
pertaining to the distinction between "virtual" and
"non-virtual" base classes (superclasses). Several other
features and their problems will be mentioned, such as:
reference types and argument passing, nested classes,
storage classes and garbage collection, overloading,
assignment and copying, templates (genericity) and
exceptions.
The worst disadvantage of C++ at the moment is political:
accepting C++ as the standard OO language de facto tends to
kill other existing languages, and stifle the development of
a new generation of essentially better OO languages.
Ample time will be left for questions and discussion after
the lecture. That allows us to look at some details that
really interest the audience. Also, many of my opinions are
controversial, and I do not expect all listeners to accept
them quietly.
References:
----------
[1] Markku Sakkinen, "The Darker Side of C++ Revisited",
which appeared in Structured Programming, Vol. 13 No. 4
(1992).
[2] Markku Sakkinen, "A Critique of the Inheritance
Principles of C++", in Computing Systems, Vol. 5 No. 1
(1992).
Date: Tue, 12 Jan 93 08:52:41 EDT
From: JL
Subject: Re: The Darker Side of C++
He's wrong. To paraphrase Pink Floyd, "There is no Darker
Side of C++. As a matter of fact, it's all dark."
From: JL
Date: Tue, 12 Jan 93 09:01:03 EDT
Subject: Re: What A Stupid Algorithm
You just don't get it, do you? This is part of PLANNING FOR
THE FUTURE. Look, suppose your workstation crashed shortly
after you walked away from it. (Yes, I know, Unix never
crashes - it just runs very slowly, like taking 15 minutes
to respond, now and then.) If your processes were still in
volatile main memory, they'd be GONE. But with Sun's
algorithm, they are safely stored away on your non-volatile
hard disk.
You say that when your system reboots (err, I mean, when it
starts running more quickly again) you don't get those
processes back? Well, that piece of the system hasn't been
finished yet. But we're working on it; after all, it'll be
written in C, which makes it very easy. No, wait, we're
doing this one in C++ - you know, the object-oriented
language that makes programming a breeze. All we need to do
make your process an object and everything will fall out
easily. Be right back to you....
From: WA
Date: Tue, 12 Jan 93 09:36:37 EST
Subject: Swapping Out Idle Processes
You mean it *MARKS THE PAGES DIRTY* after swapping them
out????????? Geez, the TI Exploder LISP machines that I had
to deal with at TLA around 1985 had that bug, and it was
considered highly amusing (by Symbolics people, at least) at
the time. There was a bug in the microcode that caused it
to mark the page dirty rather than clean after swapping it
it out, which of course made the memory scavenger have the
opposite effect from what was desired. It was just a bug!
It was not a feature, and it was not what anyone would have
considered acceptable behavior. Operating systems still
have this bug?????
From: CL
Date: Tue, 12 Jan 93 10:18:37 -0500
Subject: Re: What A Stupid Algorithm
RS says:
>> But I didn't come here today to talk about why 2 emacses
>> and a window system should take five times the total
>> memory in the late AI KS-10. [...]
Hey, just who are you calling "late"? The AI KS10 is alive
and well and living here at FTP.
From: JL
Date: Thu, 14 Jan 93 17:36:36 EDT
Subject: It's Worse Than That
This one rants at many OS's, but the rant against Unix is
kind of nice. (Of course, it's not really right. It would
be "grep store", not only would you reach speeds of 200 mph
but you'd run down several children en route, and you would
arrive IN the barber shop, not AT it.)
------- Start of forwarded messages -------
From: TP
Date: Thu, 14 Jan 93 16:01:03 EST
Subject: Driving Your OS To The Store
This one reminds me of a great bit I saw on the Net recently
(sorry, don't have a proper attribution), along the lines of
If the car industry progressed as rapidly as the
computer industry has over the past 20 years, a Rolls
Royce would cost 5 dollars, cruise all day at 1000 miles
per hour on a thimble of gas, and blow up killing all
passengers once a month.
bloody-optimists-ly y'rs - tim
--------
[tons of e-mail headers deleted{
From: MK
WHAT DRIVING TO THE STORE WOULD BE LIKE IF OPERATING SYSTEMS
RAN YOUR CAR
MS-DOS: You get in the car and try to remember where you put
your keys.
Windows: You get in the car and drive to the store very
slowly, because attached to the back of the car is a freight
train.
Macintosh System 7: You get in the car to go to the store,
and the car drives you to church.
UNIX: You get in the car and type GREP STORE. After
reaching speeds of 200 miles per hour en route, you arrive
at the barber shop.
Windows NT: You get in the car and write a letter that says
"go to the store." Then you get out of the car and mail the
letter to your dashboard.
Taligent/Pink: You walk to the store with Ricardo Montalban,
who tells you how wonderful it will be when he can fly you
to the store in his Learjet.
OS/2: After fueling up with 6000 gallons of gas, you get in
the car and drive to the store with a motorcycle escort and
a marching band in procession. Halfway there, the car blows
up, killing everybody in town.
S/36 SSP [mainframe, obv.]: You get in the car and drive to
the store. Halfway there you run out of gas. While walking
the rest of the way, you are run over by kids on mopeds.
AS/400: An attendant locks you into the car and then drives
you to the store, where you get to watch everybody else buy
filet mignons.
-------
From: MG
Date: Thu, 14 Jan 93 16:35:47 EST
Subject: RE: Driving your OS to the store
What? No MVS? How about this:
MVS: You fill up, get in your car, and declare your intent
to go to the store, specifying the exact location, distance
and speed. On the way, if you change your mind or guess
wrong, your car complains "ABEND" and drives you back home,
spilling any unused gas on the ground. You get to try again
tomorrow.
------- End of forwarded message -------
From: GP
Date: Thu, 14 Jan 1993 18:38:54 -0500
Subject: Why Are Crays Easier To Install Than SCO Boxes?
I love password expiration and overzealous security! RS had
a really fun time reloading a SCO box here this weekend
because it had expired the root password. Apparently, it
would have warned me had I not been logged in when it wanted
to expire it. Apparently, it would have warned me when I
logged out, if the power outage hadn't done that for me.
But no, it just expired me.... thanks SCO!
But, that's not what I am here today to talk to you about, I
am here to talk about the wonderful SCO Unix
installation.... There is something wrong with a UNIX
system that is more difficult to install than UNICOS (the
Cray version of UNIX). Especially on a couple-thousand
dollar 386 box.
Picture this, you have a Dell 386 box sitting in front of
you and an impressive pile of 40+ 3.5" floppies. You feed
it the first one, which it gladly accepts, displaying its
plumage-like splash screen proudly. Next, it asks for the
second disk to be loaded. No sweat, you pop out the N1 disk
and load in the N2 disk and hit return. The light comes on,
disk whirls, screen clears, text follows...... and then it
stops. You wait a minute, two, three, get Jolt, and it
still doesn't ask you for another disk... By now you have
noticed that the disk light isn't on and the drive isn't
whirling, so you reboot and try it again. Needless to say,
the superstitious remedy doesn't work, just more wasted time
goes by. At about this time, you spy the 1-800 number for
their technical support folks, and decide to give it a
whirl...
Hmmm, an audio response system to "help process your call
more efficiently." How wonderful, 4 levels of menu later
they tell me they will transfer me to "next available
agent." I wait about 35 minutes before I finally get a
human being (well, if they didn't want to pay for me to wait
on the phone, they would have either asked me to press 1 to
continue every once in a while or not installed an 800
number, right? :-) ). Well, the human had no idea why this
system which is listed as working in their compatibility
guide wouldn't even install past the first disk, but they
assured me that if I would stay on hold, they would transfer
me to someone who had a clue.... 25 minutes later I got a
person who asked me what my problem was, had not a clue how
to fix it, but would be glad to get me in touch with
somebody who had a clue. In order to avoid running out of
stack space, I decided to leave a message instead of
holding.
2 days later I decided they weren't going to call me back,
so I called again... you guessed it, I was on hold. 20
minutes later (at least the wait appeared to decrease over
time), I got passed to somebody who took a message and
promised me that "the person who did the compatibility
testing on that configuration would return my call as soon
as they could so that they could tell me what was wrong with
my hardware configuration."
Well, by the next week, I had had just about enough of this
shite, so I decided to do something really off the wall. I
called Dell's technical support line. Since the machine was
over 2.5 years old, the warranty had expired and since I got
SCO from other services, they certainly had no obligation to
answer my questions....so this is what happened:
I dialed their 800 number and got a real human. She asked
for my serial number, tickled her keyboard for a second and
read off my configuration and address. They asked what they
could do for me, and I explained that I didn't know if they
could help, but I was having problems installing SCO Unix on
my Dell box. They passed me off to a UNIX support guy. I
told the guy my problem, and he informed me that he had done
an install on the same configuration the previous
week... surprised, I answered a number of questions and we
finally found out that the SCO stuff can only load from the
A drive, but I was booting the install disk from the B
drive. The Dell person walked me through logically changing
my drive ids (not requiring a physical change).
Well, that should be the end of my "I hate SCO, I like Dell"
story, but it isn't. I had this silly idea that it would be
nice to inform the SCO folks what happened, just in case
they had another customer with the same problem. That was a
mistake for both of us. Again, I was on hold for a long
time, and once I got a human again, I got some ridiculous
condescending bullshite about "that can't happen, because
DOS boxes cannot boot off of their B drives." I asked to
speak to a manager, who then backed up his employee and told
me that he didn't understand why I was calling if I didn't
have a problem any more...
Customer service, the UNIX way. If it doesn't work, it must
be your fault, and if you paid us to get it to work, you
were stupid! At least with CTSS I didn't have to pay for
the OS.
From: RK
Date: Tue, 19 Jan 93 20:27:58 EST
Subject: Jibber Jabber
Or, it's *too hard* to implement left-to-right evaluation...
From: DK
Date: 19 Jan 93 03:49:17 GMT
Subject: Re: Incrementing Pointers During Function Call
RC writes:
>What I'm having difficulty with, is understanding why it's
>undefined, when it actually affects the programmer's
>meaning. A few people have written back
The programmer is a senseless amorphous mass incongruently
trying to draw reasonable reactions from a senseless
electronical and mechanical lump of junk. It cannot possibly
have a meaning.
>the compiler is changing the meaning of my program.
Of course. That is so that the junk better comprehends the
mass. Masses jibber high level, and junks gobble only
machine language. Ask a junk the meaning of high level. If
you are lucky it will only core dump.
>I appreciate that it doesn't matter what the compiler does
>to implement a function call, as long as it's consistent
>at both ends, and with all the other libraries that can be
>linked in. But that isn't involved in this issue. Here the
>order of execution of my parameters is being swapped
>around.
Who would not like to be consistent at both ends.
Who would not dream of having his parameters executed?
From: MR
Date: Wed, 20 Jan 93 09:33:58 EST
Subject: More On Compiler Jibberings...
C and UNIX (they say) are designed for the
programmer who likes things "terse" and quick. That's why
the commands are 2 or 3 character names like "ls" and
"awk". That's all fine with me, but what really boggles my
mind a little bit is the C compiler/environment.
Nowadays we have ANSI C, which is intended to solve
some of the problems with C. Well, one of the big problems
with C that ANSI C "solves" is function parameter call
mismatches. It *FORCES* you to pre-declare functions and
their parameters before you use them, and it checks to make
sure that you're handing it the right thing if you invoke
it. Well, actually, it will accept any random joe bob data
if you use this wonderful thing called a "cast" which lets
you tell the compiler, "sure that string is really an IEEE
floating point number. go use it. don't bother to try to
convert it to anything first." But casts aren't what we're
here to talk about today, - we're here to talk about
function prototyping and how it is good for you.
It's surprising, really, that C, a language
developed in the heady, terse UNIX environment would
incorporate something like function prototypes. It's a lot
of extra typing. Worse, it makes the programmer do extra
work to generate reasonably correct code.* I've always been
amazed that the scrotty-bearded UNIX gurus out on the net
haven't done everything they could to kill this awful waste
of keystrokes. Think of the bandwidth savings in usenet
source postings alone, if function prototypes were removed!
Of course the most amazing thing about function
prototypes that everyone overlooks is that a DECENT
environment, with a decent compiler and linker, would be
able to check all that stuff at link time! There's nothing
wrong with C as it was originally designed, it's just that
nobody thought to have link-type parameter checking built
into the compilation environment. Rather than someone
putting all that work into the linker (what, a few months?)
we have a language standard that forces every user to
perform the job of link editor in their head. Great. And
it's becoming the lingua franca of programming in the 90s.
It's grimly amusing to note that UNIX, the cradle of C as it
were, lags hopelessly behind DOS in the quality of C
programming environments, with the notable exception of
Saber-C. Saber-C is another unusual case, however, since it
gives you a NICE environment, with compile and link error
checking, runtime error checking, and so on, and when you
want to actually generate an executable....? You're on your
own and you're back to using the outdated piece of shit
compiler the vendor gives you with your system - a
descendant of the original 'pcc' or some similar
abomination, hacked on by generations of grad students on
their way to guruhood. Or you can use gcc, if you have the
time, the MIPS, and the disk space, and can tolerate its
little foibles.
The crowning glory of it all is C++, the birthplace
of function prototypes. Function prototypes must have been
implemented the way they were because it was easier for the
compiler writer to get all the parameters before starting to
parse the function, rather than having to figure them out in
the ensuing lines. When a language is bent, twisted, and
malformed to save the compiler writer a bit of effort,
you've got to wonder why the guy's writing compilers in the
first place. Now, C++ could really use a decent compilation
environment, with link time name resolution. But
NnnnnoooooOOOOOOO, rather than "do it right" some late night
caffeine and taco fever nightmare scheme was concocted
whereby symbols get transformed into DES-encrypted dog vomit
and back.
C++ is heading for standardization. All of this
happened because nobody wanted to put a few hooks for type
checking in their linker and object file format. I think
there's a lesson in all this, but I'm damned if I can see
it.
*The story of the programmer who wrote all his function
prototypes to accept (char *) and cast everything to (char
*) before calling any function is pure fiction. Really.
From: RS
Date: Wed, 20 Jan 1993 10:37:27 -0500
Subject: Re: More On Compiler Jibberings...
> Date: Wed, 20 Jan 93 09:33:58 EST
> From: MR
> Subject: More On Compiler Jibberings...
>
> ...
> There's nothing wrong with C as it was originally
> designed,
> ...
bullshite.
Since when is it acceptable for a language to incorporate
two entirely diverse concepts such as setf and cadr into the
same operator (=), the sole semantic distinction being that
if you mean cadr and not setf, you have to bracket your
variable with the characters that are used to represent
swearing in cartoons? Or do you have to do that if you mean
setf, not cadr? Sigh.
Wouldn't hurt to have an error handling hook, real memory
allocation (and garbage collection) routines, real data
types with machine independent sizes (and string data types
that don't barf if you have a NUL in them), reasonable
equality testing for all types of variables without having
to call some heinous library routine like strncmp,
and... and... and... Sheesh.
I've always loved the "elevator controller" paradigm,
because C is well suited to programming embedded controllers
and not much else. Not that I'd knowingly risk my life in
an elevator that was controlled by a program written in C,
mind you...
From: RC
Date: Wed, 20 Jan 93 12:05:37 EST
Subject: Re: ...Compiler Jibberings...
> Date: Wed, 20 Jan 93 09:33:58 EST
> From: MR
> Subject: More On Compiler Jibberings...
>
> ...
> There's nothing wrong with C as it was originally
> designed,
> ...
bullshite.
Since when is it acceptable for a language to
incorporate two entirely diverse concepts such as setf
and cadr into the same operator (=),
...
And what can you say about a language which is largely used
for processing strings (how much time does Unix spend
comparing characters to zero and adding one to pointers?)
but which has no string data type? Can't decide if an array
is an aggregate or an address? Doesn't know if strings are
constants or variables? Allows them as initializers
sometimes but not others?
(I realize this does not really address the original topic,
but who really cares. "There's nothing wrong with C as it
was originally designed" is a dangerously positive sweeping
statement to be found in a message posted to this list.)
From: MR
Date: Wed, 20 Jan 93 13:26:22 EST
Subject: Re: More On Compiler Jibberings...
I *like* C (don't tell) - but C++ and its creeping
mindnumbness really bugs the HELL OUT OF ME!!! Most of that
rant was aimed to follow what a buddy of mine calls the
"reverse socratic slam" whereby you argue:
1: 'A' is nauseating (and you give reasons)
2: anything worse than 'A' is surely unthinkable
3: -but- 'B' is, in fact, worse than 'A'
Generally when slamming C++ all you need to do is find
something C does badly, point and jeer and say, "lookit how
DUMB that is good golly!" and then pause, ask the audience,
"can you imagine something worse?" and while they're all
still shaking and puking and they finally quaver "nonono!"
you point out that C++ in fact *DOES* something worse!!
Gets 'em every time.
Let's do the exercise:
C's notion of how data objects are stored to disk is
pretty primitive. This can be excused to a degree because C
wasn't *designed* to solve that problem, it's a lower-level
language. However, it's clear that any reasonable
higher-level language needs to support some kind of not
entirely brain-crippled persistent storage.
C++ is designed as an "object oriented programming
language" but, if you look at how object persistence can be
done..... uh.... It *CAN* be done, right? You mean you
need to write some kludgy stuff that does a C-style write()
and assigns a type flag and then does a *cast* or something
down in its guts?? And if you cast an object to another
type of object it forgets what it is? Waitamminit!!!! You
mean every application that wants to do persistence has to
kludge its own application-specific tricks together to make
it work?
Yes. C++. At better compiler stores near you.
From: DH
Date: Wed, 20 Jan 93 15:19:01 EST
Subject: Gimme A Break
Date: Wed, 20 Jan 93 13:26:22 EST
From: MR
Generally when slamming C++ all you need to do is find
something C does badly, point and jeer and say, "lookit
how DUMB that is good golly!" and then pause, ask the
audience, "can you imagine something worse?" and while
they're all still shaking and puking and they finally
quaver "nonono!" you point out that C++ in fact *DOES*
something worse!!
Translated: stop complaining about the hammer smacking you
in the head when the big guy with the ice pick shows up.
Gimme a break. This kind of reasoning leads to accepting
Unix or voting for presidential candidates.
Why not demand something worthwhile?
From: RM
Date: Thu, 21 Jan 1993 18:06:53 PST
Subject: Another Day, Another Lost File
No, this isn't a story about the Fast File System or the
Journalled Fast File System or the Network File System
crashing on me and turning /dev/sd0fmh259 into cottage
cheese; this is a story about ordinary shell commands, and
the ways of typing "yes" and "no". [Hint: it isn't about
calls to "(clear-input *query-io*)", which is something
every implementation of yes-or-no-p I've written would
contain.]
For about a week I've had an Emacs running on my machine
logged-in as "hqm". The reason, or course, is that I
started doing some trivial bug-fixes for some problems he
was having from his machine, which bloomed into a full-scale
system major-version upgrade which touched most files in the
system, which meant that our terminally sophisticated
version-control system ended up with most system source
files "locked" by him.
Now eventually I got somewhat tired of this situation, and
tried to find a way to be myself again. Now of course I was
unable to find any way to do this (staring at man pages for
tens of minutes leads to a particular feeling of frustration
combined with rage -- and RCS is one of the better, more
robust, better documented systems out there.) But then I
realised that Unix has a Wonderful Feature, quite unlike all
those Proprietary, Closed, Non-Object-Centric systems out
there: all its files are just big, steaming heaps of bytes,
so I could directly edit the version-control files (whose
format I did not and do not understand) to directly effect
the change I wished to make. I was emboldened to pursue
this course of action by the fact that "hqm" and "mly" both
have three letters, and I couldn't see anything which looked
like a checksum anywhere. Well, believe it or not, this
actually worked!
Well, for a while I thought that it might not have worked,
because I kept getting an error about "RCS file foo.c is in
use" (an error-message to which no reference could be found
in any manual, and on which commands like "rcs -unlock
-force -gd" had no effect but to cause it to be repeated)
but it turns out that this is just normal, regular unix
brain-death, caused by a machine having crashed in the
middle of a source-control transactional critical section.
RNMWO anybody? BTW it only took me about half a day to
regain control of my files. Hey, another technique (which
just occurred to me) would have been to "check-in" all the
partially-broken development files and then check them all
out as myself, and them somehow try to back the public
sources back out to the previous, consistent state. I guess
I could have used some keyboard-macro wonderment to make
that happen. It might have only taken three or four hours.
But I didn't come here to talk about missing RCS features or
filesystems designed by subhumans, I came to talk about my
pals "mv" "chown" and "cp".
But before I do that, I should tell you about my adventures
trying to actually be "hqm" for a week so that I could attempt
to continue the hacking I'd started, before I decided to engage
in the adventure of wresting control of the sacred sources from
him. I do the normal unix thing of "su"-ing to the super-user
and then "su"-ing to "hqm" (so much easier and more secure than
asking him for his password, I find.) So now I was typing at a
terminal emulator with Henry's shell prompt and Henry's
environment all set up and I started Emacs which loaded Henry's
initialisation file and I attempt to mess with a file and RCS
tells me that I can't because the file is already checked-out by
"hqm".
Well, "Who am I if not hqm?", I wonder. Fortunately, unix
provides me with a Special Purpose Tool for answering just
this very question: I type "whoami" to a shell and I'm told
"hqm". (Little known Fun Unix Fact: "who am i" will also
tell you; unfortunately "what rough beast" only manages
"can't open rough (26) / can't open beast (26)" which
somehow lacks the cadence of TS WHAT's reply.) So I'm "hqm"
but I can't edit files because hqm has them locked. Well,
you long-time sufferers know what's coming next: it turns
out that although I'm "hqm" I'm not -really- "hqm" ("quick:
is this a regular expression or a regular expression...")
but actually somebody pretending to be "root" pretending to
be "hqm". Oh crafty Unix, to have seen through the veils of
my deception! (Incidentally, I asked "who am i really" but
was told nothing of any use.) So to be truly one with Henry
I must telnet to my own machine and log in as him, and then
Emacs.
But I didn't come here to talk about "su" and "who ?am ?i"
(aka "who*am*i"), I want to tell you about what happened as
the result of being Henry (not just -pretending- to be Henry
in such a way that everything but RCS appeared to work, mind
you, but really, truly being actual hqm) and the files "he"
wrote into my home directory.
At this point I could tell you about the fact that there are
really two hqm's with different user-ids, and how the former
one works with AFS and the latter doesn't and how the System
Administration Cretins at PARC turned off mail forwarding
from the former to the latter as a service to their user
community, but this isn't the place for that.
So, I have these two files sitting in my directory named
"oxds-trace" and "nxds-trace" and I need to perform a really
hairy comparison upon them. The reason the comparison is
complicated is that these two files contain voluminous
dumpings of the internal state of an interpreter engine (I'm
trying to find what I've done to make it no longer work) and
of course about the only thing you can print in a typical C
program is the hexadecimal address of objects in memory,
which of course changed wildly when I relinked the program.
I spend a couple of hours writing a medium-hairy Emacs
function which compares two buffers, globally changing any
"0xdeadbeef"-type string at which a mismatch occurs into the
same "#:G00259" identity-preserving token in both buffers so
that I can look for actual changes in the actual objects
being dealt with rather than for changes in the whims of the
virtual-address-assigner.
Now these two files are owned by "hqm" (remember him? --
he'd being doing development on my machine using my keyboard
and my hands for the last week, because I unable to bring
myself to do the foul RCS deed to which I eventually
resorted) and Emacs gets all stroppy about doing auto-saves
and about overwriting those files because I'm ("mly") not
"hqm" and I really shouldn't be pissing on his files (be
they written in a directory owned by "mly" or not.)
Eventually I get Sufficiently Sick of Emacs' complaints that
I do a stupid thing: rather than patch the emacs-lisp code
not to complain, I decide to fix the ownership of the files
so that they're really mine-all-mine. (At this point, one
may hear calls from the peanut gallery, cries of "Oh NOOO!
Don't do THAT!!")
Let's follow my little adventure in full shell-o-rama:
anonymous> ls -la *tr
-rw-r--r-- 1 hqm 1228179 Jan 15 18:07 nxds-tr
-rw-r--r-- 1 hqm 2814780 Jan 15 18:20 oxds-tr
First, I try to make the files writable by myself
anonymous>chmod u+wx nxds-tr oxds-tr
chmod: nxds-tr: Not owner
chmod: oxds-tr: Not owner
OK. That doesn't work. I'll try to make them owned by
myself.
anonymous>chown mly nxds-tr oxds-tr
chown: nxds-tr: Not owner
chown: oxds-tr: Not owner
I'm not allowed to do that? Perhaps I should try a bigger
hammer (actually, the -only- hammer -- the world looks like
one really big nail from here in unix-land)
anonymous>su
Password:
anonymous# chown mly nxds-tr oxds-tr
chown: nxds-tr: Not owner
chown: oxds-tr: Not owner
anonymous# whomai
root
Hmmm. Even though I'm all-powerful, I'm not powerful enough
to do a simple operation. (That's part of "NFS Not
Preserving [sacred] Unix Filesystem Sematics", and that's
another story.) But that's OK, I'm powerful enough to
become somebody less powerful who has power over the files.
anonymous# su hqm
"su hqm"? You'd think that I'd have learned that there's
"hqm" and then there's "hqm", but, golly gee, I don't seem
to have learned, do I?
Let's try again!
anonymous% whoami
hqm
anonymous% chown mly nxds-tr oxds-tr
Must be root to use chown
Ahhh... but I just -was- "root"... (and I was told that I
wasn't the owner.)
If I'd learned my lesson, and if I could remember what hqm's
password was, at this point I'd have telnetted to my own
machine and tried again, but I hadn't or I didn't want to or
I was tired of the whole mess.
anonymous% ls -la *tr
-rw-r--r-- 1 hqm 1228179 Jan 15 18:07 nxds-tr
-rw-r--r-- 1 hqm 2814780 Jan 15 18:20 oxds-tr
Well, at least the files are still there!
anonymous% exit
anonymous% anonymous# exit
anonymous# anonymous>whoami
mly
Back to mehood! I decided that the simplest thing to do is
to just copy the contents of the files (after all, I can
read them) to new files and just delete the old ones. ("Oh
NOOO! Don't do THAT!!") Now those who all just called out
"Oh NOOO! Don't do THAT!!" think that I'm about to type
something like "cp nxds-tr nxds-tr" or "cat nxds-tr >
nxds-tr" but I'm no unix neophyte -- I know about this
aspect of Unix Filesystem Semantics and know that NFS is
specially designed to NFS to Preserve that Semantic!! So I
rename the file first, before copying it.
For good measure, I decide to also copy the file to /tmp/,
in case my Emacs-lisp function runs amok and eats it all up.
anonymous>mv nxds-tr damn
anonymous>cp damn nxds-tr
anonymous>cp nxds-tr /tmp/o
These files are big, so rather than sitting around waiting
for the first copies to complete, I type-ahead commands to
copy "oxds-tr"; in fact, I use the same commands I used
above. ("Oh NOOO! Don't do THAT!!")
mv oxds-tr damn
cp damn oxds-tr
cp damn /tmp/o
anonymous>mv: replace `damn', overriding mode 0644? anonymous>
anonymous> anonymous>
Can you guess what happened to "oxds-trace"?
PS An even more useful unix command than "who am i" is
"yes".
From: ML
Date: Fri, 22 Jan 93 3:27:52 PST
Subject: Re: Another Day, Another Lost File
Such a sad story of unix lossage. I was screaming OH NOOO!
Don't DO THAT! right along with your comments. A few
months ago I learned the "don't use type-ahead" lesson:
I had this 50 megabyte host table I had just spent a week
gathering up from all corners of the world. I had to
process it a bit, munging out all the bogons and such.
Thing like:
nobogons < hosts > foo
mv foo hosts
I decided to try out the special feature of unix that
actually lets you type two commands on just one line. So
the next commands I did were:
sort < hosts > foo; mv foo hosts
I guess unix was never meant for repeatedly processing the
same file and creating new versions of it. On Tops-20 I
woulda just outputted the result to the next generation of
the same file.
Of course, sort died because /tmp filled up with temporary
sort garbage. But before it died, it wrote out a few
megabytes into foo, thinking that I might be happy with at
least a partial sort.
But on *my* version of unix, mv doesn't ask you the nice
question about overiding an 0644. It just goes and does it.
For some reason, I thought that because I typed two commands
on the same line, the second wouldn't happen if the first
died.
Oh well, who needs a 50 megabyte host table anyways.
From: JL
Date: Fri, 22 Jan 93 09:05:01 EDT
Subject: Linguistics
[From the tail end of an unrelated posting:]
>excuse the crudeness of this posting; i'm on a unix-V
>system and using vi (evidently, this is where they get the
>expression about 'deep sixing a file'...)
From: DH
Date: Mon, 25 Jan 93 01:33:20 EST
Subject: Take A Dump -- Please!
This ancient message came back to haunt me this evening. I
forward it with but one observation: if even unix's big fans
think unix drivers are lame...
Date: Mon, 19 Oct 92 18:21:31 -0700
From:
[email protected]
Subject: Re: dump parameters
> Perhaps, since you're going to a pipe rather than a tape,
> dump is not doing the length calculation at all?
Dump's tape calculations are arcane and completely obsolete.
You just have to fake it out, and experiment with the
numbers until you get something you like.
Dump always does the length calculation, to pipes or
anyplace else.
The right fix is for dump to notice when it gets EOF writing
to the tape, and change tapes at that point. That would be
too intelligent for Unix tape drivers to support, though.
From: AB
Date: Thu, 28 Jan 93 01:08:38 -0500
Subject: ^S/^Q/^O
It has just dawned on me that Unix is eventually going to
drive me stark raving bonkers crazy. I am -not-
exaggerating -- I truly believe that the only possible
outcome of my having to use this piece of shite environment
for a few more years is a padded cell. I mean how many
times do I have to suffer throught the same set of bugs
screwing me over in the same old way with no end in sight?
Tonight, in the course of just trying to get some gd work
done I discovered that if I use DEC's telnet program to
connect to Sun's telnet server, then I'm not allowed to type
^S, ^Q or ^O. I thought we stomped out all forms of this
lossage ten years ago.
All I want to do is search through a file for a particular
string -- and I'd like to use Gnu emacs -- but I can't type
^S can I? So now I am totally pissed off at the way Unix
and the total clown programmers it creates can make any
simple task into a trip through frustration hell. Something
that I could have accomplished in 5 minutes takes half an
hour (longer if I take time out to send a flame to
Unix-Haters) and raises my blood pressure in the process.
How hard can it be to write a telnet program that just gets
out of your way and lets a remote computer talk to your
terminal? We're not talking SUPDUP here (a wonderful
protocol that actually -did- -something- -useful-) but its
cousin TELNET -- the village idiot of remote terminal
protocols. Think about it: this telnet program has to
actually make a -special- -effort- to get in my way like
this! Some Bozo probably spent days designing this
particular misfeature. He probably worked late nights
trying hard to get it -just- -right-. What a worthless
little weenie.
Of course the Meta key doesn't work either, but it never
works no matter -where- I telnet too, so I've learned not to
expect it, but this ^S/^Q/^O lossage only happens when
telnetting to a Sun, so it always comes as a painful
surprise.
[ And don't anyone -dare- tell me about the Gnu emacs kludge
that lets you totally re-map your keyboard -- I know, I
know... ]
From: CM
Date: Thu, 28 Jan 93 02:42:41 EST
Subject: find'ing Bogons
I have this NeXT machine at home. As far as Unix boxes go,
it doesn't suck. In fact, it's not too bad since NeXT
decided to bag standards and go for useability. Hell, they
even bagged that motherhood concept of user configurability
so that all next machines would have a consistent interface.
("You may only use the state-mandated key and mouse
bindings. Anyone caught with unapproved key bindings will
be shot.")
For some reason, the disk goes crazy at 2am every night. It
turns out there is this find command that looks through the
entire file system for files named .nfs* and deletes them.
No trial. Instant death. And never mind that I don't run
nfs, or even a network for that matter. You never know
where these things can pop up.
So I got a nifty new cd-rom drive. It lets me keep 600MB of
information online. Some say it's the biggest happening
since the Gutenberg press. Anyhow, here it is 2:28 am and
the cd-rom is cranking away.
Yep, find is looking for those pesky .nfs bogons on my
cd-rom so it can try and delete them. Sort of like a dog
chasing a car; you wonder what it will do if it catches it.
Anyhow, you would think the person that wrote this would
have used a little more common sense. After all, the
/etc/mtab clearly says the cd-rom is mounted read-only. I
mean what could be clearer than the old /etc/mtab file:
/private/vm/swapfile "/private/vm/swapfile.front" swapfs rw 1 2
/dev/sd0a "/" 4.3 rw,noquota,noauto 0 1
/dev/rsd1h "/BSD386_GAMMA4" cfs ro,removable,filesystem=CDROM 1 2
See that "ro"? That means "read-only". I think. And those
numbers must mean something really important.
That's what I like about unix. All the crucial information
in easy to use configuration files makes system
administration a snap. Why you can even edit them with vi!
From: PB
Date: Thu, 28 Jan 93 13:31:51 EST
Subject: Re: ^S/^Q/^O
try "rlogin" -- "it's not a protocol, it's a program".
Some versions may have a '-8' option that may (or may not)
pass the meta bit.
What bothers me even more than how broken things are
compared to ten years ago, but how fast things seem to be
getting more broken.. Maybe it has something to do with the
baby boom.
From: AB
Date: Thu, 28 Jan 93 14:35:03 -0500
Subject: Re: ^S/^Q/^O
Date: Thu, 28 Jan 93 13:31:51 EST
From: PB
try "rlogin" -- "it's not a protocol, it's a program".
Some versions may have a '-8' option that may (or may
not) pass the meta bit.
You think I don't know about rlogin? Hell, I can tell you
things about rlogin and Kerberos that will make your hair
stand on end.
What bothers me even more than how broken things are
compared to ten years ago, but how fast things seem to
be getting more broken.. Maybe it has something to do
with the baby boom.
Not good enough. You have 48 hours to compose a better
flame about Unix or your subscription to Unix-Haters is
history.
From: DW
Date: Thu, 28 Jan 93 18:10:30 EST
Subject: Approved key bindings
From: CM
Date: Thu, 28 Jan 93 02:42:41 EST
("You may only use the state-mandated key and mouse
bindings. Anyone caught with unapproved key bindings
will be shot.")
Speaking of which, it seems that the "delete" key is
drifting farther and farther out of reachable range as Sun
Microsystems comes out with "newer" and more "improved"
keyboards. The latest one, on which my fingers currently
have the misfortune to be attempting to type (despite the
lack of any decent tactile feedback), has a delete key that
isn't even part of the main array of keys; it's off in a
little separate group, with other "word processing" commands
(Sun aspiring to be Wang), separated by some empty space. I
presume that if I live long enough to be forced to use their
next model, delete will be located somewhere behind the
monitor.
From: AB
Date: Thu, 28 Jan 93 15:35:09 PST
Subject: Re: ^S/^Q
It's not Unix's fault, it's entirely DEC braindamage. Ever
notice how the "stty decctlq" mode works?
Ugh.
You can trace it back to the VT50 terminal, rapidly
followed-on with the VT52 and VT100 series of terminals.
DEC, in its infinite wisdom, decided that scrolling the gd
screen was more important than servicing incoming characters
from the serial port. What to do when you're scrolling and
a character comes in? Why send a ^S down the line, of
course! And if the silly user has set the "Don't send
^S/^Q" bit? Why, just throw away the characters until
you're done scrolling and put in a backwards question mark
instead. AUGH! What pieces of shite! And the next worse
thing is that everyone else decided that this was OK
behavior and decided to emulate it when they built their own
"smart" terminals.
Give me my ADM3a back, or give me death!
From: AB
Date: Thu, 28 Jan 93 15:49:06 PST
Subject: Re: ^S/^Q/^O/^C/^....
There are a number of contribution factors as to why AB is
seeing this behavior.
1. Is that it has been only recently that the Telnet RFC has
been amended to allow the local system to do flow control
and process special characters locally.
2. Most lusers are still mentally dependant on printing
terminals, exhibited by personal computer communication
programs and window system terminal emulators such as xterm
and sun-cmd windows in sunstools that emulate a
near-infinite roll of paper.
3. In order to compensate for faster and faster computers
and their networks buffering up larger amount of output for
people to read, many Telnet implementations process "common"
characters, as everyone uses them in the same manner and
merely sends various embedded commands to the remote Telnet
server. After all, if you type ^S, you really do mean to
stop output on your local terminal, not actually have it
mean a command of some sort to the remote system, no?
The latter is on a par with the GNU community's bigotry in
calling ^H a help character in emacs and forcing you to use
^U as a line erase character in gdb/bash, all regardless of
what your terminal editing characters are set to before you
enter the program.
From: DW
Date: Thu, 28 Jan 93 23:41:21 EST
Subject: Unix-Haters Was Right All Along.
Naturally, emergencies always materialize themselves in the
days just before you have scheduled a vacation. Late on the
day before I was about to leave, I wanted to do one more run
of a benchmark experiment that takes about half an hour to
run. So I start this thing up, and come back after about a
half an hour with a colleague so we can see what the results
are. What do we see? "Segmentation violation". Oh,
thanks. I've been running this program all day, and have
only made one slight change to it, and the program bombs,
telling me nothing useful, after half an hour. This is a
client-server situation, so I have to tie up two machines
for a half an hour each time.
So I decide to try to figure out what's wrong. Now, if I
had been paying attention to Unix-Haters the way I ought to,
I would have known all along that this was Futile and
reflected a Bad Attitude. But I went ahead as if I were
using a real computer. I ran the program under gdb. After
the half-hour wait, gdb says (I can't remember the precise
words of this message but I've seen it before) "Illegal
memory reference. Inferior process no longer exists."
I.e., no useful information whatsoever.
I try once more. I run under gdb, and periodically
interrupt the program, so I can at least get a lower bound
on where the problem is. I do this for a while. Then it
stops responding to my control-C's. I soon discover that
it's not responding to anything, in any window. Soon after
that I find that none of the workstations all the way down
the hall are responding to anything! Everyone's trying to
figure out what's going on. The most usual suspects are the
servers, but they're all up. We quickly determine that the
Ethernet is saturated. Someone with a PC (when you want to
do a real job, you don't turn to Unix) analyzes the packets:
lo and behold there is a swarm of UDP packets between my two
machines. Now everyone's telling everyone else "Oh, this is
all Dan's fault!"
The theory quickly arrived at was that one of the machine is
doing a core dump onto a directory NFS-mounted onto the
other machine. There's no way to tell, of course, since
everything is totally wedged. At this point I had had
enough. I just powered down one of my machines. Everyone
else's machine duly resumed its wretched Unix existence.
The kind thing to do would be to leave that machine powered
down, and maybe power down some more. Unixthenasia.
All along Unix-Haters has been telling me that if I try to
make things Better, I will just be Punished. I fully expect
that if I try once more to find this problem, Unix will find
a way to wipe every hard disk owned by the company, and then
we'll learn all about bugs in the tape backup software that
caused all our tapes to contain nothing but a zillion copies
of the root's .login file. Unix-Haters was right all along.
From: AB
Date: Thu, 28 Jan 93 23:46:38 -0500
Subject: Re: ^S/^Q
Date: Thu, 28 Jan 93 15:35:09 PST
From: AB
It's not Unix's fault, it's entirely DEC braindamage....
WWHHAATT!! Of course it's Unix's fault! What is this, some
kind of contest to see how far you can push me? Can't you
see from my bloodshot bulging eyeballs that I've -had- -it-
with this kind of namby-pamby apologist rationalizing stuff?
There wasn't one even -remotely- negative thing about Unix
anywhere in this message. You know the rules: you have been
flushed from Unix-Haters.
- AB
(Pardon me while I wipe the spittle from the screen of my
ADM3a...)
From: RT
Date: Fri, 29 Jan 93 12:29:56 GMT
Subject: Re: Approved Key Bindings
> The latest one, on which my fingers currently have the
> misfortune to be attempting to type (despite the lack of
> any decent tactile feedback), has a delete key that isn't
> even part of the main array of keys; it's off in a little
> separate group, with other "word processing" commands (Sun
> aspiring to be Wang), separated by some empty space.
It's worse than that, they're aspiring to be IBM
clone-makers.
Observe the completely useless keys marked "scroll lock",
"print screen", and "F12". And this is the so-called "unix
keyboard" which we eventually persuaded them to send us to
replace what's laughingly referred to as the "UK keyboard".
What are the keys that look as if they should be on a TV
remote control? Maybe they do something under "open"
windows, but I've no plans to ever find out. My Sun
keyboard has 119 keys, of which I use less than half. I was
tempted to saw off everything to the left [right?] of the
return key, but instead I've mapped all 34 of them to
delete.
Soon they'll be be providing miniature screens with some
absurdly low resolution - oh, they already do that. Maybe
they should get rid of Sparcs and use those nice Intel
processors instead.
Sun-2s had nice keyboards. Every one Sun has made since
then has been worse than the one before.
From: SM
Date: Fri, 29 Jan 1993 10:24-0500
Subject: Approved Key Bindings
Date: Thu, 28 Jan 1993 18:10 EST
From: DW
From: CM
Date: Thu, 28 Jan 93 02:42:41 EST
("You may only use the state-mandated key and mouse
bindings. Anyone caught with unapproved key
bindings will be shot.")
Speaking of which, it seems that the "delete" key is
drifting farther and farther out of reachable range as
Sun Microsystems comes out with "newer" and more
"improved" keyboards. The latest one, on which my
fingers currently have the misfortune to be attempting
to type (despite the lack of any decent tactile
feedback), has a delete key that isn't even part of the
main array of keys; it's off in a little separate
group, with other "word processing" commands (Sun
aspiring to be Wang), separated by some empty space. I
presume that if I live long enough to be forced to use
their next model, delete will be located somewhere
behind the monitor.
Geez, so what's your problem, DW? Anybody who isn't a
perfect typist should obviously be punished.
From: MF
Date: Fri, 29 Jan 1993 13:19:17 -0500
Subject: Approved Key Bindings
** Geez, so what's your problem, Dan? Anybody who isn't a
** perfect typist should obviously be punished.
Keys? Typing? Oh yeah, that's what people used to do before
mice were invented.
From: MR
Date: Fri, 29 Jan 93 13:32:29 EST
Subject: Medical Proof That Exposure To UNIX Rots The Brain!!!
I've removed the name from this, because I don't want to
single this unfortunate victim of UNIXitis out for
ridicule. It's a painful and debilitating disease and we
need to be sympathetic of the poor drooling wreckage it
leaves in its $PATH.
>Newsgroups: comp.unix.ultrix
>Subject: Re: Unaligned access in the X server.
>
>
>First question you need to answer for yourself is, Do you
>have the source to this application? If so then recompile
>it, or run it through dbx and locate where the error is
>located, and fix it. If not then complaint to the VENDOR.
This is what's wrong with UNIX and this is one
reason why UNIX has sucked for 20 years and resolutely
continues to suck. There are people out there (like this
guy) who TRULY BELIEVE that an appropriate response to
buying software that's buggier than a manhattan flophouse is
to FIX IT HIMSELF rather than to insist that the vendor fix
it!!
Note how the patient lists "complain to the vendor"
as the final resort. This is because with UNIX vendors and
THE OPEN SYSTEMS PHILOSOPHY it is WRONG to sell something
BUG FREE. Something that actually WORKS IS PROPRIETARY and
therefore it is BAD!
UNIX is a "do it yourself" operating system because
the folks who sell it generally have little to no experience
in creating robust commercial quality environments. This is
what happens when ex college hackers and computer scientists
become managers of vendor software departments. As much as
most reasonable people hate Microsoft Windows it has the big
advantage that IF SOMETHING IS BROKEN YOU CAN'T FIX IT!
That means that customers call and BITCH and COMPLAIN. With
UNIX if you call a vendor and say "my oi command is
broken"(*) They usually start a dialog that goes like this:
Customer: I run "oi -c -f -q /dev/fratz -t -m=5" and
I get a segmentation fault. Can I get a working version of
your piece of shite operating system, please?
Support: Hmmm.... That's a pretty serious
problem. We're aware of that - it's SPR#2322, filed in 1985
- we'll have it fixed in the next release.
Customer: HEY! But I need it to work NOW! And I have
a software service contract [rustles papers at telephone]
that says you guys provide bug fixes. I want a version of
"oi(1)" with the working "-q /dev/fratz" option!!
Support: [thinks] Do you have GNUemacs installed on
your system?
Customer: Huh? Yeah, why?
Support: Darn. Sorry. I hate to tell you this but
the minute you installed unqualified third party software,
you voided your software warranty. Your system is now in an
"UNSUPPORTED CONFIGURATION" which means we can't even give
you the time of day unless you present a letter from The
Pope.
Customer: AUuuGHHGHGHGHH!!! BUT - BUT!!! But what
about "Open Systems"!!!?!?!? I'll take my business to your
competitors!
Support: No problem, but I think it's only fair to
inform you that most UNIX vendors now have a clause in the
support contracts that if you've ever even TOUCHED another
vendor's system, that your BRAIN is in an "UNSUPPORTED
CONFIGURATION" and they'll tell you to call us.
Customer: *whimper* - but - I gotta have my UNIX....
Support: Well, since you're already in an
"UNSUPPORTED CONFIGURATION" maybe you can grab the GNUoi
sources off the net and build a version that works? Great
idea, huh?
Customer: [enthusiastic] Yeah! I'll do that! Gosh! I
can fix things myself when they're broken! Isn't UNIX
GREAT!?! [Hangs up the phone]
That's the first sign of advanced UNIXitis. The next
one is that the victim wants X-Windows running on everything
in sight, but X-Windows syndrome, its symptoms, and cure
(napalm) are the topic of another discussion.
"oi(1)" is a nonexistent UNIX command with a 2-letter name used
for this example because the 2-letter name was terse and saved
me a keystroke, which I then wasted many times over for this
explanation.
From: WW
Date: Fri, 29 Jan 93 11:25:02 PST
Subject: Re: Approved Key Bindings
Speaking of which, it seems that the "delete" key is
drifting farther and farther out of reachable range as Sun
Microsystems comes out with "newer" and more "improved"
keyboards.
Well of course! It's like the escape key on PC keyboards.
Since "delete" interrupts the process (which then
disappears), it's a very dangerous key, and SHOULD be far
away. Haven't you also noticed that the "#" key keeps
getting more convenient? Since this is the standard key for
editing command lines and fixing typing errors, it NEEDS to
be convenient...
This is just the HW people FINALLY catching up with
practices that have been unix standards for DECADES!
From: AB
Date: Fri, 29 Jan 93 15:55:07 -0500
Subject: Re: Approved Key Bindings
From: MF
Date: Fri, 29 Jan 1993 13:19:17 -0500
Keys? Typing? Oh yeah, that's what people used to do
before mice were invented.
This might be a reasonable message for Macintosh-Haters, but
I don't see where there is anything to hate about -Unix- in
particular in this message.
Your subscription to Unix-Haters has been terminated.
Let me remind everybody of what I think is a good rule of
thumb for this list: If you are composing mail to
Unix-Haters, and you stared with the "reply" command (you
typed "r" in emacs rmail mode), then stop right there, your
message probably doesn't belong here. Read my lips.
From: JD
Date: Fri, 29 Jan 1993 16:24:10 -0500
Subject: One liners
Someone on alt.folklore.computers is soliciting eunix
related one-liners for use on some t-shirts. Unfortunately,
some of the SUN-struck heathen are actually suggesting text
that could be construed as POSITIVE bletch!. I am sure that
the readers of this list can provide some less biased, more
accurate and more entertaining quotes.
Apparently this is a semi-commercial effort, so any
selected will result in a donation to a charity of the
suggestors choice..... I am willing to collect the results,
and pass them on to the enterprise. Here is our chance to
correct the publics unfortunate delusion that eunix is a
useable tool...
From: DM
Date: Sat, 30 Jan 93 18:52:09 EST
Subject: Re: One Liners
Here are my suggestions:
"Well, at least it's better than MS-DOS"
("NOT" printed on the back)
"At least it used to boot fast"
"My other computer runs a real operating system"
"Don't laugh, it's open"
"Unix : Computer Science :: MTV : Grand Opera"
"Unix - fat, smarmy, and useless" (too subtle?)
"Six-character file names were never this bad" (too esoteric?)
"Fourteen-character file names were never this bad" (too subtle?)
(Well now that I think of it the fourteen character file name file
system really was that bad! I mean, it didn't begin to work! But
in those days one could still say "simple and elegant" and not mean
it sarcastically. I remember reading the entire source code of Unix
in an afternoon and understanding it too. Hell, if I start waxing
nostalgic for Unix AB is certainly going to have to kick me off this
mailing list, and that would be a blow that I would never recover
from. Gohd D4MN the syphilis infested shite eating unix mailer
from hell with lice for BRAINS that can't keep its VILE perverted hands
from inserting greater thans in FRONT of the last three LINES. There,
that should keep me on the mailing list!)
But what you really want is a graphic showing Wayne of
Wayne's World reinventing the wheel, but making it out of
marshmallow and triangular, and putting nine wheels on one
side of the car and one wheel on the other side, with a
damning-with-loud-praise caption such as "Unix - tomorrow's
technology today".
Or a "descent of man" picture with the upright muscular man,
the bent-over fellow, the degenerate wretch, and so on down
to the capering ape, labelled with "golden age", "silver
age", "iron age", "tin age", "plastic age", "cardboard age",
down to "Unix age".
From: RS
Date: Mon, 1 Feb 1993 11:54:38 -0500
Subject: Re: ^S/^Q
> From: AB
> Date: Thu, 28 Jan 93 15:35:09 PST
> Subject: ^S/^Q
I just got this message this morning. Thank You, O great
MMDF, for finally deigning me worthy of receiving this piece
of mail that was sent almost 5 DAYS AGO! I received AB's
reply *DAYS* before I got the original message! Why am I
expected to tolerate this kind of nonsense, and why are we
running a mailer on MC which can't even process a queue
properly?
piece 'o shite...
By the way, AB, about that telnet thing... be glad you
aren't on a SCO box. Ask for telnet, get rlogin. Awfully
unnerving to type "telnet foobar" and instead of a "login:"
prompt, get a "password:". Makes you wonder what would
happen if you tried to telnet to a twenex or a multics, or
something else that didn't support rlogin... chalk another
one up for the Spoiled Child Operation.
From: LK
Date: Mon, 1 Feb 1993 11:06:26 PST
Subject: Re: Take A Dump -- Please!
Back at Terrapin we wanted a Sun 2, but they had a 90-day
lead time, so we bought a QBUS based 68010 Unix system with
a Quantum reel tape drive. Its main advantage, besides
being the only other systerm with virtual memory, was that
we could just buy RS232 boards and such at Eli's, because it
was QBUS.
Anyway, dump never quite worked right. It would dump for
about half an hour, then get an EOT error, and then we'd
have to reboot the machine to make it work again.
Eventually, the Company (hopefully long since deceased) told
us to use the "-s " argument to tell the tape drive that the
tape was shorter than 2400 feet. This pretty much fixed
things, unless we forgot and had to boot the machine.
Next, we noticed our Vadic 1200 baud modem wasn't working
right. If we fiddled with the switches and made it accept
up to 1215 baud, it started working. Come to think of it,
we'd always had trouble with the clock being wrong.
Well folks, we complained of these problems to the Company,
and they fixed things by sending us a new CPU with a
slightly slower clock speed.
From: WW
Date: Mon, 1 Feb 93 13:05:38 PST
Subject: Re: ^S/^Q/^O
What bothers me even more than how broken things are
compared to ten years ago, but how fast things seem to
be getting more broken.. Maybe it has something to do
with the baby boom.
Nah, there is just more. The same exact things that were
broken 10 years ago ARE STILL BROKEN. This is a major
problem in itself...
Unix weenies have been busy making new broken software
instead of fixing the old broken software.
Sigh.
From: MR
Date: Mon, 1 Feb 93 16:17:10 EST
Subject: Re: One liners
I think RP said it best: "UNIX is not only dead -
it's starting to smell bad"
From: AB
Date: Tue, 2 Feb 93 01:33:56 -0500
Subject: Re: One liners
Date: Mon, 1 Feb 93 16:17:10 EST
From: MR
I think RP said it best: "UNIX is not only dead - it's
starting to smell bad"
"MS-DOS is not only dead - it's starting to smell bad"
Sorry, there is nothing in your message about Unix. I can
plug the name of -anything- I dislike into the phrase:
"<blank> is not only dead - it's starting to smell bad"
What, you're trying to tell me that the fact that RP said it
makes this quote special? Since I can barely remember who
RP is, I'm not impressed.
Oh, this was intended to answer the call for good
one-liners? So you were -replying- to someone else's
message? DIDN'T I TELL YOU THAT WAS DANGEROUS?
Furthermore, this is the jillionth marginal message to
Unix-Haters today. Someone mentioned to me today that
they've stopped really reading Unix-Haters because the
quality to volume ratio is so low, they just hit the delete
key -- well perhaps we need to make some more examples.
*sigh*
You just lost your subscription.
From: JW
Date: Tue, 2 Feb 93 03:16:29 -0500
Subject: Re: ^S/^Q
From: RS
X-Mailer: InterCon TCP/Connect II 1.1b34
What is this - you're flaming about unix from a -Macintosh-?
Talk about the pot calling the kettle black. Oh, sorry,
wrong list.
I just got this message this morning. Thank You, O
great MMDF, for finally deigning me worthy of receiving
this piece of mail that was sent almost 5 DAYS AGO! I
received AB's reply *DAYS* before I got the original
message! Why am I expected to tolerate this kind of
nonsense, and why are we running a mailer on MC which
can't even process a queue properly?
piece 'o shite...
Now this just won't do. MMDF is a perfectly reasonable
mailer, and in fact is a hell of a lot better at managing
queues than sendma.. sendmai.. sendm... sendmai..
ssssssendmai... Gawdawmit, can't do it.
Ever notice how most unices, the ones that don't use MMDF,
often send you half-complete messages? Ever wonder where all
those lost bits GO??
But the point of this is that it really hasn't got much to
do with MMDF, it has to do with unix itself. The problem,
see, is that the machine you mention, MC, is only a poor
little Microvax 3, with probably only 16Mb of memory. Which,
you would think, would be perfectly adequate to run a mailer
and a filesystem. And it would have been, too, except that
the nice helpful people who brought you unix invented this
thing called the "fork", which they then proceeded to stick
- um, sorry, about to get a little carried away, there.
But anyway, see, by employing the great unix principle of
"composable functionality", they were able to determine that
even though 99.9997 percent of the time you create a new
process you are -going to use it to run a new program-, it
would be a Good Thing to separate the notion of creating a
new process from the notion of stuffing the new program you
wanted to run into its address space.
Now, if you were going to do that, you might at least think
that you could arrange some kludge to optimize the common
case.(1) But no, that would be -messy-, and unix is not
-messy-. So, kids, the way we run a program here is to use
is the "fork" system call, which takes a running program,
makes a new process, and -copies (and I mean -copies-, as in
moves bits around on the disk), the entire address space of
the old program into the new one-, followed, 99.9997 percent
of the time, by the "exec" system call, which takes the
newly copied bits and -instantaneously throws them all
away-.
And that's why MMDF is slow.
(1) And you bloody well could, too, if you were from
California. Just forget about that for now, OK?
From: HA
Date: Tue, 2 Feb 93 08:06:26 -0500
Subject: Re: One liners
Date: Mon, 1 Feb 93 16:17:10 EST
From: MR
I think RP said it best: "UNIX is not only dead - it's
starting to smell bad"
Aha! That explains why his new system is called Plan 9 from
Bell Labs.
The original Plan 9 from Outer Space was a fiendish alien
plot to take over the earth using an army of resurrected
corpses (who were not only dead but were starting to smell
bad).
We'd better watch out.
From: DW
Date: Tue, 2 Feb 93 08:50:45 EST
Subject: Re: ^S/^Q/^O
Date: Mon, 1 Feb 93 13:05:38 PST
From: WW
Nah, there is just more. The same exact things that
were broken 10 years ago ARE STILL BROKEN. This is a
major problem in itself...
Unix weenies have been busy making new broken software
instead of fixing the old broken software.
Worse yet, even when something gets "fixed", that just means
that one version of Unix has an old bug while another
version of Unix has a new bug, and we have to conditionalize
all our software EVEN MORE in order to make it work. So
with Unix, even IMPROVEMENTS are BUGS! There must be a
special circle of hell for this.
From: AM
MMDF-Warning: Parse error in original version of preceding line at mc.eve.rcl.ear
Date: Tue, 2 Feb 93 22:09:54 MST
Subject: Grrr.
I sent off this little rant about how stupid Unix is
about device drivers to unix-haters-request, and got back
this snotty little note about how it was misdirected and
here's a copy back and if you think it's worthy, send direct
to unix-haters.
Well. Like a bolt out of the blue it came to me that
it wasn't really Unix I hated, it's those Unix users. They
think just because they've mastered a few of the bizarre
incantations for their brand of Unix, they get to be snide
to everyone who's missing one of their incantations.
Ever asked a guru-wannabee how to do something?
They invariably look at you like you're an alien. I got NEWS
for you bozos, just because you know how to make your STUPID
little toy OS beep and burble happily doesn't make you a
GOD. I know you're way too busy reading news to help me work
around all the shite you've broken on your stupid little
box, but at least lose the stupid attitude.
Gd useless hippies.
Oh yeah, subscribe me to this list, you useless
twerps. If you can remember HOW, in your no doubt
drug-induced haze.
From: AB
Date: Wed, 3 Feb 93 03:57:29 -0500
Subject: When It Rains, It Pours
Date: Tue, 2 Feb 93 22:09:54 MST
From: AM
I sent off this little rant about how stupid Unix is
about device drivers to unix-haters-request, and got
back this snotty little note...
Gd useless hippies.
Oh yeah, subscribe me to this list, you useless twerps.
If you can remember HOW, in your no doubt drug-induced
haze.
Since I doubt people will be able to control themselves from
responding to this jerk, and because the resulting flame war
will probably spill over onto Unix-Haters, and since we've
already had a lot of useless noise recently, I'm going to
shut Unix-Haters off after I send out this message.
I'll let you know when we're back on the air. Bye for now.
- AB
From: DM
Date: Fri, 12 Mar 93 18:45:44 -0500
Subject: The Emperor of China
Section 30.02 of _Unix Power Tools_ by O'Reilly & Associates says
... /ispell/, originally written by Pace Willison ...
but hey, I was there when Pace ported the ITS SPELL program
to C. Sure I am grateful to have a few reminders (^Z is
another one) of bygone glories around, but let's give credit
where credit is due! Legend tells of a Chinese Emperor who
ordered books burned so all knowledge would be credited to
his reign. I guess the subsequent generation of scholars
were a lot like the Weenix Unies of today.
From: PD
X-Mailer: PP/Ream v4.16d (The Choice for a New Generation)
X-Subliminal-Message: Send me all your thesis ideas
Date: Wed, 24 Mar 93 14:42:59 +0000
Subject: [Fwd: Something's Badly Wrong]
This isn't very specific but, God, it was just that
realisation *again* that the ultimate computer viruses are
moving us backwards rather than forwards...
---- Start of forwarded text ----
From: PD
Date: Wed, 24 Mar 93 11:31:47 +0000
Subject: Something's Badly Wrong
Danny Bobrow, Ron Kaplan, Larry Masinter (all at PARC),
Richard Burton, Peter Deutsch and Warren Teitelman (all
ex-PARC) are to be awarded that ACM's Computer and
Information Processing Software System Award. Why? For the
development of Interlisp, and its facilities such as
integrated compiler and interpreter, source level debugging,
structure editing, graphical user interface integration,
automatic change management and analysis and profiling
tools. The generic description of the award describes how
the recipients will have had a lasting influence on the
development of software systems.
I wish. Now I write programs in C and C++ (ok, sometimes
Lisp when I'm lucky) using emacs on a window system set up
to look like ten hardcopy terminals at once. Since the
address space is rudely split, non-intrustive profiling
tools are just impossible, but fortunately we don't have the
integration in the environment to make them work anyway. I
do storage management by hand. I am aware of the difference
betwen -O2 and -O4 because Sun (and no-one else) can write a
compiler which optimises properly. I put printfs in my code
in order to trace it. The closest I can come to an
all-purpose User Interface Management Systems is emacs.
What is the lasting influence of Interlisp? It is that,
almost twenty years since it was developed... and even
though the current implementation is still a byte-code
emulator for the Dorado's instruction set... still, after
all this, I bloody wish I was still using it.
---- End of forwarded text ----
From: RA
Date: Thu, 25 Mar 93 1:22:35 EST
Subject: It's Not Just New Jersey That's The Problem
From: CD
Date: 23 Mar 93 16:46:09
Subject: Re: Patch For bin/rm/rm.c
In an article DF writes:
>I'm not sure if this is the way it's supposed
>to work.
that is the correct behavior for rmdir.
rmdir foo/
is equivalent to
rmdir foo/.
which, it should be obvious is an impossibility; you can't
delete a dir that you're holding busy, and you "enter" it
with the trailing /.
From: AW
Date: Thu, 25 Mar 1993 02:51:23 -0500
Subject: That's Not A Feature, That's A Bug.
> which, it should be obvious is an impossibility; you can't
> delete a dir that you're holding busy, and you "enter" it
> with the trailing /.
It's only impossible if you're a UNIX kernel, and don't have
the brains to realize that once namei() has resolved the
name to an inode, you're done looking in the directory and
can thus remove it without actually sawing off the branch
you're standing on.
The UNIX philosophy is to prevent you from shooting yourself
in the foot, but only if the gun is unloaded.
From: AB
Date: Sat, 3 Apr 93 21:42:26 -0500
Subject: Out Of Disk Space, So I Zeroed Your File...
From: DW
Date: Sat, 3 Apr 93 13:52:55 EST
To: ...,
[email protected], ...
I've temporarily fixed the problem on all of the servers
except for random1. The .envrc file was modified
yesterday, to change how the path was set....
[ Explanation omitted. ]
*** I have totally screwed up random1. *** There's no
space left on the disk, so when I tried to write to
.envrc it got zeroed out. If anyone knows why it's out
of disk space, please feel free to do the right thing.
You might think that on the operating system favored by
academic computer scientists there would be a reasonable
mechanism in place to update files as an atomic operation.
Some of you may be lucky enough to recall that ITS had the
RENMWO (rename while open) system call, which most programs
actually used. The idea was fairly simple, when a program
(say TECO) wanted to write a file, it opened an output
channel to a file with a funny name like "AB;_TECO_
OUTPUT". Then it wrote out the proposed new file contents
to that file. After it was satisfied that the contents were
correct, the program used RENMWO to rename the still open
file to the correct final name, say "AB;UNIX HATERS",
simultaneously deleting any old file with that name. If
something went wrong -- the system ran out of disk space, or
the program crashed, or ITS itself crashed -- the worst that
would happen is that the user might find a file named
"_TECO_ OUTPUT" on his or her directory. Simple, safe.
Most users were dimly aware of this mechanism, at least in
as much as they would occasionally have to delete a file
with a funny name from their directory. And let me
emphasize that this was a fairly common occurrence. On any
given day, poking around the file system, you could almost
always count on finding one or two of these files. Each one
evidence that something had gone wrong, but that use of
RENMWO had saved the user from corrupting any previous
version of the file.
But what do we do on Unix? Well, first we open the file for
output using the O_TRUNC flag, which means that the old bits
are gone for good before we even begin to write out the new
ones. No disk space? Program bug? Operating system crash?
Tough luck. (Sure, there are things that a Unix program
-can- do along the lines of RENMWO. Perhaps even use the
rename(2) system call. But a zillion little things make
this incredibly inconvenient in practice. Like, suppose the
user doesn't have write access in the containing directory?
Or suppose we want to preserve the original owner of the
file?)
So the question arises, if this situation happened once or
twice a day on a typical ITS machine, where a safety
mechanism prevented it from doing any damage, why doesn't
the lack of such a safety measure screw Unix users all the
time?
Well, part of the answer is that is -does- screw Unix users,
at least occasionally. Witness DW's message above. I've
been bitten too. (I once zeroed out the password file on a
machine I was using this way, and boy did I think carefully
about what to do next in that situation!)
But it probably doesn't happen as much as our experience
with ITS suggests it should for a couple of reasons. First,
we have a lot more disk space here in the future. Running
out of disk space on the file system containing ones
personal files used to happen every couple of weeks, now
that is a somewhat more rare, although not unknown,
phenomenon. Secondly, we have hardware that is quite
reliable compared to what we used to have. Crashing in the
middle of something critical is simply a lot less likely.
So I would conclude from this that Unix is able to get away
with being sloppy about this issue because technology (in
the form of bigger disks and more reliable hardware) has
helped to -hide- Unix's deficiencies. As the technology
continues to improve, we can look forward to even -lower-
standards of software engineering in our operating systems.
From: DW
Date: Sat, 3 Apr 93 23:55:30 EST
Subject: Re: Out Of Disk Space, So I Zeroed Your File...
Date: Sat, 3 Apr 93 21:42:26 -0500
From: AB
Sender:
[email protected]
So I would conclude from this that Unix is able to get
away with being sloppy about this issue because
technology (in the form of bigger disks and more
reliable hardware) has helped to -hide- Unix's
deficiencies. As the technology continues to improve,
we can look forward to even -lower- standards of
software engineering in our operating systems.
Emacs has also helped hide this problem. I have many times
(especially on Project Loki, where the disk quotas (gasp!)
are embarassingly low) tried to write out a file and had
quota problems. Luckily, emacs has usually informed me
while I still had a copy in my buffer....
From: BM
Date: Sun, 4 Apr 93 01:27:43 EST
Subject: Re: Out Of Disk Space, So I Zeroed Your File...
Date: Sat, 3 Apr 93 21:42:26 -0500
From: AB
But it probably doesn't happen as much as our experience
with ITS suggests it should for a couple of reasons.
Another reason: many of us use GNU Emacs, which normally
uses the Unix analogue of RNMWHO (although it has options to
write directly to the original file, if you want to preserve
ownership, etc.). Of course, that's because it was written
by a former ITS hacker.
At our site, we frequently run out of disk space in our
/usr/local partition. And the "install" command on SunOS
doesn't report write errors!
From: JA
Date: Sun, 4 Apr 93 15:03:58 -0700
Subject: Filesystem? What Filesystem?
Ah, the sweet rush of relief at the return to the
unix-haters fold. Thank you thank you. Here's my initial
flame I sent to unix-haters-request, may you all take from
it what little enjoyment you can as you fight the good
battle against the big evil.
--------
This is a request to be readmitted to the vaunted halls
of unix-haters, which list I fell off as a side effect
of being laid off from CompCo. I thought I'd wait to
make this request until I had something to say. Thank
you for your consideration.
So, here I am in my lisp window, typing forms, doing my
thing, being happy it's lisp and not C (but mad that
it's the foreign function interface to C, but we won't
go into that here). So I type (load "myfile"). It
takes a while to do all the stuff that's in myfile, so I
trundle off to another window to do some other work.
While doing so, I realize there's an addition I could
make to myfile to make my life easier in the future, and
not thinking about it, I just add the form to the middle
of myfile and save out the file, and go back to my
secondary task. Eventually I decide to check on the
loading process.
There it is, in living color:
Error: the variable OBAR is unbound.
1 (continue) Try evaluating it again
What the hell??? I didn't make any variable like that.
So I look for OBAR... Aha! Near the end of myfile,
approximately the number of characters I had added from
the end, is (load "foobar")
Yep, I had changed myfile, and the existing process that
was reading it got the changes to its open file! My
addition was to the middle of the file, but did that
stop it from losing? No, it just blindly went ahead and
found more data in the file and gave it to me, never you
mind that it *wasn't* appended to!
Gaaa! VERSION NUMBERS you idiots, VERSION NUMBERS.
Gaaa! Or at the very least, DON'T GIVE ME NEW DATA THAT
I DON'T WANT!
From: BB
Date: Sun, 4 Apr 93 16:43:25 PDT
Subject: Environments -- Why Should I Care?
Months ago there was a message on this list about how Unix
is the only operating system that requires you to recompile
programs to install them. Or something like that (it's all
so terrible that I try to repress it).
But it's worse than that: Unix is the only operating system
that *requires* users to do system manager stuff in everyday
life. I am referring to environments. Why should I have to
edit my ".cshrc" file (whatever that is) and include lines
like "setenv LD_LIBRARY_PATH" and "setenv WINGZ" just to use
a stupid spreadsheet or editor? Geesh, aren't the system
guys supposed to do that? Or, better yet, aren't the
applications supposed to do that when they are installed?
Or, even better, aren't they supposed to be like the
Macintosh where they just *run*?! All by themselves?! No
need to pass GO; no need to ask the system guy what a
"<can't even remember the error message>" means? To quote
The Talking Heads "My God, What Have I Done?" Why do I use
this *&#!$!* stuff?! I mean VMS (which wasn't that good
either) at least had system environments that all users
inherited and thus they didn't have to worry about an
LD_LIBRARY_PATH.
Oh, wait, that's right, while C++ is one small step
backwards for man, Unix is a one giant leap backwards for
mankind...
From: PB
Date: Mon, 5 Apr 1993 04:13:22 PDT
X-Mailer: Sendmail/Ream version 4.16b (The Choice for a New Generation)
X-Subliminal-Message: Send me all your money
Subject: xset bc
I think I've seen this one before, flashing by on my screen
as I trawl through manual pages looking for the particular
piece of nonsense I'm after, but for some reason today it
stopped where my eyes were resting, and I read it. X "bug
compatibility" mode. Bug compatibility?
Yeah, like, I've always thought this. X isn't nearly losing
enough. It is important that it should support backward
compatibility with old bugs which were eliminated from the
server. It's just what I need, is to turn on "bug
compatibility" mode. Maybe it'll dump core more often if I
do that.
(Oh, here's another one -- a UNIX word processor which
dumped core on me the other day. What caused it to do this?
It got confused when writing out a file because -- the file
system overflowed. Naturally, UNIX's answer to this is to
attempt to write a 12M core file to the same filesystem. I
wish I'd thought of this. I wonder if they patented that
idea?)
But sure enough, bug compatibility is just what it sounds
like. To quote, "Various pre-R4 clients pass illegal values
in some protocol requests, and pre-R4 servers did not
correctly generate errors in these cases. Such clients,
when run against an R4 server, will terminate abnormally or
otherwise fail operate correctly. *Bug compatibility mode
explicitly reintroduces certain bugs into the X server, so
that many such clients can still be run*." (Let's ignore
that fact that I'm running R5, not R4, shall we?)
Oh God. I give up. They're never going to even try to remove
the grossness. They're going to build in
grossness-backward-compatibility. I should have seen this
coming, really, shouldn't I?
Ok, guys. It's time for the ITS-for-Alpha port.
From: SS
Date: Mon, 5 Apr 1993 12:01:25 -0500
Subject: I say potatoe, you say /net/potatoe
From: VB
Date: Mon, 5 Apr 93 10:01:41 -0400
Subject: Something Mildly Troubling Here?
amt> ls -l /bigtmp
lrwxr-xr-x 1 root 7 Jun 6 1992 /bigtmp -> mas/tmp
amt> ls -l /mas/tmp
lrwxr-xr-x 1 root 17 Jan 16 1992 /mas/tmp -> /mas/disks/bigtmp
amt> ls -l /mas/disks/bigtmp
lrwxrwxrwx 1 root 27 Apr 5 09:07 /mas/disks/bigtmp -> /tmp_mnt/net/hub/hub/bigtmp
No further comment needed, I think.
From: WY
Date: Mon, 5 Apr 1993 17:15:01 PDT
Subject: [SparcPRINTER crashes when out of paper -- need some suggestions]
From: WY
Date: Thu, 1 Apr 1993 10:16:20 -0800
Subject: [SparcPRINTER crashes when out of paper -- need some suggestions]
And we thought that the Genera print spooler was bad!
Date: Wed, 31 Mar 1993 17:22:11 -0800
From: MM
To:
[email protected]
Subject: SparcPRINTER crashes when out of paper -- need some suggestions
I have a SparcPrinter connected to a Sparc 2 running
NeWSprint ver 2.0. Every time the printer runs out of
paper it causes the Sparc 2 to crash. I have tried
reinstalling the NeWSprint software and playing around
with the log files etc, but I can`t figure out what`s
wrong. Any suggestions would be appreciated.
BTW: I am using the openwindows (ver 2 and 3) printtool
and not printtool packaged with the NeWSprint software.
From: SG
Date: Thu, 08 Apr 1993 11:16:32 EDT
Subject: link-to-link -> lose
Symbolic links is one of those indispensable Unix features
that get in your way all the time. I get the feeling it was
invented at a party on a Saturday night after work,
implemented in the wee hours of Sunday morning, shipped
Monday, and carefully thought out Tuesday.
I keep running across Makefiles that link two source files
together and compile them with different options to make two
objects from one source. The commands look something like
this:
cc -c -DPLANES8 source.c
ln source.c source32.c
cc -c -DPLANES32 source32.c
rm -f source32.c
cc -o prog source.o source32.o ...
So what's wrong with this? Nothing actually(1), if symbolic
links had been thought out properly.
Suppose you want to build "prog" for multiple architectures.
We might create a separate compilation directory for each
architecture, using "lndir" to make links back to the source
directory. And we might use NFS to have the source
directory mounted on a central file server. Wow, look at
all these great Unix features we're using! Astute readers
will notice that we have passed the Threshold of Combinable
Unix Features(2) and are headed for certain failure. Which
we are.
So the source directory looks something like this. (Extra
credit: what do the permission bits on the two links mean?
See note 3.)
lrwxrwxr-x 1 gildea 19 Aug 8 1992 Makefile -> /srcs/prog/Makefile
lrwxrwxr-x 1 gildea 19 Aug 8 1992 source.c -> /srcs/prog/source.c
-rw-rw-r-- 1 gildea 28136 Apr 7 13:43 source.o
..
What happens when we try to link source32.c to source.c? A
reasonable system would make source32.c exactly the same as
source.c, that is, also a link to /srcs/prog/source.c.
Having determined what a reasonable system would do, let's
look at what Unix does:
$ ln source.c source32.c
ln: source32.c: Cross-device link
Hmm, Unix thinks I've typed "ln /srcs/prog/source.c
source32.c"(5). Ok...since I'm creating a link to a
symbolic link to another file system, I have to make this a
symbolic link, too: "ln -s source.c source32.c". So is the
Makefile broken? No, "ln -s" wouldn't work on systems that
don't support symbolic links. (So how can you write a
portable Makefile? See note 6.)
You can't win. It's Unix.
Notes:
(1) Besides [the fact] that we're using C.
(2) Experimentally determined to be 0.
(3) Nothing! Pretend you're using AFS if it makes you feel better.
(4) This message was composed on Unix, so it's broken, too.
(5) Which could never work. It's Unix.
(6) You can't. It's Unix.
From: LF
Date: Thu, 8 Apr 93 23:43:05 -0400
Subject: The Decline And Fall Of Western Civilization
These stupid shit-for-brains weenix unie "programmers" have
managed to break that mainstay of Western enlightenment and
education, the dictionary. And I'll bet they excuse their
behavior by saying, "Well, it's all Greek to me"!
I suppose it's only appropriate that the invading hordes
scraped the librarian at Alexandria to death with shells.
They must have had a premonition that UNIX was coming.
- - - Begin forwarded message - - -
Date: Thu, 8 Apr 93 23:36:18 -0400
From: LF
Subject: Webster Is Broken Is A _D4^^n3d_ Peculiar Way!
Webster has a host of weird bugs. I can forward some
additional ones for you if I haven't already sent them. But
this latest one actually broke some code I was running in a
big way.
It seems that Webster doesn't either say "no such word", or
give a definition, for (ready? get this!) --the names of
greek letters--. Instead, once it malfunctions on the first
try at one of these, the next two definitions (for anything,
greek letters or not) also malfunction, and then the program
aborts. I suspect that some allocation error happens the
first time that gronks it in successively worse ways after
that.
Btw, I'm running this on UNO.DOS.TRES. Here's a transcript:
webster
[marble] /mas/mc/re/fubar/Mud/Unwrapped-Transcripts> Word: lambda
lambda
Word: lambda
lambda
Word: Lambda
Lambda
Broken pipe
[marble] /mas/mc/re/fubar/Mud/Unwrapped-Transcripts> webster
Word: Lambda
Lambda
Word: Lambda
Lambda
Word: Lambda
Lambda
Broken pipe
[marble] /mas/mc/re/fubar/Mud/Unwrapped-Transcripts> webster
Word: rock
rock
1. rock \'ra:k\ vb [ME rokken, fr. OE roccian; akin to OHG
rucken to cause to move] 1a: to move back and forth in or as
if in a cradle 1b: to wash (placer gravel) in a cradle 2a:
to cause to sway back and forth 2b1: DAZE, STUN 2b2:
DISTURB, UPSET 1: to become moved backward and forward under
impact 2: to move oneself or itself rhythmically back and
forth SYN syn SHAKE
2. rock n : a rocking movement
3. rock n [ME roc, fr. MD rocke; akin to OHG rocko distaff,
roc coat] : DISTAFF
4. rock n [ME rokke, fr. ONF roque, fr. (assumed) VL rocca]
often attrib 1: a large mass of stone forming a cliff,
promontory, or peak 2: a concreted mass of stony material;
also : broken pieces of such masses 3: consolidated or
unconsolidated solid mineral matter; also : a particular
mass of it 4a: something like a rock in firmness : 4a1:
FOUNDATION, SUPPORT 4a2: REFUGE 4b: something that threatens
or causes disaster - often used in pl. 5: a stick candy with
color running through slang 6: DIAMOND 1: in or into a state
of destruction or wreckage 2: on ice cubes {bourbon on the
rocks} - on the rocks
Word: LambdaMOO
LambdaMOO
No definition for 'LambdaMOO'.
Word: LambdaMOO
LambdaMOO
No definition for 'LambdaMOO'.
Word: Lambda
Lambda
Word: Lambda
Lambda
Word: Gamma
Gamma
Broken pipe
[marble] /mas/mc/re/fubar/Mud/Unwrapped-Transcripts> webster
Word: gamma
gamma
Word: gamma
gamma
Word: gamma
gamma
Broken pipe
[marble] /mas/mc/re/fubar/Mud/Unwrapped-Transcripts> webster
Word: alpha
alpha
Word: alpha
alpha
Word: alpha
alpha
Broken pipe
[marble] /mas/mc/re/fubar/Mud/Unwrapped-Transcripts> webster
Word: foo
foo
No definition for 'foo'. Maybe you mean:
1. fob 2. foe 3. fog
4. food 5. fool 6. foot
7. fop 8. for 9. fou
10. fox 11. foy 12. fro
Word: theta
theta
Word: theta
theta
Word: gamma
gamma
Broken pipe
[marble] /mas/mc/re/fubar/Mud/Unwrapped-Transcripts> webster
Word: y
y
y \'wi-\ n often cap, often attrib 1a: the 25th letter of
the English alphabet 1b: a graphic representation of this
letter 1c: a speech counterpart of orthographic y 2: a
graphic device for reproducing the letter y 3: one
designated y esp. as the 25th in order or class, the 24th in
order or class when j is not used, the 22nd in order or
class when j, v, and w are not used, or the second in order
or class when x is made the first 4: an arbitrarily chosen
value from the domain of a variable 5: something shaped like
the letter Y
Word: z
z
z \'ze-, chiefly Brit 'zed\ n often cap, often attrib 1a:
the 26th and last letter of the English alphabet 1b: a
graphic representation of this letter 1c: a speech
counterpart of orthographic z 2: a graphic device for
reproducing the letter z 3: one designated z esp. as the
26th in order or class, the 25th in order or class when j is
not used, the 23d in order or class when j, v, and w are not
used, or the third in order or class when x is made the
first 4: an arbitrarily chosen value from the domain of a
variable 5: something shaped like the letter Z
Word:
[marble] /mas/mc/re/fubar/Mud/Unwrapped-Transcripts> webster
Word: alpha
alpha
Word: beta
beta
Word: gamma
gamma
Broken pipe
[marble] /mas/mc/re/fubar/Mud/Unwrapped-Transcripts> webster
Word: alpha
alpha
Word: beta
beta
Word: rock
rock
Broken pipe
[marble] /mas/mc/re/fubar/Mud/Unwrapped-Transcripts> webster
Word: alpha
alpha
Word: rock
rock
Word: rock
rock
Broken pipe
[marble] /mas/mc/re/fubar/Mud/Unwrapped-Transcripts>
- - - End forwarded message - - -
From: FM
Date: Fri, 9 Apr 93 03:33:32 cdt
Subject: NFS Automounter
>I've installed the NFS automounter on our system.
Be ready to LOSE.
My experience with automount is that it repeatedly wedges
itself for no adequately explored reason and makes the
machine unusable until you reboot. It's so annoying that we
have refrained from running automount (or amd, which suffers
similarly) on the GNU machines for years. Bernard chose to
run amd on hal.gnu.one.two.thr, and half the time I try to
log into the machine it's completely wedged and unusable. I
wish he'd turn the gd thing off.
From: RS
Date: Fri, 9 Apr 1993 05:42:03 -0500
Subject: Life's A Batch, Then You Get A Cron...
Cron went haywire today (big surprise, huh?) on one of the
netnews servers I maintain. Since misery loves company, I
was tempted to put
[email protected] on the
usenet alias so you could share in my joy at getting
peppered every 10 minutes by a demented process claiming it
couldn't run nntpsend (which was present, in the directory
it was supposed to be in, and with the permissions it was
supposed to have). Merely killing cron and then restarting
it solved the problem. Needless to say, I didn't succumb to
the temptation to redirect the mail, but I'll keep all you
wonderful folks in mind next time I have a few dozen spare
messages lying around.
Unix - not only doesn't it have a real scheduler, it doesn't
have a real batch submission system either. Sorry if I
offend the saints of ITS by bringing up "lesser" operating
systems for the '10, but it's amazing how often I wish I had
Galaxy, damnit.
What a paragon of reliability. Speaking of time, could it
be that now that it's well past the 20-year mark, Unix is
starting go go a little senile? Why, not too long ago, I
had a time server lose its clock, and all the other machines
on the net happily decided that they, too, were back in
1970. Kind of like your roommate's great aunt who the
police keep bringing back from the other side of town 'cause
she thinks she still lives in the house where she grew up
years and years ago...
"... sometimes, they even boot spontaneously just to let you
know they're in top form..."
(retch)
From: WA
Date: Fri, 9 Apr 93 15:48:11 EDT
Subject: Stop That Snickering In The Back!
I heard that! If something is funny, why don't you share it
with the whole class, or perhaps you would like to stay
after school and reorganize all those little directories
under /usr/lib/terminfo?
All right, I'll share the joke. You see, we Apollo users
can't help smirking, if not cracking up altogether, whenever
we see mail on unix-haters, about all those things that we
did right 10 years ago, and UNIX has done wrong all along.
(Those of us that also used ITS find it particularly
amusing.) So, whenever you send mail about how screwed up
NFS (or whatever) is, and you hear the snickering and
laughter, that's us. The recent mail about symbolic links
was the source of my recent outburst, for which I truly
apologize to the class. You see, on Apollos, the following
three things are all INDEPENDENT and ORTHOGONAL:
(1) the "mount" mechanism for allowing auxilliary disks
or partitions to be made part of the file system
(2) the networking mechanism for making all the file
systems of all the machines on the local area
network behave like one unified transparent global
file system
(3) the soft link mechanism for allowing an item in a
directory anywhere in the global file system to be
a text string naming some other object anywhere
else in the global file system
What kind of flea-infested brain thought up the idea of
using the "mount" mechanism for doing networking, and then
had the audacity to charge people *MONEY* to *BUY* this
garbage is utterly beyond me. When it became clear that it
was necessary to have every node in the network "mount"
every other node in order for the network to behave
rationally, and that this was creating incredible headaches
for network administration, did it occur to these people
that their design was fundamentally wrong and they should
throw it away and do it correctly? No, they just added
"auto-mount" daemons. Yes, folks, there are daemon
processes running around trying to frob your "mount tables"
so that the network will behave properly.
Somehow, the phone company managed to figure out how to do
this stuff without auto-mount daemons. I never get an error
message from my telephone saying that such-and-such an area
code isn't mounted.
Anyway, to get to the point, on an Apollo network, ALL parts
of the global file system are accessible by the same name
from ALL points. Mounting is used for auxilliary disks.
Once a disk is so mounted, it is of course automatically
part of the global file system, and immediately visible from
anywhere. The symbolic link mechanism can link ANY point in
the global file system to ANY OTHER point, whether it
crosses the network or not. Because all parts of the global
file system have universal system-wide names, the links JUST
WORK. If we have a link like this:
source.c -> /srcs/prog/source.c
meaning, of course, directory "srcs" relative to the root of
this node, and we link across the network to it, the "/srcs"
still means relative to the node in which the link lives,
rather than the node initiating the request. That way, any
reference to that link will always wind up at the correct
file.
It really isn't that hard to do it right!! Workstations
that do it right have been around for 10 years.
From: JA
Date: Fri, 9 Apr 93 16:36:18 -0400
Subject: Re: NFS Automounter
Date: Fri, 9 Apr 93 03:33:32 cdt
From: FM
>I've installed the NFS automounter on our system.
Be ready to LOSE.
Let's not forget wonderful behaviour like:
ja@brandi$ ls /src
ja@brandi$ ls /src/X*
/usr/local/gnubin/ls: /src/X*: No such file or directory
ja@brandi$ cd /src/X11R5
ja@brandi$
From: DM
Date: Fri, 09 Apr 93 19:25:06 EDT
Subject: Re: Stop That Snickering In The Back!
> From: WA
> Date: Fri, 9 Apr 93 15:48:11 EDT
>
> Somehow, the phone company managed to figure out how to do
> this stuff without auto-mount daemons. I never get an
> error message from my telephone saying that such-and-such
> an area code isn't mounted.
But I do get such an error message from my PBX. Well, the
error message is not that specific, it's a busy signal or
something, but that's what it really means. The f3ing piece
of s2t probably runs Unix and uses pipes to implement phone
calls. We keep it in the same closet as the Unix systems
and other such slime infested garbage.
> It really isn't that hard to do it right!! Workstations
> that do it right have been around for 10 years.
I would have thought that the collapse of "actually existing
socialism" would have disabused you of the Marxist notion of
linear progress. In the world of Unix and Unix-like
computers (in which I would include Apollo DOMAIN, no
offense meant), everything gets progressively worse, not
better. Except MIPS/$, which appears to be the sole
accepted measure of quality.
Date: Sat, 10 Apr 93 14:23:28 edt
From: NF
Subject: [Re: Patching Stock /usr/ucb/whois For The New Internic Service]
------- Start of forwarded message -------
From: EG
Date: 7 Apr 93 08:11:00 GMT
Subject: Re: Patching Stock /usr/ucb/whois For The New Internic Service
In some article JI writes...
#<>And here is a perl version of "whois" I wrote today:
#<Neat...here is my shell version.
# Yeah, I wrote one of those too, but discarded it as not K00l
#enough. Emacs LISP anyone?
Man, how I wish I could do that! See, I'm stuck with
MultiNet TCP/IP for VMS, and they just do one measly set
command and it figures out the new NIC.
What a pisser. No patches, no reboots, no clever scripts in
a foreign CLI, no weirdnesses, and still forward compatible
with future changes. I hate MultiNet because it's
preconfigured in the right way.
Man it's a good thing TGV Inc. did it, or I'd be here doing
as much hacking as you gurus!
..
------- End of forwarded message -------
From: JL
Date: Sun, 11 Apr 93 06:38:19 EDT
Subject: RE: link-to-link -> lose
...I keep running across Makefiles that link two
source files together and compile them with
different options to make two objects from one
source. The commands look something like this:
cc -c -DPLANES8 source.c
ln source.c source32.c
cc -c -DPLANES32 source32.c
rm -f source32.c
cc -o prog source.o source32.o ...
So what's wrong with this? ...
OK, please damage my brain a bit and explain to me why
anyone would want to do this. In what way is it better than
just:
cc -c -DPLANES32 source.c -o source32.o
which is how one would do it on a rational system?
Or even, if there's some You-nixed (i.e., bizarre and
anti-functional) interaction between -c and -o:
cc -c -DPLANES32 source.c
mv source.o source32.o
cc -c -DPLANES8 source.c
I get the feeling I'm on the edge of a breakthrough I my
understanding of The Unix Way. Please give me another small
brain hemorrhage and help be cross that threshold.
From: SH
Date: Sun, 11 Apr 93 11:58:44 -0400
Subject: Re: link-to-link -> lose
>From: JL
>Date: Sun, 11 Apr 93 06:38:19 EDT
[...]
>Or even, if there's some You-nixed (i.e., bizarre and
>anti-functional) inter- action between -c and -o:
>
> cc -c -DPLANES32 source.c
> mv source.o source32.o
> cc -c -DPLANES8 source.c
>
>I get the feeling I'm on the edge of a breakthrough I my
>understanding of The Unix Way. Please give me another
>small brain hemorrhage and help be cross that threshold.
Well, if you really want another tumor... In fact, Motorola
System V/88 requires the above, but you must add more
commands if you have a group of developers. In this case,
the move could fail if you are not the last person to
compile the file.
cc -c -DPLANES32 source.c
rm -f source32.o
mv source.o source32.o
Even worse is the fact that the snotty cfront based
implementation refuses to accept .cxx as a C++ file
extension (treats it as a file to be passed to the linker).
Since we chose .cxx as the lcd which works on all systems
that we support but this one, the full script in all its
glory is (assuming source is a c++ file)
rm -f source.C
ln -s source.cxx source.C
CC -c -DPLANES32 source.C
rm -f source32.o
mv source.o source32.o
Of course, since we started out by getting rid of ln usage,
those first two lines should probably read
rm -f source.C
cp source.c source.C
Why compiler writers can't all support some basic options
like -o and "believe me, its a source file, just disregard
that extension" is one of the imponderable mysteries of the
universe. Or, more succinctly, FMHWATID.
From: AB
Date: Sun, 11 Apr 93 23:02:15 -0400
Subject: Group Theory
I wonder what groups I'm in?
> groups
user staff fax lispm
Cool. I wonder what group my directory named `temp' is in?
> ls -lgd temp
drwxrwxr-x 2 alan user 512 Mar 14 20:30 temp
Ah, the `user' group, one that I am in myself. Actually,
I'd rather that directory be in the `staff' group.
> chgrp staff temp
chgrp: You are not a member of the staff group
Come again? Did that have any effect?
> ls -lgd temp
drwxrwxr-x 2 alan user 512 Mar 14 20:30 temp
Apparently not. Do -all- the groups I'm in behave this way?
> chgrp fax temp
> ls -lgd temp
drwxrwxr-x 2 alan fax 512 Mar 14 20:30 temp
So apparently I really am in the `fax' group, but not the
`staff' group?
> chgrp staff temp
chgrp: You are not a member of the staff group
I guess so. I guess I must be a member of some -other-
group that just happens to be named `staff' as well. I
wonder...
> cat /etc/group
wheel:*:0:
nogroup:*:65534:
daemon:*:1:
kmem:*:2:
bin:*:3:
tty:*:4:
operator:*:5:
news:*:6:
uucp:*:8:
audit:*:9:
staff:*:10:
other:*:20:
+:
Ah Ha! For those of you not familiar with the Yellow Pages,
let me try and explain. See, this here file is a database
of groups and who is in them. So the group named `staff' is
here defined to have the number 10, and no members. Except
there are additional groups stored in the Yellow Pages --
you know that because that's what the line containg "+:"
means (obvious, huh?). Let's see what's in the Yellow
Pages:
> ypmatch staff group
staff:*:10:root,file-server,glr,kwh,dms,sundar,cjl,ray,djsm,tower,towercsh,jp,pao,lct,leo,jck,andyc,andrew,noakes,pgs,jcma,viola,tmb,bfox,nsp,vanni,hack,kingdon,randy,berwick,djm,kerr,dick,roland,robles,caroma,cstacy,misha,hqm,mib,davis,beymer,ian,pwu,bavery,jonathan,friedman,laurel,rst,bruce,taalebi,rs,qobi,ddl,gumby,rwk,ymtan,torrance,alan,zalondek,gill,ericldab,cwitty,mpf,spraxlo,anarch,cdsmgr,mhcoen,sgw,grg
Well, well. Here is -another- group named `staff', also
with the number 10, and a bunch of members (including me).
I'm not even going to begin to speculate about the Rube
Goldberg machinery that causes this to result in the dialog
that started my message.
From: NF
Date: Tue, 13 Apr 93 02:19:49 edt
Subject: Nightmares
Not sure if everyone on this list has seen this before.
From: DL
Date: Thu, 15-Dec-83 13:03:52 EST
Subject: A Nightmare
Last night I dreamed that the Real World had adopted the
"Unix Philosophy."
I went to a fast-food place for lunch. When I arrived, I
found that the menu had been taken down, and all the
employees were standing in a line behind the counter waiting
for my orders. Each of them was smaller than I remembered,
there were more of them than I'd ever seen before, and they
had very strange names on their nametags.
I tried to give my order to the first employee, but he just
said something about a "syntax error." I tried another
employee with no more luck. He just said "Eh?" no matter
what I told him. I had similar experiences with several
other employees. (One employee named "ed" didn't even say
"Eh?," he just looked at me quizzically.) Disgusted, I
sought out the manager (at least it said "man" on his
nametag) and asked him for help. He told me that he didn't
know anything about "help," and to try somebody else with a
strange name for more information.
The fellow with the strange name didn't know anything about
"help" either, but when I told him I just wanted to order he
directed me to a girl named "oe," who handled order entry.
(He also told me about several other employees I couldn't
care less about, but at least I got the information I
needed.)
I went to "oe" and when I got to the front of the queue she
just smiled at me. I smiled back. She just smiled some
more. Eventually I realized that I shouldn't expect a
prompt. I asked for a hamburger. She didn't respond, but
since she didn't say "Eh?" I knew I'd done something right.
We smiled at each other for a little while longer, then I
told her I was finished with my order. She directed me to
the cashier, where I paid and received my order.
The hamburger was fine, but it was completely bare... not
even a bun. I went back to "oe" to complain, but she just
said "Eh?" a lot. I went to the manager and asked him about
"oe." The manager explained to me that "oe" had thousands
of options, but if I wanted any of them I'd have to know in
advance what they were and exactly how to ask for them.
He also told me about "vi," who would write down my order
and let me correct it before I was done, and how to hand the
written order to "oe". "vi" had a nasty habit of writing
down my corrections unless I told her that I was about to
make a correction, but it was still easier than dealing
directly with "oe."
By this time I was really hungry, but I didn't have enough
money to order again, so I figured out how to redirect
somebody else's order to my plate. Security was pretty lax
at that place.
As I was walking out the door, I was snagged in a giant Net.
I screamed and woke up.
--
From: JA
Date: Tue, 13 Apr 1993 18:08:40 -0400
Subject: Hey! That's *My* Paging Partition!
We at SomeCompany have discovered a New Way to get more
diskspace available to users! Share your paging partitions!
That's right, in /etc/fstab on all your machines, just put
the same line for swap partitions... Then, NFS mount the
filesystem. None of that need to do mkfile! And the best
part is, you don't have to buy more disks!
*Why* does unix allow you to page off of NFS mounted filesystems?
*Why* does unix allow you to page off the SAME FILE that some other
system is paging off of? Can you say "file locking"? I'm sure you
can...
From: NF
Date: Tue, 13 Apr 93 23:46:22 edt
Subject: Re: Hey! That's *my* paging partition!
>Can you say "file locking"? I'm sure you can...
cn't sy "fl lckng" bcs nx dsnt hv ny vwls! :-)
From: RS
Date: Wed, 14 Apr 1993 19:14:12 -0500
Subject: Re: Returned Mail: Can't Create Output
Gee, I remember seeing this kind of message from PMDF a lot
- now it looks like some bright person decided to integrate
VMS's lossage into their Unix mailer.
> Date: Wed, 14 Apr 1993 19:04:10 -0400
> From: Mail Delivery Subsystem <
[email protected]>
> Message-Id: <
[email protected]>
> To: rs
> Subject: Returned mail: Can't create output
>
> ----- Transcript of session follows -----
> thalx: User has exceeded their disk quota, try again later
> 550 <
[email protected]>... Can't create output
>
> ----- Unsent message follows -----
From: JL
Date: Wed, 14 Apr 93 23:16:47 EDT
Subject: More Tales Of Unix Mail Wonder
Date: Wed, 14 Apr 93 20:13:58 EDT
From:
[email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
To:
[email protected]
----- Transcript of session follows -----
link access: Remote node failed to respond
cat: write error: Broken pipe
550 crd!arthur_monroe.sdf... User unknown
Just WHAT is it telling me:
That the remote node failed to respond?
That the user really is unknown?
That someone stepped on a cat? Was it Siamese?
From: CG
Date: Wed, 14 Apr 93 20:45:15 -0700
X-Headline: CHAMP'S ESTRANGED WIFE PLEADS PMS-INDUCED INSANITY FOR MAYOR DALEY!!
Subject: X
I just found out a wonderfully useful bit of information
today, but I won't share it with you because that would be
contrary to The Charter. So there.
I will, however, tell you what it does. It let's you see
error messages produced by the X Window System!!! Wow!
(I'm talking here about the error messages produced by
whatever bits rummage through your myriad
joes-window-manager-init and .xmumble files. Gee, I wonder
where those error messages go when I can't see them...) Now
that I have this information (and know the secret handshake
too) I may actually be able to debug my .twmrc file! And
then I can get real work done, right?
I think it is a measure of how far I have sunk since leaving
the world of lisp machines that I actually found this
impressive for a few minutes.
From: JR
Date: Thu, 15 Apr 93 9:15:19 EDT
Subject: MAKEing Kindergarten Mistakes
So I'm toiling away trying to decrypt someone else's
Makefile when I get the error message:
Fatal error in reader: line 57: More than one % pattern on
left hand side
Gosh! A line number! Maybe there's hope! As you can tell,
my unix experience is limited. Line 57 reads:
%.ram.ob: %.mal $(UC_PATH)hmu.def $(UC_PATH)hmu.mac
Hmmm, there only seems to be one percent sign here. What
else could be wrong? I look higher in the file, and a
horrible suspicion seizes me when I see:
%.ram.abs: %.ram.ob %.ram.ml $(UC_PATH)hmu.def $(UC_PATH)hmu.mac
There are two percent signs, but on the RIGHT-hand side. I
comment out this line, and the message no longer appears.
So, yes, the author of 'make' - the most fundamental tool of
software engineering, the foundation of all UNIX software
integrity, the only bulwark between eUnnuchs and the raging
chaos of build procedures - this guy confused left and
right. My job depends on this stuff.
From: WY
Date: Mon, 19 Apr 1993 14:21:15 PDT
Subject: Forwarded Without Comment
From: KP
Date: Mon, 19 Apr 1993 12:00:19 -0700
Subject: Repertory Downtime
The file server "repertory" will be down from 8:30am
tomorrow until approx 9:00am, to replace a failed drive.
The file system on the bad drive is /repertory-7 and users
of it may experience "stale NFS file handle" messages, which
will require a reboot of their workstation to clear.
From: RM
Date: Wed, 21 Apr 1993 12:01:10 PDT
Subject: Is That A Regular Expression? Or Is It Instead A Regular Expression?
From: GB
Date: Tue, 6 Apr 1993 23:23:09 GMT
Subject: Re: Regexps From Shell Wildcards
WL writes:
if you wanted to do /bin/csh shell expressions, then
you'll find that things like "*.{c,C,H,h,cf}" cause
problems and cause the output string length to grow
wildly.
Worse than that, the csh {foo,bar} construct is not a file
glob and in general has semantics that cannot be duplicated
with REs:
- Order is preserved, so *.{h,c} is NOT the same as *.[hc]
- Is expanded regardles of matches, so "echo {foo,bar}.c"
will work whether or not foo.c or bar.c exist.
Of course, in any one application these may not be a
problem, and more-or-less mechanical conversion to (foo|bar)
might be acceptable.
Just as a hint, here is some perl code I use to convert
sh-type globs to REs in a Perl package. The input glob
pattern is known to contain no '/' characters (the handling
of which is "interesting" recursion).
I make no promises about this, but it hasn't failed me yet.
# Convert shell-style glob pattern to regex
$pat =~ s/[.=<>+_\\-]/\\$&/g;
$pat =~ s/\?/./g;
$pat =~ s/\*/.*/g;
# Hide leading . from wildcards
$pat =~ s/^\.\*/[^.].*/; # .* -> [^.].*
$pat =~ s/^\.([^\*])/[^.]$1/; # .x -> [^.]x
$pat =~ s/^\*/[^.]*/;
# Anchor the pattern
$pat = "^$pat\$";
# could do some optimising here, but leave it to perl!
# e.g. "^.*" => ""
# ".*$" => ""
--
From: PH
Date: Sun, 25 Apr 93 16:04:46 -0700
Subject: Please Remove Me
Please Remove Me
From: CL
Date: Thu, 29 Apr 93 16:53:56 -0400
Subject: [Forwarded: I've Been Programming In C!!]
To the unix-impaired, the realization that there's an entire
world of programming outside of ``vi, cc, a.out'' can be a
satorial experience. Witness the mail sent to me by a
friend upon getting an old Anon 1108 lisp machine working
and discovering just what he had been missing out on all
these years:
--- Begin Forwarded Message ---
From: KA
Date: Tue, 27 Apr 93 16:53:52 -0400
Subject: I've Been Programming In C!!
All these years, I've been programming in C! C!
It's such a shock, I feel like I've been working for
Microsoft or something....what was I thinking?!?!?!
So anyhow, I came about this discovery while reading Volume
1 of the Interlisp D reference manual, in it are some of the
little toys it has to help you out while programming, such
as DWIM (Do What I Mean) and the Programming Assistant,
which keeps track of what you have done, undone or altered.
It also has something called the Masterscope which can
analyze a user's function and build a database of the
results. Using another of the functions you can basically
say EDIT WHERE ANY CALLS '(BIN BOUT ...) and change an
entire program..... Also, with this environment, apparently
you can have multiple, independent processes. It is
additionally oriented towards network services and
distributed processing across machines.
This is one incredible system.
- Amazed in Amozonia -
--- End Forwarded Message ---
From: JL
Date: Sun, 2 May 93 17:59:48 EDT
Subject: Signature Seen On The Net
=============================================
[ ]
[ Unix is to computing ]
[ as an Etch-a-Sketch is to art. ]
[ ]
=============================================
From: RA
Date: Tue, 4 May 93 4:49:26 EDT
Subject: Brave Little Ethernet Packet Goes To Mars
I haven't had much to say on this mailing list lately
because for the last year or so I've been spending so much
of my time loathing MS-DOS that I've had little time left
over in which to hate unix. But this evening I had one of
those experiences that brings it all back.
See, on recent versions of Berkeley-derived unix there's
this thing called the Berkeley Packet Filter. To someone
who has spent a year tracking TCP segments through what
passes for a debugging environment under MS-DOS, BPF could
be mistaken for a godsend. Here's this nice built-in
mechanism that allows you to send and receive raw ethernet
packets, thus allowing you to track your TCP segments under
a debugger that (usually) doesn't crash the machine when it
hits a breakpoint.
Right.
So I spend a couple of days figuring out how to use this
thing. Ok, nevermind that you have to tell this device what
the MTU is you want to support before you're allowed to ask
it what the MTU is of the interface you're trying to use,
and that if you get this wrong your read() calls will all
mysteriously fail. Nevermind that this code won't tell you
how big the headers it puts on incoming packets will be,
because it wants to protect you against alignment problems
on three different processors that you're not using.
Nevermind that the ioctl() that's supposed to tell you what
the ethernet address is so that you can set it into the
filter program for the emulated micromachine that BPF uses
to throw away packets you don't want is broken, if you can
figure out how to program the micromachine at all, the only
person who understands this language is Van Jacobson, but
anyway, that ioctl() doesn't work so you've got to feed the
damned ethernet address back into the system via an
environment variable set by a shell script that grovels the
messages the kernel emits when it boots. Nevermind all
that. I've been in DOS hell, I've learned, like someone
from New Jersey, not to expect too much, I can adjust. And
at least the output interface to BPF is nice and simple, you
just hand a packet and a file descriptor to the unix write()
call, that's it.
So I finally get this program written, run it, it looks
happy, I try to ping it from another machine. Bupkiss.
That's ok, the whole reason for this is to be able to run a
debugger, right? So I run my debugger and I see that the
ARP packets are coming in just fine, and we're processing
them just fine, and composing ARP responses just fine, and
all seems as happy as a clam, this should be working.
I'd still be wondering if I hadn't been using FTP software's
network monitor program and mis-typed a command. See,
LANWATCH's running screen mode does different link-layer
protocols in different colors, so debugging TCP/IP stuff is
usually pretty bloody but occasionally descends into
Christmas mode when the bright green ARP packets start
mixing it up with the red IP packets. But I screwed up the
filter command I tried to specify, and all of a sudden I
start seeing these black packets in response to the ARP
requests.
Wait a minute. BLACK packets? Black packets are packets
whose link layer type field isn't recognizable. Oh no, I
have a bad feeling about this....
Yup. Although unix requires that every other field you put
in an outgoing ethernet packet be in "network" order, it
wants to diddle around some more with the ethernet type
field and can't be bothered to store it somewhere else, so
it has you fill in the ethernet type field in "host" order
then byte swaps it for you when it's done screwing around.
It's wired into far too much code to change it.
Fortunately, there's an obvious answer, clear to any true
unix weenie: just byte swap the type field one more time in
the BPF write() driver routine.
I think I'll go and crash my unix box by running supdup now.
From: CM
Date: Fri, 7 May 93 01:53:47 EDT
Subject: The Unix Mind Set
Wow! A text-book perfect case.
From: BB
Date: Thu, 6 May 1993 13:59:07 -0700
Subject: Re: FTP Block Mode Implementations?
*> Mike Karels and I argued for a long time with Braden
*> about it. Braden continually insisting that it was not
*> possible to implement in a portable manner, yet not being
*> able to produce a coherent counter argument. Finally, we
*> decided we had other things to do and just implemented
*> it.
Since Rick has mentioned my name in this fashion, I feel
obliged to comment.
The discussion, as I recall it, went like this.
Me: there are files systems in the world (IBM MVS was
the example with which I was familiar) in which is is
difficult, if not impossible, to implement the byte-count
approach of Rick and Mike.
Rick: Such file systems are brain-damaged and should not
be considered.
Me: But you have to consider them; standards are
concerned with interoperation. RFC-959 is an Internet
standard, the result of an intense effort [admittedly in
1973-1975]. You shouldn't just ignore it because you find
it distasteful.
Rick: We'll do it the way we like.
Rick, if you think this is an unfair representation of the
discussion, please correct me.
From: OS
Date: Fri, 7 May 93 21:57:06 EDT
Subject: Another Satisfied Customer
[Identifying information has been obscured to protect
the privacy of the lucky winner. Note the >From, an
indication of authenticity that is preserved from the
original forwarding.]
>From
[email protected] (Abc Defgh)
Newsgroups: misc.forsale.computers.other
Date: 99 Mmm 93 12:34:56 GMT
Subject: Sun SPARCclassic For Sale
Solaris 2 is worthless!
For sale: Sun SPARCClassic
15" Color Monitor
16 MB Ram
207MB Internal disk
Sun 5 Keyboard, Mouse n' Pad
Loaded with Solaris 2.1
$3600 Complete
This system is essentially brand new. It runs Solaris 2
which is an unfriendly feature-devoid piece of dog excrement
incapable of compiling most popular software.
If you're still standing in line for one, here's your chance
to be ripped off like I was. Compiler NOT included!
-Abc
==================================================================
= Abc Defgh | +1 333-333-3333 Internet Dialup Access =
= IJ Klmn |
[email protected] =
= Box 123 | +1 098-765-4321 Voice =
= Opqrstuv, WX. 99999 | +1 123-456-7890 Fax =
==================================================================
From: AB
Date: Sun, 9 May 1993 07:51:14 -0400
Subject: the soul of a lame machine
I've been sitting here for quite a while now, because they
told me I had to come upstairs away from the lispms and hack
together something that might actually function well enough
to get some mail moving around this place in the right
direction, with not too many extraneous ">"s or
"X-Gratuitous-Braindamage:" inserts. But I'm not here to
talk about that; this sorry unix mailer wouldn't let me
flame that much without crashing and leaving another 50 or
60 droppings in my mail spool file. Instead, I shall just
point out that, for the first time this weekend, unix has
actually done something that I wanted it to do. The first
time. Exactly what I wanted it to do. Something useful,
even. See, in a moment of masochism, I determined that I
wanted to discover yet more obscure ways to lose lose lose
with yet another incompatibly-argumented command. Of
course, a moment later, I realized the error of my ways, and
tried to stop. And that's the astonishing thing. It *did*
stop. Right when I asked it to.
church$ man ar
Reformatting page. Wait...^G aborted (sorry)
So, of course, it apologized. I'm sure it won't happen
again.
From: CM
Date: Tue, 11 May 93 16:32:08 EDT
Subject: BOOT, Don't REBOOT
What does this mean? And why do I have to run fsck anyway.
Why doesn't it just work...?
% fsck
[ whine whine whine ]
***** FILE SYSTEM WAS MODIFIED *****
***** HALT and BOOT unix (DO NOT REBOOT!!) *****
***** USE '/etc/reboot -n' *****
From: RA
Date: Wed, 12 May 93 12:37:05 EDT
Subject: Building Emacs On A 108% Full Disk
So we just got this Sun Sparc-IPC box, kinda looks like a
caricature of a computer, all head, no body. Came with a
200MB disk, which was almost entirely filled by a bunch of
OpenSomething GUI crud for the keyboard-impaired. What it
didn't come with was emacs.
So, ok, I hand configure the ethernet interface and the
routing and slurp over a copy of emacs 18.59 from prep. Oh,
right, I've got to slurp a copy of gzip too this year, ok.
So I build gzip, unzip (stop snickering, you in the back)
the tar file. Hmm, not enough disk space to untar emacs.
Oh well, guess I don't need gzip anymore.
Hmm, still not enough space to untar emacs. A couple of
iterations of trying to untar just the essential parts of
emacs by hand convince me that this is futile. Ok, well,
I've got a huge disk on another machine, I'll untar emacs
there and move it over.
Oh dear, there are three files I have to edit to build
emacs. How do I edit them without an editor? Well, I can
edit them on the other machine and FTP them over. Hey, wait
a minute, what about ange-ftp? Yeah, that's it, I'll use
ange-ftp to edit the files remotely via the ftp server from
a machine where I've already got emacs running. Gee, this
isn't so bad.
Go back over to the sparc, type "make", it says "huh? I
don't see anything here to make". Hmm, how did that
makefile I just edited get to be zero length? And the other
two config files I just edited too.
Oh.
See, all that source code I just moved over drove the disk
usage up to about 108% full, so only root's allowed to
allocate disk blocks now. But I edited the three config
files logged in as myself, forgetting that this is unix,
where successful completion of a file write operation
doesn't mean that your bits ever got anywhere near the disk.
It seems that if you tell the ftp server to write a file
onto a disk that's more than 100% full, it says "ok, file
transferred successfully" and truncates the file. Unless of
course you're logged in as root, in which case it says
exactly the same thing but writes the bits out.
In a final gesture of futility, after finally getting emacs
built, I went and read the tunefs man page, which allows you
to fiddle the magic number that determines how full a unix
filesystem is allowed to get. The default value is 10,
which means that filesystems can get up to 111% full. It is
possible to set the magic number to zero, which would limit
the disk to only getting 100% full, but, warns the tunefs
man page, having your disk only be allowed to get 100% full
is bad for your disk throughput.
From: MP
Date: Wed, 12 May 1993 14:52:36 -0400
Subject: Where'd *This* Come From?
So, here I am, puttering along on this UNIX box, when I
notice a core file in the root directory. Hmmm, I sez, that
wasn't there before I booted this beast. So I tried to look
at the file with dbx, then gdb. No luck -- the debuggers
couldn't read it. Try strings on it -- no luck; no strings.
Bring up the core file in emacs. Hmmm -- looks like
something from startup. But the machine started up fine,
and there's no hint in either the log files or in the core
file of what program may have done this.
So, delete the core file, check the logs, boot the machine.
Machine comes up, core comes back. Same size, looks the
same inside.
So, why doesn't UNIX have some way of finding out what
program barfed? A core file is a large turd on the disk. A
few more bytes in it wouldn't be that bad. Also, supposedly
the startup winnage and lossage all ends up in log files, or
spewed on the screen. Nada in this case. Sigh. Yet more
drain bamage, brought to you courtesy of AT&T plus a host of
others.
Can I have a better OS, please?
From: BB
Date: Wed, 12 May 93 14:47:39 PDT
Subject: Time Means Nothing When You're Having Fun
Wow, what a thrill, an error message 42 days after the fact!
I guess that the unix weenies figured that since they
weren't doing anything useful, nobody else is either, so
it's okay to wait a while before sending e-mail...
:) From daemon Tue May 11 21:49:05 1993
:) Return-Path: <root>
:) Received: by at.dot.at.dot (4.1/SMI-4.1-UVic1.0MX)
id AA00229; Tue, 11 May 93 21:49:04 PDT
:) Date: Tue, 11 May 93 21:49:04 PDT
^^^^^^^^^
:) From: root (Operator)
:) Message-Id: <
[email protected]>
:) Subject: editor saved ``aaa.in''
:) Apparently-To: tkwan
:) Status: R
:)
:) You were editing the file "aaa.in"
:) at <Tue Mar 30 20:51> on the machine ``ra''
^^^^^^
:) when the system went down.
:)
:) You can retrieve most of your changes to this file
:) using the "recover" command of the editor.
:) An easy way to do this is to give the command "vi -r aaa.in".
:) This method also works using "ex" and "edit".
:)
And then, of course, it contains the statement "an easy
way..." Ha! And "this method also works"... Double ha!
This is unix. Nothing works!
From: JA
Date: Wed, 12 May 1993 17:47:10 -0400
Subject: Oh, Just Kill Those Trees, We Don't Care.
% lpr reallybigfile.ps
lpr: /usr/users/cary/reallybigfile.ps: copy file is too large
<read man pages, find -s option>
% lpr -s reallybigfile.ps
% lpq
Rank Owner Job Files Total Size
active cary 72 /usr/users/cary/reallybigfile.ps 1025024 bytes
1st cary 73 /usr/users/cary/reallybigfile.ps 2071097 bytes
Oh, fine. Just GIVE ME AN ERROR and GO AHEAD AND PRINT A
TRUNCATED FILE.
Geez.
From: RS
Date: Wed, 12 May 1993 19:26:44 -0500
Subject: Re: Where'd *This* Come From?
> Date: Wed, 12 May 1993 14:52:36 -0400
> From: MP
>
>
> So, why doesn't UNIX have some way of finding out what
> program barfed? A core file is a large turd on the disk.
> A few more bytes in it wouldn't be that bad. Also,
> supposedly the startup winnage and lossage all ends up in
> log files, or spewed on the screen. Nada in this case.
> Sigh. Yet more drain bamage, brought to you courtesy of
> AT&T plus a host of others.
You obviously aren't sufficiently infused with the Tao of
Unix. The proper way to handle this problem is to put "rm
-f /core" as the last line of your rc.local. On second
thought, make that "rm -f /vmunix".
From: JP
Date: Wed, 12 May 1993 20:42:22 -0400
Subject: Suggested
A fine suggestion from the authors of the tla tcp for vms
documentation
>
>Unix (you-nix) Another operating system that lots
> of people use. People who use Unix tend to act like
> they should set the standards for everyone else.
> If you meet someone like that, you should hit them
> with a wet fish, apologize, and then pretend nothing
> ever happened.
>
>VMS (vee-em-ess) The operating system of the future
> which will probably be extinct in a few years.
>
Personally I would leave out the apologize part.
From: BW
Date: Thu, 13 May 93 11:40 EDT
Subject: Jokes In The Machine...
On my SUN SPARCstation, after reading 4 screenfuls of
"UNIX-quality" 8-( documentation they have the unmitigated
gall to finish with a "JOKE"!
@BEGIN(UNIXCRAP)
Sun Release 4.1 Last change: 5 July 1990 2
TUNEFS(8) MAINTENANCE COMMANDS TUNEFS(8)
You can tune a file system, but you can't tune a fish.
@END(UNIXCRAP)
"UNIX is a computer virus with a user interface"
From: RS
Date: Wed, 19 May 93 11:21:11 -0400
Subject: Have I Ever Mentioned..
.. how much I hate this OS?
You know Unix - the operating system that has all these
fabulous disk checking utilities like dcheck, icheck, and
fsck which give you the thumbs up on your filesystems, but
the machine still says "Panic - freeing free inode" after
running for several hours and dies a heinous death, taking
all your work from the past 12 hours with it? I've been
working on this for almost 24 hours solid, and I'm about to
smash the gd box with a tire iron. What a total piece of
shite.
PS: The first person who says "Oh, you're using Unix - you
deserve to lose..." gets spit on. I _know_ that. Find me a
reasonable machine (non-unix) that runs all the crap that
the cretins want these days (like netnews), and I'll trade
up.
I'm heading off to spin an install tape now. Did someone
say something about six character filenames? Well, at least
the Salvager actually *salvaged* shite instead of giving you
messages like:
Important-file-you-wanted inode 11365 corrupt - flush it?
NO, G*DD*MN IT , I DON'T WANT TO FLUSH IT. I WANT MY
FRIGGIN FILE BACK. YOU WEREN'T WRITING IT WHEN YOU WENT
DOWN - IN FACT, YOU WEREN'T EVEN WRITING ON THAT PARTITION.
WHY DID YOU CORRUPT IT, YOU WORTHLESS PIECE OF GORILLA
EXCREMENT?
there, I feel better (a little) now...
From: SS
Date: Wed, 19 May 1993 12:19:19 -0400
Subject: How To Lose With Paste
from RISKS:
----
Date: Tue, 18 May 1993 11:22:57 GMT
From: CL
Subject: Re: Cut and Paste risks (Zwicky, RISKS-14.61)
> I've never liked the X method of cutting and pasting
> much, but I'm beginning to feel actively hostile
> towards it.
> EZ
Not to mention mixed platform, mixed GUI cut-and-paste
problems. I am a system manager for both VMS and Ultrix
systems. I use an Ultrix machine running Motif for my GUI,
while most of the VMS users have DECwindows.
The main problem is the differing cut-and-paste buttons:
Motif uses the middle button, while DECwindows uses the
right button (assuming a right-handed mouse set-up). This
becomes a problem when I run a standard DECwindows
applications with the display on Motif. Only the left mouse
button (select text) remains constant.
Plus, some DECwindows applications (notably DECwindows Mail)
like to reset the cut-and-paste buffer if you switch input
focus to a certain window. (E.g., DECwindows Mail seems to
put the text of the current message in the cut-and-paste
buffer automatically.) My autofocus mouse (ala Sun) wreaks
havoc with this. Many times I have selected text in one
window, moved the mouse to a terminal window, pasted, and
had the entire contents of a mail message run as Unix
commands because I had accidentally had my mouse cross over
the DECwindows Mail window (focusing input briefly on it).
My solution? Live with it. It has not gotten to a point
yet where I feel the need to hunt down the various settings
files (*if* this is possible) to fix the problems by
creating "Laffer's own standard GUI set-up". Being a system
manager, I use a good variety of computers and their various
GUIs frequently. Furthermore, I have to help users a lot,
and I have found that if I customize my own GUI and shell
settings too much, then I can't function with the standard
GUI and shell commands. (It is very embarrassing to type
all of these arcane short-cut aliases in front of a user at
her/his terminal, and have them not work! You look
incompetent....)
How to practice safe cut-and-paste practices? *NEVER* paste
into a terminal window with a superuser session (be it
"SYSTEM" or "root"). This means one has to type it all,
possibly leading to transcription errors, but one should
always double-check important commands anyway.
Of course, as Ms. Z's message shows, a lot of times pasting
into a superuser session window is unintentional. More than
once I have gone to scroll my xterm window (using the middle
button in the scroll-bar area), only to hit the middle
button a microsecond too early. BLAM! I've just pasted a
mail message into my VMS SYSTEM session, and all of its
contents are being interpreted as commands. Luckily nothing
major has happened because of this!
Sometimes I think going back to a good old VT100 terminal
would be safer all around....
From: CM
Date: Wed, 19 May 93 15:54:38 EDT
Subject: Re: Have I Ever Mentioned..
Date: Wed, 19 May 93 11:21:11 -0400
From: RS
You know Unix - the operating system that has all
these fabulous disk checking utilities like dcheck,
icheck, and fsck which give you the thumbs up on
your filesystems, but the machine still says "Panic
- freeing free inode" after running for several
hours and dies a heinous death, taking all your
work from the past 12 hours with it? I've been
working on this for almost 24 hours solid, and I'm
about to smash the gd box with a tire iron. What a
total piece of shite.
Unix reminds us to strive for perfection. The file you were
working on was obviously "not good enough" in the eyes of
the god and it used the most convenient vehicle (a kernel
panic in this case) to ask you to please try again. I am
happy that Unix is so forthright about its flaws. It is a
constant reminder that I can and should do better. I am
enlightened.
Date: Fri, 21 May 93 12:10:05 edt
From: NF
Subject: [Lockup]
------- Start of forwarded message -------
From: A Guest
Date: Fri, 21 May 93 02:56:28 EDT
Subject: Lockup
Sorry to bother, but I've noticed a tendancy of Unit's to
lock up directly after logging in, or rather, directly after
I type in my name and pass. It will just sit there. It
does echo back my characters, but nothing else.
Perhaps something is wrong with csh? Anyway, thank you for
your time.
------- End of forwarded message -------
automount + csh, what's a great combination.
*I'll* say there's something wrong with csh. It's still
wasting useful blocks of disk space that could be used for
some other buggy program instead.
Unix may be pretty bad in general, but there are programs in
particular that are even more egregious that the others.
There are some programs I'd love to be able to wipe off the
face of the earth, forever. Among them are /bin/csh,
/usr/ucb/vacation, and automount. That's just the *top* of
the list.
From: JL
Date: Fri, 21 May 93 23:28:08 EDT
Subject: Every Bug A Feature. An ESSENTIAL Feature.
[I've removed the original author's name and a bit of
identifying information because he was concerned about
retaliation from high-level Unix zealots who consider Unix
"strategic". If someone wants to add him to the list I can
provide the mailing address.]
Yep, I'm all too familiar with the format and usage of Unix
ar archives. I had to implement support for them in the xxx
product, which is actually a port to Unix of the yyy link
editor. It accepts both yyy object files and Unix a.out
format object files and ar archives.
Linker (either ld or xxx) processing of archives is
different depending on whether or not ranlib has been run
over the archive. If the archive does not have a
ranlib-provided symbol index in it, the linker searches the
symbol table of each archive element, in the order that they
appear in the archive, exactly once for names on the
unresolved external symbol list. It includes the object
file from the archive if it resolves a symbol. But if a
ranlib index is there, the Linker searches the index
repeatedly, including those modules that define external
symbols, until a pass over the index doesn't result in
including any new modules. A ranlibed archive is thus
processed similar to the way the yyy link editor handles a
library.
There is one other curious quirk in Unix archive processing.
Ranlib is a very simple-minded program and only examines the
"external" bit in symbol definitions in the a.out symbol
table. If the external bit is lit, the name is entered in
the index. This means that the index includes not only
external symbol definitions, which it should, but also
common block definitions, which it shouldn't. Finding a
name in the index thus doesn't necessarily mean that the
module should be loaded--the linker still has to process the
module's symbol table to see if the symbol that caused the
module to be loaded is really a global symbol definition and
not a common block name. Ld takes the brute-force approach
to this problem. Whenever it gets a hit in the ranlib
index, it loads the module. It then looks up the symbol
that caused the module to be loaded, and if it was really a
common block symbol, it unloads the module. The problem is,
ld has already maximized the size of any common blocks that
may have been seen in the now-unloaded module, and it has no
way to back that out. So the size of a common block is not
the maximum size declared by any module that is linked into
the executable image, but rather the maximum size that ld
ever saw in any module that it processed during library
searches.
It turns out that the Unix stdio library on bsd Unix and zzz
depends on this crock of ld processing for correct
behavior--the stdio file variable vector for stdin, stdout,
and stderr is a common block dimensioned 3 in some places
and 2 or 1 in others, depending on whether the module in
question references stdout or stderr. But the code
references element [2] in the array even if it's only
dimensioned [2] or [1]!! The stdio routines only work
because ld always loads (and usually then unloads) a module
that has the common block dimensioned [3] and so the size of
the common block is always maximized to this value. When I
first did the product, I was unaware of this dependency on a
bug in ld, I didn't have the bug, and so most programs using
stdio were dying with illegal memory accesses. It took a
week to figure out what ld was up to. We ended up writing
the same crock into xxx.
And people wonder why xxx folks tend to sneer at Unix.......
From: PD
X-Mailer: PP/Ream v4.16d (The Choice for a New Generation)
X-Subliminal-Message: Send me all your thesis ideas
Date: Wed, 26 May 93 12:36:28 +0100
Subject: When A Command Isn't A Command
Another delightful one:
Script started on Wed May 26 12:33:33 1993
(sol)1% browse
browse: Command not found.
(sol)2% which browse
/cs/research/coside/local/croissant/bin/browse
(sol)3% ls -l /cs/research/coside/local/croissant/bin/browse
-rwxr-xr-x 1 gjoly 1515 May 26 12:27 /cs/research/coside/local/croissant/bin/browse
(sol)4% /cs/research/coside/local/croissant/bin/browse
/cs/research/coside/local/croissant/bin/browse: Command not found.
And why? Because "browse" is a script, beginning
"#!long-path-name", and long-path-name is more that 14
characters.
UNIX: arbitrary length limits 'R' Us.
From: DM
Date: Thu, 27 May 93 16:49:50 EDT
Subject: Re: The Real Windows NT Implementation Story
> Date: Tue, 25 May 1993 18:34:58 -0700
> From: KB
> Subject: NT Forward
>
>
> Actually I have SOLID information that Windows NT will be
> distributed in chain letter form. Within 60 days you will
> receive a letter containing a list of names and addresses,
> along with instructions to write 10 lines of C code and
> send them to the address at the top of the list before you
> add your name at the bottom and mail copies to 84 of your
> friends. Having done that you will simply simply sit back
> and wait a few weeks to receive 12.5 million lines of NT
> source code, which you will then compile and link to form
> your NT system.
>
> DO NOT break the chain. Microsoft has spent billions
> figuring out what to do to people who break the chain.
> One beta tester forgot to mail his source code, and within
> ten days his system was attacked by a virus and then
> destroyed by a power surge. A woman told her friend not
> to respond to the pre-release letter, and within hours she
> fell into a hole and was devoured by poisonous NT bugs!
> Another man sent the letter back to Microsoft, and within
> weeks he began hallucinating and ended up in a mental
> hospital, endlessly repeating the word "downsizing".
>
> Don't tell anyone that you heard this from me.
Heck, that's pretty much how Unix evolved to where it is
today.
From: BB
Date: Fri, 28 May 93 10:21:08 PDT
Subject: [Unix Haters] Now We Can't Even Turn It Off!
Date: Wed, 26 May 93 17:15:32 -0700
From: PB
Subject: X Terminals - Update
The ban on X terminal reboots applies only to X
terminals that connect to a Sun host. All other X
terminals can be rebooted under situations that make it
necessary, but only then: there is still the potential
for problems when this is done.
Terminals attached to Sun's should not be rebooted until
FURTHER NOTICE. It appears that a change in some
configuration in the main campus computing network is
leading to some rather hairy problems on our own
network, and the terminals are the trigger for this.
ps. for the technically curious, the reason the Sun X
terminals are affected is that they normally boot
using RARP, after trying BOOTP without success. They
now believe themselves to be succeeding using BOOTP,
even though "success" means possession of an illegal
IP address.
Terminals that boot from DECstations are able to use
BOOTP directly, although it is still possible that a
race condition exists between our local BOOTP
servers and the new "helpers" in C&C's domain.
From: DW
Date: Fri, 28 May 93 23:30:34 EDT
Subject: Unix Hatred In The Outside World
"[Unix] is not vastly more user-friendly than Chinese
ideograms."
The Economist, May 22-28 1993, p. 26
From: SS
Date: Fri, 28 May 1993 23:42:22 -0400
Subject: Re: Unix Hatred In The Outside World
>Date: Fri, 28 May 93 23:30:34 EDT
>From: DW
>To:
[email protected]
>Subject: Unix hatred in the outside world
>Reply-To: DW
>
>"[Unix] is not vastly more user-friendly than Chinese
>ideograms."
That's because it's half-vast.
From: CM
Date: Mon, 7 Jun 93 22:05:35 EDT
Subject: Re: Catholicism and Unix (The Real Stuff)
Date: Mon, 7 Jun 93 18:42:58 EDT
From: JL
Forwarded to me by some with taste....
Arrgh. I sent this to an internal tla bboard that was
somehow gatewayed to subg. Here's the original post...
From: DH
Date: Tue, 20 Dec 88 01:36 PST
Subject: Charles Fort Died Too Soon
Date: Mon, 19 Dec 88 00:47:13 EST
From: MT
I believe "Chuq" is some form of usenet weenie.
Discussions of usenet weenies unrelated to the Church
of the SubGenius or other forms of genuinely bogus
spiritual violence are not particularly germane to this
forum.
Oh come on. There are those who allege that the Church is a
hoax, that the SubG are no different from your everyday
Pink. What better way to keep them guessing than by linking
the Church with a genuine hoax: the unix "operating system."
Observe that once the phone company lost its monopoly hold
on expensive, crappy phone service, they immediately
strangled the microcomputer world by cramming unix down its
throat. Now you can buy cheaper, better phone service, but
you can hardly walk by a small computer without smelling the
unwashed stench of some unix zealot. Now, as computing
power gets better, the rate of advance is slowed by the
feebleness of the operating system you're given to run on
it. And who gets a royalty on each one? The same damned
phone company!
I'd believe that it was another coup by the trilateral
commission if it weren't for the obvious hand of the roman
pontiff in all of this. I wonder how much of the Vatican's
wealth is in ATT stock? Consider the parallels:
Catholicism: Unix:
Celibacy. What else can a eunuch do?
Produced the Dark Ages by The Unix network protocols, sendmail.
reducing the spread of
knowledge and understanding
Abhorrence of Sex One's natural reaction to the typical
unix weenie.
The Inquisition Only a few schools teach Computer
Science any more. The rest is forced
memorisation of the "sh" manual.
Incense in churches Back to the unwashed bodies! (plus: dope)
Borgia Popes Bill Joy, Dennis Ritchie
The Crusades The Hordes of unwashed who splatter you
with the mucous which runs down their
chins as they shriek at you "you don't
want to do that!" when you ask
innocent questions like "What if I my
string is longer than 80 characters?"
Christmas, stolen from the "Multics? Oh yea, that was a descendent
Pagans of unix which didn't pan out. By the
way, it's spelled `Multix.'"
Botticelli, Stained Glass Stupid pictures like :-~ which mean "No
need to read any more of this message;
I left my brain in my desk in the
fifth grade and never went back for it."
Bach, Handel, Gregorians Barry Manilow, Twisted Sister
Myrrh Clearasil
Selling Indulgences No error-checking
Intolerance Case-sensitive
The Pope sided with Hitler Any unix weenie with enough brains to
find a polling place votes for LaDouche
Inability to overcome Luther, The continual re-implementation of bugs,
Calvin, and other schismatics because every program depends on them.
Cathedrals, gargoyles Unix conventions
Raping the artistic treasures How many ordinary words, like "Wizard,"
of the world for the Vatican, "Hacker," or "Filesystem" are mis-used
a millenium before Goering by unix weenies every day?
Invented stories of martyrdom Invented stories of sexual encounters by
by the early christians, in usenet "news" readers, in order to win
order to build solidarity sympathy from those gullibles who
and sympathy think it might be true.
Calls itself the universal How many mailing lists have you been on
church. Will not admit the which have been changed from "A
possibility of alternatives discussion of Z" into "A discussion of
Z in the unix environment?"
Suppression of the Jews What kind of mail will I get for sending
this to unix-wizards?
Papal infallibility Still won't admit that they should add
version numbers to the filesystem!
Look, I could go on, but there are just too many parallels
to enumerate. Unix incorporates the worst features of a
facistic religion with that most religious of
characteristics: it's a hoax that can't deliver! So I'd say
you were hoodwinked like the rest of the pinks, brother, if
you really think Unix shouldn't be discussed on the SubG
list!
The most Right-shifted Rev. Bit-Rot, C.O (Computationally Orthodox)
PS: The bit about unix conventions gets me worried. I would
like to see a film of one. I have this image of a huge
stadium, filled with those degenerate creatures from
H.G. Wells' "The Time Machine" -- were they the
Morlocs? Just imagine the whole convention floor,
filled with all manner of these vile, hairy, beasts,
gnashing their teeth, drooling acidic saliva on each
others' mis-shapen backs as they leap and shriek and
roll their eyes, arms flailing, infected claws ripping
gobbets of flesh and lancing the boils of their
fellows, only to spew the pus and other unmentionable
secretions into the crowd as the uncontrolled limbs
pass on.
From: NF
Date: Mon, 7 Jun 93 23:11:12 edt
Subject: Catholicism and Unix
>PS: The bit about unix conventions gets me worried. I
>would like to see a film of one. I have this image of a
>huge stadium, filled with those degenerate creatures from
>H.G. Wells' "The Time Machine" -- were they the Morlocs?
>Just imagine the whole convention floor, filled with all
>manner of these vile, hairy, beasts, gnashing their teeth,
>drooling acidic saliva on each others' mis-shapen backs as
>they leap and shriek and roll their eyes, arms flailing,
>infected claws ripping gobbets of flesh and lancing the
>boils of their fellows, only to spew the pus and other
>unmentionable secretions into the crowd as the
>uncontrolled limbs pass on.
Sounds like the last Usenix conference I went to.
From: NF
Date: Wed, 9 Jun 93 00:25:35 edt
Subject: [ange-ftp's ange-ftp-generate-anonymous-password]
Gee, and I thought only unix was capable of such gratuitous
lossage.
------- Start of forwarded message -------
From: SI
Date: Wed, 9 Jun 1993 05:26:53 +0200
Subject: Re: ange-ftp's ange-ftp-generate-anonymous-password
Given all the discussion of sending FQDN's as anonymous FTP
passwords, I just thought that I'd cloud the issue by
pointing out that MVS mainframes have a rather short
restriction on the password length (I don't remember what it
is off hand). Usually sending a FQDN overflows this, which
causes the FTP server to bomb out with some wonderfully
cryptic error messages.
------- End of forwarded message -------
From: DM
Date: Sun, 13 Jun 93 12:50:11 EDT
Subject: Another Indictment
I realize this is a bit tame for this forum, but it's nice
to find one's prejudices confirmed in a refereed journal.
The abstract of an article (Flater, Yesha, & Park,
``Extensions to the C programming language for enhanced
fault detection'') in the June '93 _Software --- Practice &
Experience_ begins like this:
The acceptance of the C programming language by
academia and industry is partially responsible for
the `software crisis'.
The article includes:
C will continue to be used despite its limitations,
not only because the choice of language is often
forced by external constraints, but also because
many people have become addicted to the `worse is
better' approach to design and coding.
From: RC
Date: Mon, 14 Jun 93 11:00:31 EDT
Subject: Working With Unix Is Causing Me To Have An Identity Crisis
I made the mistake of thinking that reading a Unix manual
page would provide me with useable information. The man
page for "passwd" under Solaris says:
-s Show password attributes for the login name.
-a Show password attributes for all entries. Use
only with -s option; name must not be provided.
However, when I ran it, this is what I found:
% passwd -s
passwd: cassan does not exist
% passwd -s -a
passwd: Permission denied
Nice. I don't exist, but I have a name and I am not allowed
to use the system software.
From: RH
Date: Mon, 14 Jun 93 08:55:20 PDT
Subject: Unix Under Pressure
Does the young heroine, unruffled amidst the snarls and
snaps of hunters from 65Myears ago, really pony up to the
workstation and say ``Its UNIX'', or did I, quite distressed
by the snarls and snaps, miss something critical when she
actually said ``Its not UNIX''?
From: SR
Date: Mon, 14 Jun 93 14:25:48 -0400
Subject: Re: Unix Under Pressure
Date: Mon, 14 Jun 93 08:55:20 PDT
From: RH
Does the young heroine, unruffled amidst the snarls and
snaps of hunters from 65Myears ago, really pony up to
the workstation and say ``Its UNIX'', or did I, quite
distressed by the snarls and snaps, miss something
criticial when she actually said ``Its not UNIX''?
She says, "It's Unix." A friend of mine heard shouted at
his theatre, "Be glad it's not OS/2."
I thought it was obviously Unix.
It had 2 million lines of uncommented code and no
manual.
It required a bloated, greasy guru with an inflated ego
just to reboot it.
It gave multimedia "Bad password" messages but was
totally dysfunctional at such advanced operations
as turning on the lights, phones, and door locks.
The security system was robust: lots of back doors,
while legitimate users couldn't log in with the
right passwords.
It provided the sole positive-self-esteem opportunity
for the paranoid prepubescent whose only talent in
life was getting in the way and screaming
incessantly when things didn't work (as opposed to
DOING SOMETHING about it).
From: RS
Date: Mon, 14 Jun 1993 16:09:15 -0500
Subject: Re: Unix Under Pressure
> From: RH
>
> Does the young heroine, unruffled amidst the snarls and
> snaps of hunters from 65Myears ago, really pony up to the
> workstation and say ``Its UNIX'', or did I, quite
> distressed by the snarls and snaps, miss something
> criticial when she actually said ``Its not UNIX''?
Indeed, she said "It's Unix...", and I thought I detected a
heavy tone of derision in her voice. I thought they did a
remarkably good job in that movie from a realism perspective
- everything from using out-of-the-box SGI demo packages for
most of their whizzy stuff on screen (that fly-around
filesystem browser is real, and Iris Indigos are whizzy toys
(as opposed to whizzy tools, which they'd be with the simple
addition of a real OS)) to having a major disaster of
tremendous magnitude perpetrated by a Unix weenie. Right on
the money.
From: AB
Date: Mon, 14 Jun 93 18:54:23 -0400
Subject: UNIX (In)Security
I'm trying to convince my favorite TLA official that putting
data on a UNIX machine on the TLA network is about as secure
as posting it to alt.flame. Does anyone have a document on
UNIX (in)security I could pass on?
Thanks.
AB
(Please respond directly to me; I'm not on this list.)
From: RS
Date: Tue, 15 Jun 1993 01:01:44 -0500
Subject: Re: UNIX (In)Security
> From: AB
>
> I'm trying to convince my favorite TLA official that
> putting data on a UNIX machine on the TLA network is about
> as secure as posting it to alt.flame. Does anyone have a
> document on UNIX (in)security I could pass on?
alt.flame would be inappropriate if the material in question
isn't a flame or a response to one. I suggest tla.bboard if
the data is about things of general interest (like how much
certain people make).
Or, you could just put it up for anonymous ftp with the X
sources (eww!) on export.eve.rcl.ear. Then post a "ThE
sEkrIt Tla dATa yoU hAve BeEn waItInG foR is ON
eXpoRt.eve.rcl.ear" message to misc.wanted.
Seriously, look at the Kerberos papers. Look at the Orange
Book (trusted systems evaluation manual from the NCSC).
Realize that Unix security is like swiss cheese - not a
Jarlsberg or other cheese with a few big holes in it, but an
Alpine Lace cheese with thousands of tiny holes in it which
you could never plug all of. You can wrap it in saran wrap,
but you've still done nothing for the underlying structure,
save for reducing the rate at which mold grows on it.
From: JZ
Date: Tue, 15 Jun 93 23:24:16 PDT
Subject: Mailer Vomit Du Jour
Well, for all I know, Anon's mailer doesn't even run under
Unix, but every time it pukes something my way I can't help
but think that it's every bit as fouled up as sendmail, so
I'll assume that it's Unix just to keep my animosity
focused.
Anyway, I found the return address here mildly entertaining.
Who is this Clayvin Parc guy, and why is he taking a
personal interest in my problems?
-- Jamie
------- Start of forwarded message -------
Date: Tue, 15 Jun 1993 23:15:11 PDT
From:
[email protected] (A Mail Service)
Subject: Undeliverable mail
Reply-To:
[email protected]
The enclosed message could not be delivered to the following
recipient:
[email protected] -- no such user
- - - - - - - - - -
[...]
------- End of forwarded message -------
From: SR
Date: Wed, 16 Jun 93 12:10:35 -0400
Subject: Logging A Copy Of Your Interactive SENDs
Hi, all.
Didn't there used to be a day when you could send an
interactive terminal message over a network and:
[a] it would pretty much ALL get there (not just the
first N bytes)
[b] you could review a log of all sends you'd received
since logging in, just in case your screen scrolled?
:PRSEND on ITS, for example?
It's 1993. UNIX still hasn't figured out how to do this.
Project Loki, the pathetic Unix-steeped remnant of a
university which once knew something about computers (TLA),
has a great solution: ZEPHYRgrams. They often reach their
destination. And as long as they're only a couple of lines,
they even reach their destination intact.
But beware! If you miss a Zephyrgram because your Emacs is
refreshing the screen, hey, that's life.
I wanted my Zephyr client (ZWGC) to copy messages to a file
so I could do a :PRSENDS. An Loki friend suggested
several intuitive solutions. He pointed out that the "best"
way is to modify the Zephyrgram client description file,
according to the man page, so it automatically logs
messages.
Sure enough, ZWGC has an entire embedded programming
language (they used to teach us to add things called
"features" to our programs, so our users didn't need to
learn another embedded language to use something that just
receives interterminal messages). Alas, none of the
statements in the documentation that would be used to
implement log files have examples supplied, and several
hours of playing were unable to get them to stop breaking
ZWGC.
Maybe if I send a long enough Zephyrgram, it will overwrite
a stack frame somewhere, enabling me to create a virus which
will restore some semblance of design and robustness to an
otherwise bleak and empty universe.
Date: Wed, 16 Jun 93 11:46:06 -0400
From: <name removed to protect the innocent>
From: SR
[proposed solution]
I would expect you to get two copies of every zgram with
that.
One way would be to put "set skip_tty_startup" in your
~/.environment
...
Alternatively, you could still run two zwgc's, and use:
/usr/etc/zwgc -ttymode > /tmp/alllus-sends &
so that the second one only writes to the file, instead
of going both to the file and your screen.
Finally, you could copy /usr/loki/lib/zephyr/zwgc.desc
to ~/zwgc.desc, then edit it a bit to get each and every
zwgc you run to both display and log zgrams. This is
probably the best solution, but I'm not going to take
the time now to figure out how. Read the zwgc man page
and figure it out!
From: PB
Date: Thu, 17 Jun 93 00:22:08 EDT
Subject: Re: Mailer Vomit Du Jour
From: JZ
Subject: Mailer Vomit Du Jour
Well, for all I know, Anon's mailer doesn't even run
under Unix
Vomit was an apt choice of words!! Anon.COM appears to run
the eunichs mailer "ZMailer", which replaces sendmail's
charming rewrite gruel with a customization language not
unlike the bourne shell! So at least they didn't invent a
NEW bogus "language"! Bah Humbug!! COMSAT, X/MMAILER did
just FINE without "customization languages" and "rewrite
rules".
A VAX weenie once asked me what I did with the extra four
bits. A slightly more knowledgable VAX weenie piped in
"NOOPs!" Damn Straight, and I miss 'em all.
From: DM
Date: Tue, 22 Jun 93 22:08:51 EDT
Subject: Seen On A Screen At USENIX
noone@baltic:/tmp_mnt/home/gp2/noone/$ host 153.16..1.28
Segmentation fault (core dumped)
noone@baltic:/tmp_mnt/home/gp2/noone/$ host 153.16.1.28
term28.conference.usenix.org 153.16.1.28
From: RS
Date: Wed, 23 Jun 1993 01:49:44 -0500
Subject: Re: Seen On A Screen At USENIX
> Subject: Seen On A Screen At USENIX
^^^^^^^^^^^^^^^^^^^^^^^^^^
Gee, DM, glad to see you're making such, ah,
@i{constructive} use of your time. Maybe next summer you
could sponsor a tiddlywinks marathon instead?
By the way, this was forwarded to me by one of the folks I
work with:
------ Forwarded Message
>From <Name deleted to protect the innocent> Tue Jun 22 11:42:40 1993
Subject: Forwarded: MTBF daemon
From the net:
Sun Microsystems has long been aware that too high a value
for system MTBF (measured in days or fractions thereof)
leads to a stultifying sense of boredom and complacency on
the part of the network administrator.
Thoughtfully, SUN has incorporated the little-known MTBF
daemon, which is quietly spawned at boot time, to ensure
that all users are exposed to the excitement of real
breakdowns at reasonable intervals. MTBFd is intelligent
insofar that it automatically detects the busiest server on
the network and grafts itself onto the server's sendmail
daemon. Lifeboat simulations are no substitute for that
first actual file-scrambling catastrophe. Quoting the MTBFd
(8) man page, "it's not actually data corruption, as we use
a special write-only encryption algorithm."
The initial panic and wringing of throats soon gives way to
the familiar elation of the front-line soldier under fire:
sinews are stiffened, blood is summoned. Site-wide
solidarity is magically rewoven as an almost forgotten
camaraderie emerge to weather the blitz.
"For the system administrator shall lie down with the
controls engineer, yea, even the simple coder shall lie down
with the OI group leader." -- St. Presper's Epistolary
Update to the Pascalites, Release V, Level 1.2.
The traditional supplier/user frictions also, suprisingly,
disappear since the user is now, as it were, a born-again
nonuser, and by definition a prospect for *something*.
Long-forgotten salespersons will arrive to offer condolences
and quotations for extended and enhanced service: contracts,
add-ons, RAID systems, UPSes, upgrades, and newly-released
allegedly working software.
Eventually, the peaceful boredom of uptime will be restored,
prisoners exchanged, scapegoats tried and executed,
memorials erected to lost files, and a candle placed on the
console to honor the Unknown Coder.
------ End of Forwarded Message
Date: Wed, 23 Jun 93 09:42:11 EDT
From: JL
Subject: Re: Seen On A Screen At USENIX
Sun Microsystems has long been aware that too high
a value for system MTBF (measured in days or
fractions thereof) leads to a stultifying sense of
boredom and complacency on the part of the network
administrator. Thoughtfully, SUN has incorporated
the little-known MTBF daemon, which is quietly
spawned at boot time, to ensure that all users are
exposed to the excitement of real breakdowns at
reasonable intervals....
Typical pile of Sun marketing hooey. MTBF daemons have been
part and parcel of Unix implementations since at least V5.
The only thing Sun has done is pick a fancy name for code
that's been integrated into the kernel for years.
From: MN
Date: Mon, 28 Jun 1993 11:55 -0400
Subject: A Sad Comment On The Times
One of the more common tasks of as system administrator
is helping users recover lost or corrupted files.
from "DEC OSF/1 Guide to System Administration", Feb. 1992,
page 9-1.
Date: Mon, 28 Jun 1993 12:51 -0400
From: SM
Subject: Re: A Sad Comment On The Times
Date: Mon, 28 Jun 1993 11:55 EDT
From: MN
One of the more common tasks of as system
administrator is helping users recover lost or
corrupted files.
from "DEC OSF/1 Guide to System Administration",
Feb. 1992, page 9-1.
I presume they said "lost or currupted" to hide the real
breakdown of 99.44% of files lost due to accidentally misuse
of, or typos in, an "rm" command, and 0.36% due to actual
corruption.
Admitting that most of this work could be saved by fixing a
longstanding user interface land mine might actually cause
(dare I say it?) an *improvement* to take place in Unix, and
we certainly couldn't have that.
From: JL
Date: Tue, 29 Jun 93 16:16:00 EDT
Subject: When All You Have Is A Crowbar,
The World Looks Like A Pile Of Junk
In article <whatever> (GZ) writes...
> UNIX have a facility called cron, which allows
> commands to be at regular times without having to
> hold them on queues. Does VMS have anything similar?
There is a PD cron for VMS. The pertinent
difference between putting something in a queue or
putting it in a crontab escapes me. I wish I had
real queues on my UNIX machines.
(I wish I had no UNIX machines.)
From: JL
Date: Tue, 29 Jun 93 16:19:09 EDT
Subject: When All You Have Is A Crowbar,
The World Looks Like A Pile Of Junk
In article <whatever> (GZ) writes...
> UNIX have a facility called cron, which allows
> commands to be at regular times without having to
> hold them on queues. Does VMS have anything similar?
There is a PD cron for VMS. The pertinent
difference between putting something in a queue or
putting it in a crontab escapes me. I wish I had
real queues on my UNIX machines.
(I wish I had no UNIX machines.)
From: JL
Date: Tue, 29 Jun 93 16:31:29 EDT
Subject: When All You Have Is A Crowbar,
The World Looks Like A Pile Of Junk
In article <whatever> (GZ) writes...
> UNIX have a facility called cron, which allows
> commands to be at regular times without having to
> hold them on queues. Does VMS have anything similar?
There is a PD cron for VMS. The pertinent
difference between putting something in a queue or
putting it in a crontab escapes me. I wish I had
real queues on my UNIX machines.
(I wish I had no UNIX machines.)
From: RS
Date: Tue, 29 Jun 1993 19:02:08 -0500
Subject: Re: When All You Have Is A Crowbar,
The World Looks Like A Pile Of Junk
So, JL, why'dja send us *three* copies of that? Don't you
trust my Unix mailer?
> rs@node [5] % telnet node 25
> Trying... Open
> 220 node.com Sendmail 911016.SGI/930401.RS ready to puke on your shoes
> at Tue, 29 Jun 93 19:00:04 -0400
From: JL
Date: Tue, 29 Jun 93 20:58:57 EDT
Subject: Re: When All You Have Is A Crowbar,
The World Looks Like A Pile Of Junk
Ahem. The three copies were my fault. The mailer here
glitched and I thought the two earlier attempts had gotten
lost. Wrong.
I wasn't going post this to UNIX-HATERS since this
particular mailer happens to run on VMS; but two people have
already asked so....
I know, I know, UNIX-HATERS is supposed to be for flames.
Well, this is an apology.
Then again: Unix means never having to say you're sorry.
You don't even have to SUGGEST that it's the system's fault
- that's assumed.
From: PB
Date: Tue, 29 Jun 93 23:45:02 EDT
Subject: Register Your Protests!!
Do your part in stamping out Berkeley revisionism!!
Next thing they'll re-write SMTP to conform to sendmail!!
From
[email protected] Fri Jun 25 15:12:21 1993
Date: Fri, 25 Jun 93 14:48:12 -0400
Subject: Last Call: The Finger User Information Protocol to Standard
The IESG has received a request to consider RFC1288 "The
Finger User Information Protocol" as a Standard. This has
been reviewed in the IETF but is not the product of an IETF
Working Group.
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send any
comments to the
[email protected], or
[email protected] mailing lists by July 09.
JS
IESG Secretary
From: BB
Date: Tue, 29 Jun 93 21:57:37 PDT
Subject: Unix Haters - What Does This Mean?
Return-Path: <
[email protected]>
Date: Wed, 30 Jun 93 00:17:58 -0400
From:
[email protected]
Subject: Waiting Mail
After 4 days (107 hours), your message to the following
people:
[email protected] (host=some)
has not yet been delivered. Attempts to deliver the message will
continue for 0 more days. No further action is required by you.
^^^
Oh yeah?! Zero more days? So what happened?
What will happen? The unexpected, for sure,
after all, this in unix...
----- Queued message begins -----
Date: Fri, 25 Jun 93 09:48:15 PDT
From: AB
Date: Wed, 30 Jun 93 12:33:46 -0400
Subject: My mail to
[email protected]
Please inform RB, when he returns from his much-needed
vacation, that there is a problem with the vacation program
that produced the message below. The problem is that the
message-id in the In-Reply-To field is the -only- hint it
gives me about which message of mine it was that prompted
this response. I suppose I can search through various
mailer logs to see if I can figure it out, but that seems
like a lot of trouble to put me through.
In fact, I have no memory of sending RB any mail at all, so
I'm concerned that it might be about something important
that I have forgotten. Furthermore I have no memory of who
RB is, and this message doesn't include his last name. I
can guess his last name starts with a B, but a quick flip
though my rolodex doesn't turn up any RB's among the B's.
After we get this all straightened out, someone should
really complain to the authors of the vacation program and
ask them to fix its obvious deficiencies. We wouldn't want
this to become a commonly used program in its current state
-- where it's more likely to be annoying and confusing than
useful.
Date: Tue, 29 Jun 1993 22:46:09 -0400
From:
[email protected]
Message-Id: <
[email protected]>
To:
[email protected]
Subject: Your mail to
[email protected]
In-Reply-To: <
[email protected]>,
from AB
Reply-To:
[email protected]
Your mail is being routed by an automatic
message-handling program.
I am on a much-needed vacation and will not be able to
look at or respond to your email for a while. Your
message is important, though, and it has been saved to
read when I get back.
If you need to reach someone with Nowhere Nohow Noway
when I'm out, try sum1@non1 (DK),
[email protected]
(PL), or
[email protected] (DM).
My (new)
[email protected] (TB)--will handle
any correspondence of a personal nature.
Thanks!
Home:
[email protected] __ Work: <TBA>
From: SS
Date: Wed, 30 Jun 1993 13:11:08 -0400
Subject: Montezuma's revenge, or, vacation viruses
Y'see AB, you need to get RB a new, improved vacation
program.
No need to search my mailbox any further back than this
morning to find an example of gleefully automated
imbecility.
>Date: Tue, 29 Jun 93 23:21:01 -0500
>From: AS
>Posted-Date: Tue, 29 Jun 93 23:21:01 -0500
>Subject: AS is away until July 1
>Apparently-To:
[email protected]
>
>Hi y'all,
>
>AS's vacation bot here. AS is away...
>
>As it is, I'll carefully preserve your message about
>"$SUBJECT" in that file over there until she gets back on
>the 11th...
Oh yeah, tell me once again why it needs an "Apparently-To:"
field?
From: NF
Date: Wed, 30 Jun 93 15:54:11 edt
Subject: Vacation Lossage
The list of unix programs that lose is quite long, but the
top three on my list (in the "rm with extreme prejudice"
category) are `vacation', `automount', and `csh', in that
order.
I have gotten so angry with the vacation program that I have
taken to removing people from mailing lists when they send
me cryptic messages saying they're on vacation and won't be
able to answer my mail. Like I give a damn.
From: RB
Subject: My First Perl Program
To the person who posted the text of my vacation message to
this mailing list:
Shame on you. This was my first perl program, and aside
from not detecting or pointing out to the recipient that my
vacation message might have come to you via my membership in
a mailing list to which you posted rather than from a
private message directed to me, the program ran flawlessly.
I'd appreciate greater consideration for the difficulty of
crafting software to handle the many nuances of email
transmission. (Having subscribed to a variety of mailing
lists, I can state with certainty that writing a
general-case program to handle Sender, Reply-To, From, and
Subject headers and dispatch them based on potential list
membership would be quite a job, since there isn't a
standard for mailing list management software.)
Fear not that this particular vacation program will fall
into the hands of anyone else. But I think posting my
personal message, with personal contact information, to a
mailing list like this was UNCALLED FOR.
Thank you.
-RB
P.S. Why the arrogance, anger and hostility in your
posting, anyway? It was such a trivial issue to deal with.
You could have ignored my message, or at most sent me and my
postmaster a bug report. Why a broadcast flame?
From: JL
Date: Thu, 1 Jul 93 00:04:13 EDT
Subject: Re: Vacation Lossage
The list of unix programs that lose is quite long,
but the top three on my list (in the "rm with
extreme prejudice" category) are `vacation',
`automount', and `csh', in that order.
I have gotten so angry with the vacation program that I
have taken to removing people from mailing lists when
they send me cryptic messages saying they're on
vacation and won't be able to answer my mail. Like I
give a damn.
The RIGHT solution is to create a new newsgroup,
alt.houses.owner.away, and forward any such messages to the
group. Append a finger listing - preferably one with a home
address - if available.
Word will get around.
From: WY
Date: Wed, 30 Jun 1993 19:21:32 PDT
Subject: Now THAT's Progress
[Technically isn't hate mail about Unix, but rather the "C
family" of programming languages. Still, as the twig is
bent...]
From the "Acknowledgments" section of Scott Meyers' book
"Effective C++:
"In the two decades that have passed since [I first learned
to program], I've moved from a 110-baud teletype to a
12-MIPS workstation, and from BASIC to C++"
So several orders of magnitude improvement on the hardware
side and nearly imperceptable movement (forward or backward,
take your pick) on the programming language front.
Hell, he probably moved from DTSS to Unix along the way too.
From: RS
Date: Thu, 1 Jul 1993 10:11:36 -0500
Subject: Re: My First Perl Program
> From: RB
>
> Shame on you. This was my first perl program, and aside
> from not detecting or pointing out to the recipient that
> my vacation message might have come to you via my
> membership in a mailing list to which you posted rather
> than from a private message directed to me, the program
> ran flawlessly.
>
> I'd appreciate greater consideration for the difficulty of
> crafting software to handle the many nuances of email
> transmission.
A friend who's also on Unix-Haters sent me this offline
commentary:
Is this guy kidding, or what? I sure hope so, because
he needs to be killed otherwise... what a whiner! "perl
is too hard! whine whine snivel" Try a real language
next time, like lisp!
I say, maybe you ought to get your Commodore PET out and go
back to programming BASIC. Unix-Haters is for flaming about
flaws in Unix (of which there are plenty), not for passing
the buck about your inability to code, inability to design
software, inability to test software, or inability to cope.
*YOU* voluntarily made a decision to write software that
deals with the nether regions of the Unix mailer. Don't
come whimpering to *us* when you discover that it's a dark,
spoogey place; we already knew that.
*YOU* also voluntarily made a decision to put your first try
at a new programming language on public display by making it
critical path for your e-mail. When it embarasses you, you
should think about your poor judgement rather than flaming
people for not cutting you slack since it was your first try
with a new language.
> (Having subscribed to a variety of mailing lists, I can
> state with certainty that writing a general-case program
> to handle Sender, Reply-To, From, and Subject headers and
> dispatch them based on potential list membership would be
> quite a job, since there isn't a standard for mailing list
> management software.)
Bullshite. Does the "To:" field contain your name? If not,
keep the drivel about when you're not going to be around to
yourself.
If it does, try to finger the reply-to address. Except in
very rare instances, you can't finger a mailing list (unless
some loser set up an admin account that matches the list
name when fingerd does fuzzy matching). If you can't finger
it, then don't send the gd vacation message. Fair enough?
If you get a hostname lookup failure, then send the message
anyway, since nobody is stupid enough in 1993 to run a mail
burster on a machine that isn't actually on the internet.
And if they do, they deserve to lose.
> Fear not that this particular vacation program will fall
> into the hands of anyone else. But I think posting my
> personal message, with personal contact information, to a
> mailing list like this was UNCALLED FOR.
If you had made just one more error in your program, it
would have gone to the list anyway. What's your gripe?
Oh yeah, and about the hostility in our messages, this is
the unix-HATERS list, not the WCTU tea party list. Get a
grip. Deal.
And post something about how bad Unix sucks rather than
whining about your ability to test your own code before you
put it into production, or I'll start the petition
circulating to have AB kick your sorry a$$ off of Unix-
Haters.
Sheesh. I feel much better now. A good flame is an even
better breakfast than steak, eggs, espresso, and a bagel.
Good Morning...
From: IH
Date: Thu, 1 Jul 93 09:08:07 EDT
Subject: My First Perl Program
Dear Sir,
I appreciate your hurt feelings. I understand both that
writing proper mail-groveling software is difficult and that
you do not feel that others should criticize programs that
you write for your personal use. However, by installing the
program as a network daemon, you have thereby -forced-
others to use it too.
If you wrote a quick hack as your first perl program, I
doubt that you would send it to comp.sources or sell it for
$400 to PC users. But by setting it up so that it gets run
automatically every time someone sends you a message, you
have forced more people to run it, involuntarily, than would
have run it if you had posted it to comp.sources in the
first place.
Imagine that you wrote new software for your internet
gateway and it started spraying bogus routing packets around
the internet. Such things have happened in the past, and
they have brought large chunks of the net to a standstill.
Would it then be appropriate to respond that it was your
first C program?
The question is not whether it is a reasonable expectation
that you get a program right the first time when programming
in a new language, but whether it is a reasonable action to
force a large number of strangers to use it when you have
already decided that it is not a reasonable expectation that
it will work the first time.
From: GP
Date: Thu, 1 Jul 1993 11:34:37 -0500 (EDT)
Subject: Re: My First Perl Program
I don't know, seems about par for UNIX for untested, hacked
together software, thrown together on a whim and without
planning to be forced upon the entire universe without
warning. Sounds like sendmail... or finger.... or almost
any other unix utility.
>
> The question is not whether it is a reasonable expectation
> that you get a program right the first time when
> programming in a new language, but whether it is a
> reasonable action to force a large number of strangers to
> use it when you have already decided that it is not a
> reasonable expectation that it will work the first time.
>
From: RC
Date: Fri, 2 Jul 93 13:36:54 EDT
Subject: I Just Received This From A Friend Who Is Not On This List
**** Forwarded Message Follows ****
From: GL
Date: Fri, 2 Jul 93 13:15:56 EDT
Subject: ld Is Sure Robust
>ld -o
Segmentation fault (core dumped)
**** End Forwarded Message ****
From: RS
Date: Fri, 2 Jul 1993 14:52:31 -0500
Subject: Re: I Just Received This From A Friend Who Is Not On This List
Ahem. Maybe you forgot that you're supposed to read the
manual page and be intimately familiar with software before
you use it. Moreover, you are not allowed to make typos,
and should always say exactly what you mean. If the people
at Berkeley and AT&T had spent all their time implementing
error handlers and doing sanity checking on their code, Unix
would never have gotten to where it is today!
Unix - The Choice of a Screwed Generation
> From: RC
>
> From: GL
> Date: Fri, 2 Jul 93 13:15:56 EDT
> Subject: ld Is Sure Robust
>
>
> >ld -o
> Segmentation fault (core dumped)
> **** End Forwarded Message ****
From: GR
Date: Fri, 2 Jul 93 15:50:05 -0400
Subject: I Just Received This From A Friend Who Is Not On This List
|
| From: RC
| Date: Fri, 2 Jul 93 13:36:54 EDT
|
|
| **** Forwarded Message Follows ****
| From: GL
| Date: Fri, 2 Jul 93 13:15:56 EDT
| Subject: ld Is Sure Robust
|
|
| >ld -o
| Segmentation fault (core dumped)
| **** End Forwarded Message ****
|
What sort of stinking Unix-like flame is this? You've done
the same thing that ld did, but with your problem. You just
report that it happened, you don't amuse us or enlighten us!
I'm getting really sick of people copying a tiny transcript
of some well-known-to-be-broken Unix utility (as if there
were any that are not broken) and merely forwarding it to
the list without spending the time to write a
seriously-obnoxious, intensely-abusive flame.
If you are not willing to take the time to pour out your
bile on all of AT&T, Berkeley, Ken Thompson, Bill Joy, and
everyone else involved (they are all guilty by association)
in this comedy of stupidity, errors, and infinitely poor
judgement called Unix, don't send a message!!!
Heck, if I wrote a message like the above every time that
Unix screwed me, you would not have time to do whatever your
employer pays you to do, since you would be busy hitting the
#\D key in your favorite losing mail-reading utility trying
to flush the infinitely long stream of tiny transcripts
spewing from my mailer.
Think before you act! You don't deserve to be on
unix-haters if you don't. If there is anything that Unix
programmers can be characterized by is precisely that they
don't do that (of course, they don't think at all).
AB, isn't it time for a new shakedown? I'm starting to hit
the #\D key every time that I see a message addressed to
unix-haters.
From: RC
Date: Fri, 2 Jul 93 16:26:10 EDT
Subject: Re: I Just Received This From A Friend Who Is Not On This List
| From: RC
| Date: Fri, 2 Jul 93 13:36:54 EDT
|
| **** Forwarded Message Follows ****
| From: GL
| Date: Fri, 2 Jul 93 13:15:56 EDT
| Subject: ld Is Sure Robust
|
| >ld -o
| Segmentation fault (core dumped)
| **** End Forwarded Message ****
What sort of stinking Unix-like flame is this? You've
done the same thing that ld did, but with your problem.
You just report that it happened, you don't amuse us or
enlighten us!
Sorry, but I don't see any indication that ld reported
anything at all. But hey, this is Unix. Why should ld have
to report anything when it has got the csh there to print
one of its two universal diagnostics for it? And as an
additional bonus it left me 8491440 bytes of data in a file
I didn't ask for in case I wanted to run a debugger to find
out what the command line arguments are (provided the
debugger doesn't create another such file on top of the one
it is trying to examine.) Much more thorough than simply
providing a readable help message, no?
Heck, if I wrote a message like the above every time
that Unix screwed me, you would not have time to do
whatever your employer pays you to do, since you would
be busy hitting the #\D key in your favorite losing
mail-reading utility trying to flush the infinitely long
stream of tiny transcripts spewing from my mailer.
You are absolutely right. It is the end of another five day
period of dealing with this sorry excuse for an operating
system and it has apparently affected the way I deal with
the world. Before I sent that message I had been thinking
that there had been too much trivial traffic on unix-haters
lately, and yet I went right ahead and mailed it without
thinking twice. My apologies. Maybe I'll recover over the
weekend.
From: JL
Date: Fri, 2 Jul 93 16:37:07 EDT
Subject: Re: I Just Received This From A Friend Who Is Not On This List
> From: RC
>
> From: GL
> Date: Fri, 2 Jul 93 13:15:56 EDT
> Subject: ld Is Sure Robust
>
> >ld -o
> Segmentation fault (core dumped)
> **** End Forwarded Message ****
Ahem. Maybe you forgot that you're supposed to
read the manual page and be intimately familiar
with software before you use it. Moreover, you are
not allowed to make typos, and should always say
exactly what you mean.
What in heaven's name makes you think the user here didn't
read the manual page, was not intimately familiar with the
software, committed a typo, or didn't mean what he said?
Do you see something on the ld manual page, or anywhere in
the Unix documentation, that says that ld ISN'T supposed to
dump core when invoked this way? Did you ever consider the
possibility that the far-seeing developers INTENDED THIS TO
HAPPEN? What do YOU think "ld -o" means?
If the people at Berkeley and AT&T had spent all
their time implementing error handlers and doing
sanity checking on their code, Unix would never
have gotten to where it is today!
Oh, but they DID! After all, the system didn't crash in
response to the segmentation fault. It got trapped, and an
error message got printed. While it isn't shown, chances
are pretty good that the user got his prompt back. This
isn't MS/DOS, you know!
You want them to waste time writing ADDITIONAL error
handlers and sanity checks into every little junky program
like ld? That's against the Unix philosophy! Each tools
does ONE thing. ld links object files.
Checking for errors and printing error messages is someone
in else's bailiwick. (You know, I wonder if any of the Unix
philosophers spent a few decades working in some big
bureaucracy, where the operative pharse was "It's not my
job".)
Unix - The Choice of a Screwed Generation
Screwed UP Generation.
From: BK
Date: Fri, 2 Jul 1993 15:14:01 PDT
Subject: ld Loses, So What Else Is New?
From: JL
Date: Fri, 2 Jul 1993 13:37:07 -0700
> From: RC
>
> From: GL
> Subject: ld Is Sure Robust
>
> >ld -o
> Segmentation fault (core dumped)
Did you ever consider the possibility that the
far-seeing developers INTENDED THIS TO HAPPEN? What do
YOU think "ld -o"
I got curious about this after I discovered that the 'ld' on
my Sun-4 did this too. I went and looked at the source for
'ld'. Don't do this just after lunch, that's a BIG mistake.
IN fact, looking at the source at all was a serious mistake.
Ecch.
This stupid program scans its argument list not once, not
twice, but at least THREE times that I could find. I
couldn't stomach any more searching. After I found two
places where a '-o' option with no trailing argument would
provoke a segmentation fault, I stopped looking.
It's just sloppy coding. There's no excuse for it. The
first loop over the arguments (looking for the zflag,
whatever the hell that is) just blithely increments the
argument index when it sees '-o'. Next time around the
loop, it gets incremented again and POW! you're off the end
of the array.
The funny thing is, this shite wasn't in there when I hacked
on ld back in the mid-80's. Sure enough, looking along a
little farther, I find
case 'o':
if(++c >=argc)
error(1, "-o: arg missing");
of course, this is in the third pass over the args, by which
time it's too late!
Those bozos at Sun screwed up another perfectly good
program. Well, OK, they made an already mildly losing
program lose BIGTIME.
And I haven't even gotten into the guts of the program, this
is still just the ARGUMENT PROCESSING! Ghreat Ghreen Ghods
above.
Excuse me, I have to go throw up now.
From: AB
Date: Sat, 3 Jul 93 20:35:17 -0400
Subject: Passing The Flame
Date: Fri, 2 Jul 93 15:50:05 -0400
From: GR
...
What sort of stinking Unix-like flame is this?...
Think before you act! You don't deserve to be on
unix-haters if you don't....
AB, isn't it time for a new shakedown? I'm starting to
hit the #\D key every time that I see a message
addressed to unix-haters.
I fear that I have become burned out in my role as guardian
of the vitriol, chief hate-monger, grand disciplinarian, and
most exalted screaming maniac.
More and more often, things are happening to me that should
make me compose a rant for Unix-Haters, but I can't seem to
summon the energy. For example, I recently learned of
several new ways in which NFS fails to be an actual file
system, I have discovered that one Unix vendor's manual
pages have been rendered almost useless by over-zealous
technical writers, and I have been shafted in multiple ways
by the Unix/Kerberos notion of "security". In none of these
cases have I shared my righteous wrath with you all.
Thus I have felt for some time that I should pass the flame
on to someone who still can summon up a good head of steam
when necessary. In fact, several weeks ago I picked 10
members of this list and asked them to form a nominating
committee to pick a new Unix-Haters Czar -- or suggest some
other way of reorganizing me out of a job. After some brief
discussion, this effort failed to produce any results.
So when I got GR's flame quoted above, I immediately went
downstairs to his office and asked him if -he- would
consider being the new Unix-Haters Czar. He accepted.
We haven't worked out the details yet, but starting with
this message, GR's word is law. I'll still be on
Unix-Haters-Request (along with PB and MP), so I might
answer your request to change your address, but you won't be
hearing from me in this forum again except as a regular
contributor.
Keep the faith: it -can- be better than Unix.
From: SS
Date: Tue, 6 Jul 1993 21:22:11 -0400
Subject: Worst Manual Of The Year Competition
You know what to do.
----
Date: Tue, 6 Jul 93 21:15:06 -0400
To:
[email protected]
From: GH
Subject: THE WORST MANUAL OF THE YEAR competition
FROM:
The Anonymous Company
666 La Ha See Enda, N.N.
LowDown, ZZ 99999.
Call: (666) 999-9999
Fax: (666) 999-9999
FOR RELEASE JUNE 22, 1993
THE WORST MANUAL OF THE YEAR:
A COMPETITION FROM HELL
If you've ever felt let down by a VCR manual,
frustrated by your computer's documentation, or downright
crazed by the instructions for some toy, here's your chance
to fight back. You can nominate that lousy manual to be
acclaimed as "The Worst Manual of the Year."
Sponsored by the Anonymous Company, a group of
experienced and fed-up professional writers, the competition
for the worst manual of the year aims to shame manufacturers
into providing manuals we can actually use. The best
consumer companies have improved a lot, over the last few
years, says JP, President of the Anonymous Company Circle.
But there are still too many bad manuals out there. You
usually can't find what you need, and if you do find it, you
can't understand what they're saying, or the diagram's such
a mess you give up.
JP urges you to send in those abominable manuals.
Look through your pile of manuals and send us the one that
helps you the least, frustrates you the most, and generally
makes your life miserable. Write a short note saying why
you're nominating this book as your candidate for the Worst
Manual of the Year. We don't care what year it was printed;
if you used it this year, and you hate it, tell us why.
If your candidate wins (or places), you get a custom
T-shirt showing the cover of the manual selected as Worst
Manual of the Year, with the slogan, I fingered the Worst
Manual of the Year, 1993. As a bonus, you get a copy of
JP's Book That Needs Publicity, and a certificate of honor
in the war against useless manuals.
The Anonymous Company will announce the Worst
Manual of the Year to the press on December 7, 1993;
distribute copies of your letters (anonymously if you wish);
and award the offending company a garish Certificate of Bad
Taste. To correct their errors, the company will also
receive a copy of How Not To Do Anything by JP and HK. So
scan those shelves. Which manual has caused you the most
grief this year?
Mail the book with your complaints to:
The Worst Manual of the Year
c/o The Anonymous Company
666 La Ha See Enda, N.N.
LowDown, ZZ 99999.
Absolute last-chance deadline for submitting monster manuals:
Halloween, 1993.
This press release has been distributed widely across the
internet. But if you know another list or a personal net-friend
who might want to read it, please forward it on.
If you have any questions about the contest, please write
N. O. Wun at
[email protected]. Please don't send
descriptions of manuals via e-mail, though. We need to get
those, along with a copy of the horror text, in the mail.
Please let us know when you send in the manuals on what list
you saw this release.
Thanks for reading, and go get those miserable manuals!
###
From: MM
Date: Wed, 7 Jul 93 21:32:59 -0700
Subject: I Think I Understand Unix Better Now
This isn't really a complaint about Unix. In fact, I will
actually offer a slight amount of praise -- at the end, of
course. What I really want to talk about is how I suddenly
grew to understand the implications of the Unix philosophy,
and how it appears to be permeating our society.
Today, I tried to phone someone who works at Sun World
and/or Next World magazines. I called their main number and
was dropped into an automated voice-mail telephone operator
system. Press 1 for this, 2 for that, and never a press to
reach a human. No options reached a department: either you
knew how to spell the person's last name, or you wandered
endlessly in a maze of twisty little passages, all alike,
until you stumbled over the rusty knife that disconnected
you.
It can truly be said that whoever designed that voice mail
system, learned the lessons of Unix to perfection: "if it
was hard to do, it should be hard to understand." The really
frightening thing is that the people who write about Unix
seem to accept this monstrosity.
Oh, yes, I was going to praise some part of Unix, wasn't
I. Well, I've been using "ed" as my editor for the past
year. It has the one, single, advantage that it is so
boringly uninteresting that no Unix Wizard has seen fit to
create ed++ and, thus, it has stumbled along for the 15
years I've suffered under the yoke of Unix slavery without
"improvements." Amazing, isn't it, how hard one must stretch
to find something -- anything -- to praise?
Happy Hacking
From: GR
Date: Thu, 8 Jul 93 01:22:27 -0400
Subject: WARNING!
As of today, I've become the new unix-haters czar or
dictator. I plan to take this duty seriously.
What this means:
- I will flush from the list people who send inappropriate
messages. I will flush them without warning, but, unlike
your favorite losing Unix utility (insert any here) I will
send them a notice telling them that I have done so.
- If the person in question is in a redistribution list, and
I cannot get the person flushed, I will unceremoniously
flush the _entire_ redistribution list. Here I will act
like "rm *" to remind the people involved how losing Unix
_really_ is so that they'll have something to flame about.
What are appropriate messages? The unix-haters welcome
message, attached at the end, should remind you.
IMPORTANT NOTE: The previous two messages sent to the list
(by GH and MM) are inapropriate. Had I sent the present
message earlier, as I had planned to, I would have flushed
both.
This will be the last warning.
------- Begin Greeting
Welcome to Unix-Haters.
Remember, every message sent to Unix-Haters must say
something bad about Unix. This rule is strictly enforced.
People have been removed from this list for merely
correcting other people's honest confusions. All
contributions should be -original- as well -- simply
repeating "Unix is Evil" for the 100th time isn't good
enough and will simply irritate the moderators. (And we're
pretty irritable since we have to use Unix too).
A good rule of thumb: If you are composing mail to
Unix-Haters, and you started with the "reply" command (you
typed "r" in emacs rmail mode), then stop right there, your
message probably doesn't belong here. Think: "would the
message I am sending still seem appropriate next week?". If
your answer is "no", then don't send it. If your answer is
"yes", then send it next week.
------- End Greeting
From: SG
Date: Thu, 8 Jul 93 06:21:28 -0400
Subject: Unix Shell Expansion Lossage
..pretending to be mail lossage....
I get this lousy mail message in the mail, then spent a good
three minutes trying to figure out what ever JG must have
done to make it happen...
Begin forwarded message:
From: JG
Date: Thu, 8 Jul 1993 04:20:50 -0400
To:
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected]
Then I get the following message. Of course it makes sense
to apply name expansion in the shell. Of course we might
want to apply it to our command names. Of course the people
who wrote csh weren't thinking...
Begin forwarded message:
From: JG
Date: Thu, 08 Jul 93 05:12:04 -0400
Subject: Sorry
I did a "*" on a line by itself, by accident. The shell
expanded it to the name of every file and directory in the
current directory (my home directory). Since the name of
the first file is my home directory (in alphabetical order)
is "Mail", the result was to send mail to the username of
every remaining file, as if I typed this:
Mail News a bin lib ....
Unfortunately, I have a directory named "amt", so this list
included
[email protected] (a.k.a. msgs).
Sorry.
Possibly interesting, but annoying.
From: AB
Date: Sat, 10 Jul 93 17:47:39 -0400
Subject: "Millions Of Chinese Can't Be Wrong"
Date: Sat, 10 Jul 93 13:26:44 -0700
From: MA
... I didnt chose to respond to the post about sendmail
being more flaky than mmdf just because I didnt want to
be a lone cry. I have had nothing but problems with
mmdf, honestly. My opinion is quite biased by the fact
that I have had NO problems with sendmail... never lost
a single message. I guess what I am really itching at is
that mmdf is compatible with next to no mail software,
where sendmail is what the internet community accepts as
standard and writes things for.
When asked what he thought about rice, Lenny Bruce
replied, "I dont know but how can millions of chinese be
wrong?"
I'm having this nightmare in which a chorus of unix weenie
pod-people chants:
"sendmail is what the internet communty accepts as standard"
"sendmail is what the internet communty accepts as standard"
"sendmail is what the internet communty accepts as standard"
over and over again, as they shuffle relentlessly towards
me, clutching hideous kludges that they claim are "Internet
Standards", that I must accept in order to be "compatable".
In vain, I throw copies of the actual Internet protocol
documents back at them in a futile attempt to demonstrate
the difference between the Internet and Unix. Copies of
RFC821 and RFC822 are simply trampled under their feet as
they close in around me. As I lose consciousness, I think
some of them have switched to chanting:
"you are number six"
"you are number six"
"you are number six"
From: JL
Date: Thu, 22 Jul 93 17:55:59 EDT
Subject: It Rots The Mind. It Saps The Will.
An error report I sent to a system support person at
Somewhere, and the reply received:
I just tried this:
---------------------------
$ passwd
Changing NIS password for summer on song.epei.edu.
Enter current password for
[email protected]:
Enter Your SecurId Access Code
or Type return <CR> if You Do NOT Use a SecurId Card:
Unable to Get Initial Credentials : Not enough memory 12
Protocol Failure - Password NOT Changed.
---------------------------
Not enough memory?!?!?!?
(The problem was "sticky" - trying it again produced the same
result.)
-- Jerry
If you type in an incorrect password, you would get this error.
See, computers are these mysterious things. (At least those
running Unix are.) Don't try to understand them. Just
accept. If your mind objects, we can fix it. Your mind,
that is.
BTW, it's worse than it appears. The problem kind of WAS an
incorrect password: I had accidentally set a 9-character
password. The same program that let me SET that password
with no complaint would not accept it for verification when
I wanted to change it. (It WOULD accept it when I left off
the 9th character.) The Epei software is "partially"
converted to Kerberos. Some of it takes 9 character
passwords; some of it doesn't. None of the error messages
you get when you use a 9 character password with software
that doesn't accept it give you any hint of what might be
wrong. "The competent programmer will know what to do."
Please tell me it doesn't always have to be like this.
Please tell me that this is only the result of force-fitting
code into 640K to run on .5 MIP machines. Please tell me
that when Unix runs on 1 MIP workstations with a few meg of
memory it will finally grow up.
What? You say this is on a many-MIP multiprocessor machine
with tens of megs of memory? And gigabytes of disk (but no
room for user stuff)? Never mind. I'll go quietly. I
promise.
ARGHHHH!!!!!!!!
From: RZ
Date: Mon, 2 Aug 93 00:30:22 -0700
Subject: "Random" Numbers And Unix
The behavior of the rand() function under Unix defies
belief. I quote below from the man page (believe it or
not).
BUGS
The low bits of the numbers generated are not very
random; use the middle bits. In particular the lowest
bit alter- nates between 0 and 1.
From: PB
Date: Mon, 2 Aug 93 13:49:11 EDT
Subject: Speaks For Itself...
From: AK
Subject: Re: Smalltalk Versus C++ (No Flame Wars, Please!)
In some article RH writes:
> A core dump is C++'s way of "delaying the objection until
> run-time"
Putting it another way:
`Method not found' is Smalltalk's way of spelling `core dumped'
From: CL
Date: Mon, 2 Aug 93 18:17:55 -0400
Subject: [A Question For The UNIX Weenies In The House]
My reply to a discussion on another list concerning shell
output redirection:
>> What's going on is that you're overflowing the *shell's*
>> output buffer. When you do <prog> > <file> you're asking
>> the shell to capture all the output from <prog> and when
>> it's done, stuff that into <file>. As you've noticed,
>> there's not much of a buffer there and when you've filled
>> it up it goes kablooie.
..producing no error message or useful diagnostic, of
course. Such wasteful civilities are obviously far beyond
the ``small is beautiful'' design philosophy of which Weenix
Unies are so fond. And you weren't actually expecting the
shell to be designed to buffer its output correctly without
segfaulting, were you? As a user, keeping system programs
from wetting their pants is, after all, YOUR responsibility.
--
%SYSTEM-F-ANARCHISM, the operating system has been overthrown
From: KP
Date: Tue, 3 Aug 1993 09:21:50 PDT
Subject: Forwarded Without Comment,
or Why Things Are The Way They Are
Identities deleted.
---------------------------------------------------------------------
Date: 2-Aug-93 19:30:02
Subject: MS/Windows Screen Saver Not Always Working
Sometimes, when I come into work in the morning, MS/Windoze
is not in a screen saver mode. Does anyone know what can
cause this, other than the fact that Windoze was written by
MicroSoft?
Last night, this happened, and I have a clock running, and a
MS-DOS Prompt opened. Can one of these force stupid Windoze
to not run the screen saver?
I was spoiled with OpenWindows on the Sun, and miss the
professional robustness.
Thanks,
..
From: RS
Date: Thu, 5 Aug 93 15:26:10 -0400
Subject: When There's Not An Error, It's An Error
From the mucus-lined vats of Old Murray Hill, we bring you
this Unix error message as a tribute to your poor taste...
No, seriously... this one's a new one on me. What is this
"There was no output on standard error" bullshit? Is
failure to produce a cryptic error message like "unknown
mailer error 255" indicative of lossage in and of itself?
Or is it a simple acknowledgement of "silent failure" as a
Unix paradigm (ie, if it doesn't create an error message,
then it *must* have failed)?
Date: Thu, 5 Aug 93 13:00 EDT
From:
[email protected] (Uucp administration)
Subject: Execution failed
Message from UUCP on ano Thu Aug 5 13:00:32 1993
Execution request failed:
rmail
[email protected]
There was no output on standard error
From: RM
Date: Thu, 5 Aug 1993 18:18:49 PDT
Subject: [New And Exciting Variety Of Nfs Lossage] ]
------- Start of forwarded message -------
From: SL
Subject: Re: [New And Exciting Variety Of Nfs Lossage]
Date: Thu, 5 Aug 1993 17:47:52 -0700
I've got this spiffy (read "inexpensive") SparcClassic. It
was running Solaris 2.1. Compared to Solaris 2.0, 2.1 was a
major advance, like electric lightbulbs over gas lamps. But
it did have this problem that it would occasionally die.
This only seemed to happen if there was a big load on the
machine, a lot of processes trying to run. And that only
happened during my nightly software build. I would come in
in the morning and find my machine totally catatonic. Even
the kiss-of-death L1-A had no effect. Fortunately Suns boot
fast.
Solaris 2.1 was also blessed with a really awful process
scheduler. If you tried to do a compile you could no longer
use X. Moving the mouse would result in nothing for large
amounts of time, followed by the little arrow on the screen
zipping way past where you wanted it to go. But that's OK.
I got used to doing a "M-x compile <RET>" and stepping into
somebody else's office to chat.
Well, along came Solaris 2.2, with promises of enhanced
performance ("90% improvement in fileserver
performance!...") So my machine got upgraded. The good
news is that the machine is noticeably faster in normal use.
Context switch time is improved; I can actually do other
things (like read netnews) while a compile is going on.
The bad news is that doing a compile often causes the system
to go into a deadlock state where it no longer fields NFS
requests. L1-A time. But that's OK, it boots fast. I've
got this chart on my wall, showing how many times a day I
have had to reboot because of this problem:
7/20 4
7/21 2
7/22 1
7/23 4
7/26 5
7/27 1
7/28 4
I've learned to not do any builds on my machine. Instead I
do builds on other machines here that are still running
Solaris 2.1. My workstation now effectively operates as a X
server. This is what is known as "progress."
------- End of forwarded message -------
From: KP
Date: Thu, 12 Aug 1993 18:19:23 -0400
Subject: Meeting Unix Robustness Standards
Heard in a talk by a vendor at a conference I was at
recently...
``The unix market has generally been more forgiving
on quality aspects.''
Gee, I always thought of the distinctive Unix level of
quality as unambiguously negative. But seen from the other
side, it has its advantage. First beat your customers into
a daze where they don't know good from bad, then lean back
and enjoy the cash flow from putting out products that meet
established expectations... Why didn't I think of that?
comehere
From: ME
Date: Fri, 20 Aug 93 18:36:32 EDT
Subject: [The Worst File System Corruption I Have Ever Seen!]
------- Forwarded transaction
[1219] Amusing_Thoughts 08/20/93 16:38 (7 lines)
Subject: The Worst File System Corruption I Have Ever Seen!
Warning: slightly esoteric Unix material follows.
A 386BSD machine here went down, and when it tries to come
up fsck reports a bad inode, number 00-1/2. That's number
one-half, using a special character that isn't in ASCII.
How do you fix a non-integral inode? (also reported a
floating exception, which is probably the real problem).
--[1219]--
------- End forwarded transaction
From: PS
Date: Tue, 31 Aug 93 16:27:17 EDT
Subject: When Worlds Collide
You know, actually, there's a very sad story behind my
sending that message. Here is the blow-by-blow description:
a) I try to send it to HDKOIS and cc it to info-explorer. I
know HDKOIS (once created -- around the time that
RandomCo was really getting into swing -- as a list for
commenting on the sad state of computer hardware at the
AI Lab; said state resulting from the exodus of skilled
hackers to RandomCo) no longer exists, but I'm using it
as a bitter comment on the inevitable arrival of the
future, the ephemerality of all things, the poignancy of
the passage of days that take with them their hopes and
worries and failures, all now as distant as those hours
in early childhood, the sun entering through the window
and making its way across the carpet through all of an
impossibly long afternoon, the crisp air, the leaves
falling outside, all gone now. All gone.
b) My wunnerful Unix mailer tells me that HDKOIS doesn't
exist, so the message wasn't sent. It really does say
that the message wasn't sent. I have run into this
before with Unix mailers; I know that occasionally,
depending on whether SM's hemorrhoids itch today,
Mr. Happy Unix Mailer will entirely punt a message to
multiple recipients just because it couldn't find one of
them.
c) Well, so just for the purpose of having this tiny bit of
fun, I create the mailing list, put a few randoms who
are no longer at the Lab on it, and re-send the message.
d) I get a message from AB telling me that there is still an
HDKOIS on MC, and if I am resurrecting the list, what do
I want done with the old one? and by the way, Mister
Think-You're-So-Funny, there IS a news reader for Lisp
Machines, ptooey.
e) I receive a copy of the second message I sent to HDKOIS
and INFO-EXPLORER.
f) I receive a copy of the first message I sent to HDKOIS
and INFO-EXPLORER, which the Unix mailer had told me
hadn't been sent.
I am depressed now, okay? Now I am sad. Not just because I
gambled with Unix -- and lost; but also because this means
that the net-news sickness did indeed make it all the way to
the Lisp Machines. Next I expect to hear that there's a
great news reader running in ITS EMACS on the KLH-10.
From: PD
Date: Thu, 2 Sep 1993 06:06:16 -0700
X-Mailer: Sendmail/Ream version 4.16b (The Choice for a New Generation)
X-Subliminal-Message: Send me all your money
Subject: Fouledup Transfer Protocol
(baker)1128$ ftp magna
Connected to magna.anon.com.
220 magna FTP server (SunOS 4.1) ready.
Name (magna:pd):
331 Password required for pd.
Password:
ftp> mget ta*
mget ta* not found? yes
200 PORT command successful.
550 ta* not found: No such file or directory.
ftp>
From: RM
Date: Tue, 7 Sep 1993 17:51:17 -0700
Subject: Re: The Trouble With Unix (Datamation, 1981)
Truth is, I don't remember the details of that article
anymore, and it is clearly superseded by my more recent
works: Articles and Books -- "User Centered System
Design"; "The Psychology of Everyday Things" (also known
as "The Design of Everyday Things"); and "Things That
Make Us Smart."
Unix makes me smart, in the same way I do after a slap in
the face.
From: JZ
Date: Wed, 8 Sep 93 02:29:13 PDT
X-Windows: Some voids are better left unfilled.
Subject: Lie To Me Baby, Lie To Me
FTP says:
13772 bytes sent in 0.06 seconds (2.2e+02 Kbytes/s)
Let's see, that works out to be 1802240 bits per second.
That's a pretty good trick, considering our connection is a
measly 56000 bits per second.
Oh, and nice of it to print "2.2e+02" instead of "220", I
thought there just wouldn't have been enough characters on
the screen otherwise.
And isn't it special how FTP will also say
Hash mark printing on (8192 bytes/hash mark).
and then proceed to print hash marks every 584 bytes
instead? But of course it only does this when doing
transfers in BINARY mode, when it's in "please-
silently-mangle-my-files-by-stripping-off-the-high-bit,-won't-you?"
mode, the number of hash marks printed corresponds roughly
to what it claimed it would be.
But in the grand unix tradition, I've gotten used to waiting
until ange-ftp tells me that 1400% of the file has been
transferred before thinking it is done, and I'm getting
faster at reading scientific notation as well. Unix made me
a better person! (Or is that bitter?)
From: AG
Date: Mon, 13 Sep 93 18:12:20 PDT
Subject: High-Level Languages
This appeared in a message requesting papers for the "USENIX
SYMPOSIUM ON VERY HIGH LEVEL LANGUAGES (VHLL)":
UNIX has long supported very high level languages:
consider awk and the various shells. Often programmers
create what are essentially new little languages whenever
a problem appears of sufficient complexity to merit a
higher level programming interface -- consider
sendmail.cf. In recent years many UNIX programmers have
been turning to VHLLs for both rapid prototypes and
complete applications. They take advantage of these
languages' higher level of abstraction to complete
projects more rapidly and more easily than they could
have using lower-level languages.
So now we understand the food chain of advanced UNIX
languages:
level languages analogous organism
----- --------- ------------------
low assembler (low-level PDP) amoeba
intermediate regular expressions tadpole
high C (high-level PDP) monkey
very high awk, csh, sendmail.cf UNIX man
From: RS
Date: Sun, 19 Sep 1993 17:57:02 +0900
Subject: More Is, Uh, Ah....
I know this is Unix-Haters not OSI-haters, and this *is*
peripherally related to Unix insofar as UUCP tossed this
error message at me. But this wasn't just *any* UUCP, it's
AT&Tmail's X-400-UUCP-on-'roids-trying-to-take-over-the-
world-as-it-swings-from-the-Empire-State-Building. You see,
in a perverse sort of way, it looks like the X.400 folks
bought a clue about "unix is too cryptic".
Too bad their UUCP bounce messages now tell me EVEN LESS
than the "too cryptic" ones I'm used to. Nice of them to
return the entire text of the message that didn't get
delivered while removing all those "useless" Received: lines
in the original's envelope so I don't have the foggiest idea
why they ended up with the message in the first place.
I especially enjoyed the fact that there are now *two*, not
*one* message IDs in the envelope of the returned message
(one of them inserted by my local machine because it
COULDN'T FIND a valid Message-ID: field in the header) oh
yeah, and a *content-id*, whatever that's supposed to mean.
It also pleases me to no end that they were kind enough to
rewrite all of my nice domain-ized headers into bastardized
bangnet format.
Report-Version: 2, huh? That's highly useful information
which I just couldn't get through life without! Is there a
Content-Type: tag for "Useless Dreck"? EMail-Version: 2...
gee, I wonder what *that* means... is it a UA version or an
MTS version? Maybe it's just a way of subtly expressing
where they are in their evolutionary process.
Oh, forget it. Where's my fax machine?
------ Forwarded Message
From
[email protected] Fri Sep 17 21:03:39 1993
Received: from stl.ano.thr by ffd.tfop.co via SMTP id AA24028
(Sendmail 911016.SGI/930401.RS); Fri, 17 Sep 93 21:03:39 -0400
Message-Id: <
[email protected]>
From:
[email protected]
Date: 18 Sep 93 00:03:27 GMT
To: rs
Report-Version: 2
Received: by /C=US/AD=ATTMAIL;Sat Sep 18 00:01:27 -0000 1993
Received: by /C=US/AD=ATTMAIL/PD=GOV+FWS;Fri Sep 17 18:03:27 -0600 1993
Confirming-Mts-Message-Id: </C=US/AD=ATTMAIL;internet2610000200>
Confirming-Ua-Content-Id: <ternet2610000200>
Original-Date: Fri Sep 17 18:03:12 -0600 1993
Not-Delivered-To: mhs!fws/S=zirbess/O=ufws due to 01 Invalid Address
Specification
Content-Type: message
Message-Version: 2
From: internet!ffd.tfop.co!rs/G="R/I="X/S=S"
UA-Content-ID: <internet2610000200>
End-of-Header:
EMail-Version: 2
Subject: Commercial Internet Service in Slobovia a reality!
UA-Message-ID: <internet2610000200>
To: internet!a
To: internet!b
To: internet!c
To: internet!d
To: internet!e
To: internet!f
To: internet!g
To: internet!h
To: internet!i
To: internet!j
To: internet!k
To: internet!l
To: internet!m
To: internet!n
To: internet!o
To: internet!p
Cc: internet!q
Cc: internet!r
Cc: internet!s
End-of-Protocol:
Content-Type: text
Content-Length: 1041
After over a year of planning and work, commercial TCP/IP
service in Lower Slobovia is at last available! At
approximately 25:00 JST (34:00 GMT) on 32 September 20000,
this new era of global connectivity was ushered in with the
turnup of the first transplanetary commercial Internet link.
Incredibly BogosCo and Acronym Corp. are strategic partners
in developing commercial Internet service in Lower Slobovia
and Inner Mongolia. We are pleased to announce our
respective new services which offer IP connectivity to any
organization in Mongolia without regard to research or
educational affiliation, and without burdensome Appropriate
Use Policies (AUPs). We at IB and AC extend our
appreciation to our US partners: BoringCo, LuserCo, and
Combined Lossage for their help in making commercial ABC/DE
service a reality in Slobovia.
For more information on commercial Internet connectivity in
Mongolia, send an inquiry via electronic mail to
[email protected] or
[email protected].
------ End of Forwarded Message
Date: Mon, 20 Sep 93 21:52:08 -0400
From: SG
Subject: Oh Boy, Just Look At These New Headers
I love it. X-Disclaimer-1. X-Disclaimer-2. Every damn
message that SS sends out from psy.cho.man gets munged this
way.
I know, I know, it's not a UNIX problem. It's a mailer
problem. But psy.cho.man is a UNIX machine. And he's
using Elm.
Begin forwarded message:
From: SS -- Personal Account <
[email protected]>
X-Disclaimer-1: psy is an OVER-CONNECT public access host.
X-Disclaimer-2: Opinions expressed are not necessarily
X-Disclaimer-3: those of III or the OVER Network.
Subject: Re: Internet article in Wall Street Journal
Date: Mon, 20 Sep 93 21:01:49 EDT
From: SG
Date: Tue, 28 Sep 93 21:51:12 -0400
Subject: Good God, They Really Want A Repeat
Of The Challenger Disaster, Don't They?
Begin forwarded message:
Date: Tue, 28 Sep 93 14:40:12 edt
From: SP
Subject: Re: [E-Mail Address Needed]
AAA said he didn't know why we got this SPACECAST 2020
abstracts call. I suspect it has to do with the fact that
Random told me once that she had been told by a
customer/designer that the Space Station design work was
mostly done with C++ programming...
From: DW
Date: Thu, 30 Sep 93 16:50:44 EDT
Subject: Segmentation Violation -- Core Dumped Blues.
[Removed forwarding headers etc.]
Well, my terminal's locked up, and I ain't got any Mail,
And I can't recall the last time that my program didn't fail;
I've got stacks in my structs, I've got arrays in my queues,
I've got the : Segmentation violation -- Core dumped blues.
If you think that it's nice that you get what you C,
Then go : illogical statement with your whole family,
'Cause the Supreme Court ain't the only place with : Bus error views.
I've got the : Segmentation violation -- Core dumped blues.
On a PDP-11, life should be a breeze,
But with VAXen in the house even magnetic tapes would freeze.
Now you might think that unlike VAXen I'd know who I abuse,
I've got the : Segmentation violation -- Core dumped blues.
-- Core Dumped Blues
From: BK
Date: Thu, 30 Sep 1993 15:41:50 PDT
Subject: Segmentation Violation -- Core Dumped Blues.
DW writes:
> [Removed forwarding headers etc.]
> I've got the : Segmentation violation -- Core dumped blues.
I'd like to mention that this little ditty was written by GB
at Dontel Inc. in about 1980, shortly after we got our first
Unix machine and we were all trying to make sense of it.
It still doesn't make sense and it's still a great song...
From: AD
Date: Sat, 2 Oct 93 15:09:16 EDT
Subject: It Sure Boots Fast...
[Note: We are restarting the Loki Cell at 4:00AM Sundays (again)]
We all know by now that unix uptime epochs should be
considered disposable. You boot your machine and use it
until the OS loses track of all of the resources it was
supposed to be managing, then you reboot it. Of course, the
unix box isn't smart enough to tell you that it is out of
resources -- that would be too hard and might require
resources as well. Besides, we have to make sure there's
enough work left out of the OS to make sure the local unix
wizard remains an essential part of the installation.
Well, it seems those new fangled unix distributed
filesystems (e.g. AFS), inherit this mode of lossage from
their progenitors (is this what they mean by C++ providing
unix systems with inheritance?).
------- Forwarded Message
<questionable>
Date: Fri, 1 Oct 93 22:24:16 -0400
From: JS
Subject: Note: We Are Restarting The Loki Cell at 4:00AM Sundays (Again)
We used to restart the Loki Cell every Sunday at
4:00AM. At some time in the not so distant past this
practice was abandoned. However it is pretty clear from
last Tuesday's restart, that restarting does "clean things
up" and improve performance.
We have therefore re-enabled the 4:00AM Sunday
morning restarts and I have placed an appropriate message of
the day. Note: 4:00AM Sunday is late SATURDAY night.
------- End Forwarded Message
From: RS
Date: Sun, 3 Oct 1993 16:19:01 +0900
Subject: OLTP on the Berzerkeley Fast File System, anyone?
Every so often, our abUsenet server goes down unexpectedly,
as Unix boxes are wont to do. Unfortunately, INN (the news
transport system we're running) has no
checkpointing/roll-forward/roll-back on its databases -
they're open and naked as long as the server is up. So you
have to regenerate the databases from scratch if the server
goes down - a process that takes 5 hours or so. But even
better than that, sometimes the innd server bites the big
one and scrambles my active file. For those of you who
aren't unlucky enough to have to look after one of these
beasts, the "active" file is a list of tuples, one for each
newsgroup. They contain the name of the group, message IDs
of the first and last messages currently on the server, and
a boolean for whether the group is moderated or not.
Anyhow, the scrambling bore and interesting similarity to
dissociated press. Here are a few of the choicer ones I
found while mopping up after it:
bit.listserv.linkfail
houston.eahouston.forsale
compnderground.digest
comp.sys.ibm.pc.soundcapc.soundcard.GUS
yp.sys.ibm.ps2.hardware
comp.lang.forth.franz
clari.local.alberta.bari.local.california
From: SG
Date: Sun, 3 Oct 93 08:33:55 -0400
Subject: Crazy Error Messages
Don't you just love the informative error message? How
about that killer "from:" address? "
[email protected]"?
What the hell is Nowhere.com? Is that "noone.nowhere.com?"
Why was this message routed through uunet? What's going on?
Turns out that I was sending mail to "
[email protected]"
instead of sending mail to "
[email protected]."
Leave it to Unix to make it easy for you to figure this out.
I just feel sorry for those guys at nowhere.com whose mailer keeps
crashing with a memory fault.
Begin forwarded message:
From
[email protected] Sun Oct 3 08:28:41 1993
Return-Path: <
[email protected]>
Received: by next.cambridge.ma.us (NX5.67d/NeXT-1.0)
id AA01095; Sun, 3 Oct 93 08:28:40 -0400
Received: from relay1.UU.NET by life.one.two.thr (4.1/AI-4.10) for
SG id AA23485; Sun, 3 Oct 93 07:34:03 EDT
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AB27509; Sun, 3 Oct 93 07:34:02 -0400
Received: from planets.UUCP by uucp3.uu.net with UUCP/RMAIL
(queueing-rmail) id 073235.12866; Sun, 3 Oct 1993 07:32:35 EDT
Received: by ds9.cambridge.com (4.1/SMI-4.1-RBJ)
id AA01688; Sun, 3 Oct 93 06:33:24 EDT
Date: Sun, 3 Oct 93 06:33:24 EDT
From:
[email protected] (Uucp)
Message-Id: <
[email protected]>
Apparently-To: uunet!uunet!SG
remote execution [uucp job uunetC4WC4 (10/3-6:33:24)]
rmail apple.cambridge.com!pseudo
exited with status 139
===== stderr was =====
sh: 1686 Memory fault
From: JL
Date: Mon, 4 Oct 93 07:34:19 EDT
Subject: Heard On The Net
Well, I still like what someone said about developing
graphics applications with Windows or X: "It's like being
given the Periodic Table of Elements and being told you
have everything you need; Go make a broccoli".
Especially as applied to X.
Then again, this applies as well to Unix - except that in
Unix, most of the available isotopes are unstable, there
have been a couple of misprints in the table itself, and the
jars of available reagents are labeled with abbreviations -
in Kurdish.
From: SG
Date: Mon, 4 Oct 93 08:30:46 -0400
Subject: Administrivia
Is somebody currently archiving this mailing list, or should
I set up an archive here?
From: RS
Date: Tue, 5 Oct 1993 01:37:42 +0900
Subject: Re: Administrivia
> Date: Mon, 4 Oct 93 08:30:46 -0400
> From: SG
> Subject: Administrivia
>
> Is somebody currently archiving this mailing list, or
> should I set up an archive here?
The archives are splattered among a few different places.
They are currently being kept already; no special effort is
necessary on your part. I'll dig them all up (including all
the old ones), sort them in chronological order, stick them
in the anonymous ftp area on MC, and mail a pointer to
[email protected]. Fair enough?
From: RS
Date: Tue, 5 Oct 1993 05:18:07 +0900
Subject: Re: Administrivia
> From: AB
>
> Neither of these messages say anything bad about Unix.
> Fortunately for you both, The Czar himself is on vacation
> in Spain, so you probably have a few days until he gets
> back to make up for your lapse by submitting an apology
> -and- a good flame.
Hey, I'll apologize for cluttering up the list with
administrivia, but I'll beg off on yet another flame,
preferring to maintain that I have already served my penance
by sending the dissociated-press-on-your-active-file message
as an act of contrition *after* I sent the
administrababbble. Don't even bother pointing out that the
dates in the headers don't match up with my alibi - thanks
to the modern miracle of Sendmail I have plausible
deniability, and you can't prove I'm lying. So nyah.
> Also, what's all this shite about wanting the archives for
> the Unix Haters Handbook? I distinctly remember digging
> up the archives a year or two ago for you guys. Did you
> -lose- them? Sure we have archives, if we dig them up for
> you yet again, will you promise not to come back and ask
> for them again next year?
Heh. Like you should even have to ask. Did I just hear a
freed inode clatter to the floor?
From: SG
Date: Mon, 4 Oct 93 18:45:51 -0400
Subject: Crazy Stupid Modem Support
The first program that I ever had, on the first computer
that I ever had, was a terminal emulator which let me log
into a bulletin board system, upload and download files, and
pretended to be a Vt100 terminal. This was back in 1980 on
a Xitan Z80 with 60K of RAM, 4K of RAM, crammed into a 64K
address space and it flew.
So now what's up with this NeXTstation on my desk? I have a
choice of not one, not two, not three, but four different
programs to use my brand new, 14/14 fax/data/voice modem.
My choices? tip, cu, kermit, and Terminal (which can
connect directly to the modem port).
After several hours of trying, I've been unable to configure
any of these programs to let me dial the phone, connect,
transfer files, and log off. tip and cu can allegedly dial
the phone, but I haven't been able to figure out how to make
it work with my particular brand of modem. (Why don't they
just support the Hayes command set? I don't have
racal-vadic or anything like that.) Even if I get tip or cu
to work, they can't transfer binary files properly. I'd use
kermit, but it doesn't know that my serial ports can run at
38,400 baud --- you ask it to set that baud rate, and it
says speed not supported.
Things were so much easier back when I was using CP/M.
