Back When Geek Humour Was A New Concept To Me ...

[Lawrence D'Oliveiro]

... I came across a T-shirt which read

C:DOS.
C:DOS:RUN.
RUN:DOS:RUN.
RUN:RUN:RUN.

What’s your earliest example of geek humour?

[David LaRue]

Post by Lawrence D'Oliveiro
... I came across a T-shirt which read
C:DOS.
C:DOS:RUN.
RUN:DOS:RUN.
RUN:RUN:RUN.
What’s your earliest example of geek humour?

I don't have a cspecific memory of one, but my first language was Assembly,
then BASIC, and about 60 more languages. The first time I accidentally
discovered the equivalent of...

10 GOTO 10

was an interesting surprise to myself. My group of nerds all independantly
discovered it rather quickly. Nearly all languages can do this.

About a year later on our school's call-in timeshare system I wrote a small
BASIC program to create a short file, delete it, then create a slightly
larger file, delete it, and so on with random short lengths. It quickly
fragmented the main disk with deleted files that the sysop had to run a
process to defrag the disk and reclaim space so a file could be created
again.

[songbird]

Post by Lawrence D'Oliveiro
... I came across a T-shirt which read
C:DOS.
C:DOS:RUN.
RUN:DOS:RUN.
RUN:RUN:RUN.
What’s your earliest example of geek humour?

this was very juvenile but it was funny:

IBM
UBM
WE ALL BM
FOR IBM


it is probably older than i am...


songbird

[Carlos E.R.]

Post by songbird

Post by Lawrence D'Oliveiro
... I came across a T-shirt which read
C:DOS.
C:DOS:RUN.
RUN:DOS:RUN.
RUN:RUN:RUN.
What’s your earliest example of geek humour?

IBM
UBM
WE ALL BM
FOR IBM
it is probably older than i am...

I'm afraid I don't understand any of the two. English is not my first
language.

[Scott Lurndal]

Post by Carlos E.R.

Post by songbird

Post by Lawrence D'Oliveiro
... I came across a T-shirt which read
C:DOS.
C:DOS:RUN.
RUN:DOS:RUN.
RUN:RUN:RUN.
What’s your earliest example of geek humour?

IBM
UBM
WE ALL BM
FOR IBM
it is probably older than i am...

I'm afraid I don't understand any of the two. English is not my first
language.

"BM" in this instance is scatalogical - it means "Bowel Movement".

[Carlos E.R.]

Post by Scott Lurndal

Post by Carlos E.R.

Post by songbird

Post by Lawrence D'Oliveiro
... I came across a T-shirt which read
C:DOS.
C:DOS:RUN.
RUN:DOS:RUN.
RUN:RUN:RUN.
What’s your earliest example of geek humour?

IBM
UBM
WE ALL BM
FOR IBM
it is probably older than i am...

I'm afraid I don't understand any of the two. English is not my first
language.

"BM" in this instance is scatalogical - it means "Bowel Movement".

We had our own local joke with IBM. "Trabajo en IBM" ie, I work at IBM.
Then they would expand: "Y beme pa'cá, y beme pa'llá" And you come here,
and you go there.

[songbird]

Carlos E.R. wrote:
...

Post by Carlos E.R.
I'm afraid I don't understand any of the two. English is not my first
language.

BM is short for bowel movement (aka taking a poop).

IBM is a computer company.

it was a juvenile play on words.


songbird

[Lars Poulsen]

Post by Carlos E.R.

Post by Lawrence D'Oliveiro
... I came across a T-shirt which read
C:DOS.
C:DOS:RUN.
RUN:DOS:RUN.
RUN:RUN:RUN.
What’s your earliest example of geek humour?

I'm afraid I don't understand any of the two. English is not my first
language.

A very common first grade book to teach reaing to American children
begins with a picture of a small dog, and then the text:

See Spot
See Spot run
Run, Spot, run
Run, run, run!

(Spot is a common "generic" name for a dog.)

[Lawrence D'Oliveiro]

See Spot run ...

Which immediately brought to mind that episode of “Family Guy” where the
FCC censors Peter Griffin’s farts with Steven Wright jokes.

“I spilled spot remover on my dog, and now he’s gone.”

[Grant Taylor]

Post by Lawrence D'Oliveiro
What’s your earliest example of geek humour?

I don't know about the earliest, but here are a few that I've known for
a LONG time.

- Who is General Failure and why is he trying to read my drive C:?

A TRS-80 family lineage joke a friend of mine used to say:

- Shut 'er down Scottie, she's sucking mud!

Context is Xenix (?) on a Z80 based Tandy Radio Shack computer which
supported multiple systems in a cluster of sorts before clustering was
known.

Finally a LONG favored of mine:

Microsoft Windows
- A 32-bit hack
- on a 16-bit patch
- for an 8-bit OS
- designed for a 4-bit processor
- by a 2-bit company
- that can't stand 1-bit of competition

I've prefaced it "a 64-bit flop of ..." in recent years.

As a bonus:

- <1st person>Microsoft Works<2nd person interrupts> NO IT DOESN'T!!!

[Lawrence D'Oliveiro]

Post by Grant Taylor

Post by Lawrence D'Oliveiro
What’s your earliest example of geek humour?

I don't know about the earliest, but here are a few that I've known for
a LONG time.
- Who is General Failure and why is he trying to read my drive C:?

Not sure which OS had the error message “bad device or file name” if it
could not find the file you were looking for. The natural addition was
“Bad device or file name. Bad, bad, bad.”

Post by Grant Taylor
- <1st person>Microsoft Works<2nd person interrupts> NO IT DOESN'T!!!

I remember the Macintosh version would break every time Apple brought out
a new Mac model or even a new OS version. Every ... single ... time.

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro
Not sure which OS had the error message “bad device or file name” if it
could not find the file you were looking for. The natural addition was
“Bad device or file name. Bad, bad, bad.”

I remember a bit more now: it was “Bad command or filename. Bad, bad,
bad.”

[Niklas Karlsson]

Post by Lawrence D'Oliveiro
Not sure which OS had the error message “bad device or file name” if it
could not find the file you were looking for. The natural addition was
“Bad device or file name. Bad, bad, bad.”

I don't know about "device", but "Bad command or file name" is from
MS-DOS.

Niklas

[Charlie Gibbs]

Post by Lawrence D'Oliveiro
... I came across a T-shirt which read
C:DOS.
C:DOS:RUN.
RUN:DOS:RUN.
RUN:RUN:RUN.
What’s your earliest example of geek humour?

Back in the mainframe days, there were long lists of
bogus macine instructions, e.g.

Rewind and Break Tape
Execute Operator
Branch on Burned-Out Indicator
Reverse Drum Immediate

Et cetera.

I came up with a little song for the Intel era:

8080 One little
8085 Two little
8086 Three little-endians
8088 Four little
80186 Five little
80188 Six little-endians
80286 Seven little
80386 Eight little
80486 Nine little-endians
Pentium SYSTEM FAULT

I am Pentium of Borg.
Division is futile.
You will be approximated.

[Carlos E.R.]

Post by Charlie Gibbs

Post by Lawrence D'Oliveiro
... I came across a T-shirt which read
C:DOS.
C:DOS:RUN.
RUN:DOS:RUN.
RUN:RUN:RUN.
What’s your earliest example of geek humour?

Back in the mainframe days, there were long lists of
bogus macine instructions, e.g.
Rewind and Break Tape
Execute Operator
Branch on Burned-Out Indicator
Reverse Drum Immediate

Halt and catch fire.

...

[Scott Lurndal]

Post by Carlos E.R.

Post by Charlie Gibbs

Post by Lawrence D'Oliveiro
... I came across a T-shirt which read
C:DOS.
C:DOS:RUN.
RUN:DOS:RUN.
RUN:RUN:RUN.
What’s your earliest example of geek humour?

Back in the mainframe days, there were long lists of
bogus macine instructions, e.g.
Rewind and Break Tape
Execute Operator
Branch on Burned-Out Indicator
Reverse Drum Immediate

Halt and catch fire.

Punch Operator.

[vallor]

Post by Carlos E.R.

Post by Charlie Gibbs

Post by Lawrence D'Oliveiro
... I came across a T-shirt which read
C:DOS.
C:DOS:RUN.
RUN:DOS:RUN.
RUN:RUN:RUN.
What’s your earliest example of geek humour?

Back in the mainframe days, there were long lists of
bogus macine instructions, e.g.
Rewind and Break Tape
Execute Operator
Branch on Burned-Out Indicator
Reverse Drum Immediate

Halt and catch fire.
...

In linux-6.12.1/drivers/char/lp.c:

printk(KERN_INFO "lp%d on fire\n", minor);

[Carlos E.R.]

Post by vallor

Post by Carlos E.R.

Post by Charlie Gibbs

Post by Lawrence D'Oliveiro
... I came across a T-shirt which read
C:DOS.
C:DOS:RUN.
RUN:DOS:RUN.
RUN:RUN:RUN.
What’s your earliest example of geek humour?

Back in the mainframe days, there were long lists of
bogus macine instructions, e.g.
Rewind and Break Tape
Execute Operator
Branch on Burned-Out Indicator
Reverse Drum Immediate

Halt and catch fire.
...

printk(KERN_INFO "lp%d on fire\n", minor);

Wow :-)

How would the kernel know?

[Bob Eager]

Post by Carlos E.R.

Post by vallor
printk(KERN_INFO "lp%d on fire\n", minor);

Wow :-)
How would the kernel know?

Reminds me of this; true, I was there when it happened. And I worked on
the supervisor.

When the University of Kent's ICL 2960 mainframe was installed, it came
with a site engineer. For quite a while, one of these was someone who was
a Kent graduate. He was somewhat of a 'company man', and was not keen when
we abandoned the VME/K operating system in favour of EMAS (from the
University of Edinburgh).

I managed EMAS; it had a novel way of handling filestore and (for the
purposes of this story) peripherals such as printers. These were managed
via a Spooler process, which handled all of the exception conditions,
farmed out to it by the actual supervisor. Whoever wrote the code at
Edinburgh had been a little obsessive about detailed error messages - a
good thing, and possible because all of the messages were inside a paged
process.

One day, we saw a message we had never seen before. I forget the exact
text, but it indicated that a particular fuse had blown in the printer.
Edit: I just reviewed the source code; it was "Hammer Driver Fuse Blown".
We duly called the engineer from his room. He looked at the message, and
shook his head, stating that no such fuse existed and "our" system was
wrong.

We pressed him on this, and after casting his eye over the defunct printer
he retired to his office and manuals. He returned a few minutes later,
bearing a fuse. He silently opened a small panel in the printer casing,
and changed the fuse.

[Carlos E.R.]

Post by Bob Eager

Post by Carlos E.R.

Post by vallor
printk(KERN_INFO "lp%d on fire\n", minor);

Wow :-)
How would the kernel know?

Reminds me of this; true, I was there when it happened. And I worked on
the supervisor.
When the University of Kent's ICL 2960 mainframe was installed, it came
with a site engineer. For quite a while, one of these was someone who was
a Kent graduate. He was somewhat of a 'company man', and was not keen when
we abandoned the VME/K operating system in favour of EMAS (from the
University of Edinburgh).
I managed EMAS; it had a novel way of handling filestore and (for the
purposes of this story) peripherals such as printers. These were managed
via a Spooler process, which handled all of the exception conditions,
farmed out to it by the actual supervisor. Whoever wrote the code at
Edinburgh had been a little obsessive about detailed error messages - a
good thing, and possible because all of the messages were inside a paged
process.
One day, we saw a message we had never seen before. I forget the exact
text, but it indicated that a particular fuse had blown in the printer.
Edit: I just reviewed the source code; it was "Hammer Driver Fuse Blown".
We duly called the engineer from his room. He looked at the message, and
shook his head, stating that no such fuse existed and "our" system was
wrong.
We pressed him on this, and after casting his eye over the defunct printer
he retired to his office and manuals. He returned a few minutes later,
bearing a fuse. He silently opened a small panel in the printer casing,
and changed the fuse.

:-))


I have no trouble imagining big machines knowing such things (because I
worked with one and it knew it all, including a fire (it was in the
manual)). But the Linux kernel, that runs on PCs? How would it know a
home printer is on fire? Of course, I can be mistaken, and the printers
are designed to tell such a thing back to the printer. But the original
printer protocol on PCs was unidirectional.

[Scott Lurndal]

Post by Carlos E.R.

Post by Bob Eager

Post by Carlos E.R.

Post by vallor
printk(KERN_INFO "lp%d on fire\n", minor);

Wow :-)
How would the kernel know?

Reminds me of this; true, I was there when it happened. And I worked on
the supervisor.
When the University of Kent's ICL 2960 mainframe was installed, it came
with a site engineer. For quite a while, one of these was someone who was
a Kent graduate. He was somewhat of a 'company man', and was not keen when
we abandoned the VME/K operating system in favour of EMAS (from the
University of Edinburgh).
I managed EMAS; it had a novel way of handling filestore and (for the
purposes of this story) peripherals such as printers. These were managed
via a Spooler process, which handled all of the exception conditions,
farmed out to it by the actual supervisor. Whoever wrote the code at
Edinburgh had been a little obsessive about detailed error messages - a
good thing, and possible because all of the messages were inside a paged
process.
One day, we saw a message we had never seen before. I forget the exact
text, but it indicated that a particular fuse had blown in the printer.
Edit: I just reviewed the source code; it was "Hammer Driver Fuse Blown".
We duly called the engineer from his room. He looked at the message, and
shook his head, stating that no such fuse existed and "our" system was
wrong.
We pressed him on this, and after casting his eye over the defunct printer
he retired to his office and manuals. He returned a few minutes later,
bearing a fuse. He silently opened a small panel in the printer casing,
and changed the fuse.

:-))
I have no trouble imagining big machines knowing such things (because I
worked with one and it knew it all, including a fire (it was in the
manual)). But the Linux kernel, that runs on PCs? How would it know a
home printer is on fire? Of course, I can be mistaken, and the printers
are designed to tell such a thing back to the printer. But the original
printer protocol on PCs was unidirectional.

"Data" was unidirectional. There were bidirectional status pins (4) on the
original Centronix interface. HP redefined those into a 4-bit field for
up to 16 status codes.

[Lynn Wheeler]

I (and others) keynote at NASA/CMU Dependable Computing workshop
https://web.archive.org/web/20011004023230/http://www.hdcc.cs.cmu.edu/may01/index.html

When I first transfer out to SJR in 2nd half of 70s, I get to wander
around IBM (and other) datacenters, including disk bldg14/enginneering
and bldg15/product-test across the street. They were running 7x24,
prescheduled, stand alone testing and mentioned that they had recently
tried MVS ... but it had 15min MTBF (in that environment), requiring
re-ipl. I offer to rewrite I/O supervisor to make it bullet proof and
never fail so they could do any amount of on-demand, concurrent testing,
greatly improving productivity (downside was that they wanted me to
increasingly spend time playing disk engineer). I do an internal
research report about "I/O integrity" and happen to mention the MVS
15min MTBF. I then get a call from the MVS group, I thot that they
wanted help in improving MVS integrity ... but it seems they wanted to
get me fired for (internally) disclosing their problems.

1980, IBM STL was bursting at the seams and they were moving 300
(people&3270s from IMS DBMS group) to offsite bldg with dataprocessing
back to STL datacenter ... they had tried "remote" 3270 support and
found the human factors unacceptable. I get con'ed into doing "channel
extender" support so they can place channel attached 3270 controllers at
the off-site bldg with no perceptable difference in the human factors
offsite and in STL. The vendor then tries to get IBM to release my
support but there is group in POK that get it vetoed (they were playing
with some serial stuff and afraid that if it was in the market, it would
make it difficult to releasing their stuff). The vendor then replicates
my implementation.

Role forward to 1986 and 3090 product administrator tracks me done.
https://web.archive.org/web/20230719145910/https://www.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3090.html

There was an industry service that collected customer mainframe EREP
(detailed error reporting) data and generated periodic summaries. The
3090 engineers had designed the I/O channels predicting there would be a
maximum aggregate of 4-5 "channel errors" across all customer 3090
installations per year ... but the industry summary reported total
aggregate of 20 channel errors for 3090s first year.

It turned out for certain types of channel-extender transmission errors,
I had selected simulating "channel error" in order to invoke channel
program retry (in error recovery) ... and the extra 15 had come from
customers running the channel-extender support. I did a little research
(various different kernel software) and found simulating IFCC (interface
control check) would effectively perform the same kinds of channel
program retry (and got the vendor to change their implementation from
"CC" to "IFCC").

[Lynn Wheeler]

Post by Lynn Wheeler
I (and others) keynote at NASA/CMU Dependable Computing workshop
https://web.archive.org/web/20011004023230/http://www.hdcc.cs.cmu.edu/may01/index.html

AADS chip mentioned in NASA/CMU dependable workship talk ... more
here in Assurance panel in trusted computing track at IDF:
https://web.archive.org/web/20011109072807/http://www.intel94.com/idf/spr2001/sessiondescription.asp?id=stp%2bs13
and prototype chips used in NACHA pilot (23july2001)
https://web.archive.org/web/20070706004855/http://internetcouncil.nacha.org/News/news.html

[vallor]

Post by Carlos E.R.

Post by Bob Eager

Post by Carlos E.R.

Post by vallor
printk(KERN_INFO "lp%d on fire\n", minor);

Wow :-)
How would the kernel know?

Reminds me of this; true, I was there when it happened. And I worked on
the supervisor.
When the University of Kent's ICL 2960 mainframe was installed, it came
with a site engineer. For quite a while, one of these was someone who was
a Kent graduate. He was somewhat of a 'company man', and was not keen when
we abandoned the VME/K operating system in favour of EMAS (from the
University of Edinburgh).
I managed EMAS; it had a novel way of handling filestore and (for the
purposes of this story) peripherals such as printers. These were managed
via a Spooler process, which handled all of the exception conditions,
farmed out to it by the actual supervisor. Whoever wrote the code at
Edinburgh had been a little obsessive about detailed error messages - a
good thing, and possible because all of the messages were inside a paged
process.
One day, we saw a message we had never seen before. I forget the exact
text, but it indicated that a particular fuse had blown in the printer.
Edit: I just reviewed the source code; it was "Hammer Driver Fuse Blown".
We duly called the engineer from his room. He looked at the message, and
shook his head, stating that no such fuse existed and "our" system was
wrong.
We pressed him on this, and after casting his eye over the defunct printer
he retired to his office and manuals. He returned a few minutes later,
bearing a fuse. He silently opened a small panel in the printer casing,
and changed the fuse.

:-))
I have no trouble imagining big machines knowing such things (because I
worked with one and it knew it all, including a fire (it was in the
manual)). But the Linux kernel, that runs on PCs? How would it know a
home printer is on fire? Of course, I can be mistaken, and the printers
are designed to tell such a thing back to the printer. But the original
printer protocol on PCs was unidirectional.

It's just a goofy error message for an IO error with
the printer.

[Carlos E.R.]

Post by vallor

Post by Carlos E.R.

Post by Bob Eager

Post by Carlos E.R.

Post by vallor
printk(KERN_INFO "lp%d on fire\n", minor);

Wow :-)
How would the kernel know?

Reminds me of this; true, I was there when it happened. And I worked on
the supervisor.
When the University of Kent's ICL 2960 mainframe was installed, it came
with a site engineer. For quite a while, one of these was someone who was
a Kent graduate. He was somewhat of a 'company man', and was not keen when
we abandoned the VME/K operating system in favour of EMAS (from the
University of Edinburgh).
I managed EMAS; it had a novel way of handling filestore and (for the
purposes of this story) peripherals such as printers. These were managed
via a Spooler process, which handled all of the exception conditions,
farmed out to it by the actual supervisor. Whoever wrote the code at
Edinburgh had been a little obsessive about detailed error messages - a
good thing, and possible because all of the messages were inside a paged
process.
One day, we saw a message we had never seen before. I forget the exact
text, but it indicated that a particular fuse had blown in the printer.
Edit: I just reviewed the source code; it was "Hammer Driver Fuse Blown".
We duly called the engineer from his room. He looked at the message, and
shook his head, stating that no such fuse existed and "our" system was
wrong.
We pressed him on this, and after casting his eye over the defunct printer
he retired to his office and manuals. He returned a few minutes later,
bearing a fuse. He silently opened a small panel in the printer casing,
and changed the fuse.

:-))
I have no trouble imagining big machines knowing such things (because I
worked with one and it knew it all, including a fire (it was in the
manual)). But the Linux kernel, that runs on PCs? How would it know a
home printer is on fire? Of course, I can be mistaken, and the printers
are designed to tell such a thing back to the printer. But the original
printer protocol on PCs was unidirectional.

It's just a goofy error message for an IO error with
the printer.

ah.

[Lawrence D'Oliveiro]

Post by Carlos E.R.

Post by vallor
printk(KERN_INFO "lp%d on fire\n", minor);

Wow :-)
How would the kernel know?

Here’s the code in context:

static int lp_check_status(int minor)
{
int error = 0;
unsigned int last = lp_table[minor].last_error;
unsigned char status = r_str(minor);
if ((status & LP_PERRORP) && !(LP_F(minor) & LP_CAREFUL))
/* No error. */
last = 0;
else if ((status & LP_POUTPA)) {
if (last != LP_POUTPA) {
last = LP_POUTPA;
printk(KERN_INFO "lp%d out of paper\n", minor);
}
error = -ENOSPC;
} else if (!(status & LP_PSELECD)) {
if (last != LP_PSELECD) {
last = LP_PSELECD;
printk(KERN_INFO "lp%d off-line\n", minor);
}
error = -EIO;
} else if (!(status & LP_PERRORP)) {
if (last != LP_PERRORP) {
last = LP_PERRORP;
printk(KERN_INFO "lp%d on fire\n", minor);
}
error = -EIO;
} else {
last = 0; /* Come here if LP_CAREFUL is set and no
errors are reported. */
}

lp_table[minor].last_error = last;

if (last != 0)
lp_error(minor);

return error;
}

taken from
<https://elixir.bootlin.com/linux/v6.12.1/source/drivers/char/lp.c>.

[Mister Johnson]

from the BSD man page for tunefs:

You can tune a file system, but you cannot tune a fish.

[Scott Lurndal]

Post by Mister Johnson
You can tune a file system, but you cannot tune a fish.

Borrowed from the title of a REO Speedwagon album...

https://en.wikipedia.org/wiki/You_Can_Tune_a_Piano,_but_You_Can%27t_Tuna_Fish

[Bob Eager]

Post by Mister Johnson
You can tune a file system, but you cannot tune a fish.

Still there in FreebSD.

[Lawrence D'Oliveiro]

Back in the mainframe days, there were long lists of bogus macine
instructions, e.g.
Rewind and Break Tape
Execute Operator
Branch on Burned-Out Indicator
Reverse Drum Immediate

And a real one, from PowerPC, possibly POWER as well: “EIEIO”, “Enforce
In-Order Execution of I/O”.

[Lawrence D'Oliveiro]

In the early days of Wired magazine, they were selling T-shirts, and one
design in particular (being a Mac fanatic at the time) appealed to me: it
was closely based on the Macintosh menu design style, complete with its
use of the “Chicago” system font. The text looked like

File
Open → Your Mind
Close → Your Mouth

I still have that T-shirt tucked away somewhere, though unfortunately it
has become too decrepit to continue using.

And would you believe, I was able to find that exact same image online,
only used as a poster, not on a T-shirt:
<https://www.flickr.com/photos/philgyford/3040078285>.

[John Levine]

Post by Lawrence D'Oliveiro
What’s your earliest example of geek humour?

The Blinkenlights blurb was endlessly photocopied and posted on
computer room doors and windows starting in the late 1950s. It was
usually in a fake gothic font:

ACHTUNG! ALLES LOOKENSPEEPERS!

Das computermachine ist nicht fuer gefingerpoken und
mittengrabben. Ist easy schnappen der springenwerk,
blowenfusen und poppencorken mit spitzensparken. Ist nicht
fuer gewerken bei das dumpkopfen. Das rubbernecken
sichtseeren keepen das cotten-pickenen hans in das pockets
muss; relaxen und watchen das blinkenlichten.

I probably first saw it somewhere in the Princeton computer center
in about 1968 when it was already quite old.

https://foldoc.org/blinkenlights

[Lawrence D'Oliveiro]

The Blinkenlights blurb was endlessly photocopied and posted on computer
room doors and windows starting in the late 1950s.

Ah yes. I remember that. You’d see it in every computer room, just about.

Remember that early case, of a computer malfunction that was traced down
to a dead moth caught in a circuit or some such? (I think Grace Hopper
might have been involved in tracking that down.) The actual bug was
sellotaped in the log book next to the report about the error and the fix
-- the earliest known case of a literal computer “bug”.

[Carlos E.R.]

Post by Lawrence D'Oliveiro

The Blinkenlights blurb was endlessly photocopied and posted on computer
room doors and windows starting in the late 1950s.

Ah yes. I remember that. You’d see it in every computer room, just about.
Remember that early case, of a computer malfunction that was traced down
to a dead moth caught in a circuit or some such? (I think Grace Hopper
might have been involved in tracking that down.) The actual bug was
sellotaped in the log book next to the report about the error and the fix
-- the earliest known case of a literal computer “bug”.

I remember reading about the bug, either in the contacts of a vacuum
valve/tube, or in the contact of a relais. The thing sellotaped is new
to me. I guess the actual history has gone around a lot and the facts
are fuzzy by now :-)

[John Levine]

Post by Lawrence D'Oliveiro
Remember that early case, of a computer malfunction that was traced down
to a dead moth caught in a circuit or some such? (I think Grace Hopper
might have been involved in tracking that down.) The actual bug was
sellotaped in the log book next to the report about the error and the fix
-- the earliest known case of a literal computer “bug”.

It was the Harvard Mark II, which was mostly electromechanical. The
log book with the moth taped to a page is in the Smithsonian. Here's
a picture of it:

https://daily.jstor.org/the-bug-in-the-computer-bug-story/

The word "bug" for a flaw in the equipment goes way back. Thomas
Edison used it in the 1800s.

[Carlos E.R.]

Post by John Levine

Post by Lawrence D'Oliveiro
Remember that early case, of a computer malfunction that was traced down
to a dead moth caught in a circuit or some such? (I think Grace Hopper
might have been involved in tracking that down.) The actual bug was
sellotaped in the log book next to the report about the error and the fix
-- the earliest known case of a literal computer “bug”.

It was the Harvard Mark II, which was mostly electromechanical. The
log book with the moth taped to a page is in the Smithsonian. Here's
https://daily.jstor.org/the-bug-in-the-computer-bug-story/

Ah, good to know :-)

Post by John Levine
The word "bug" for a flaw in the equipment goes way back. Thomas
Edison used it in the 1800s.

Heh, the log says "moth" :-)

[Lars Poulsen]

Post by Carlos E.R.

Post by Lawrence D'Oliveiro

The Blinkenlights blurb was endlessly photocopied and posted on computer
room doors and windows starting in the late 1950s.

Ah yes. I remember that. You’d see it in every computer room, just about.
Remember that early case, of a computer malfunction that was traced down
to a dead moth caught in a circuit or some such? (I think Grace Hopper
might have been involved in tracking that down.) The actual bug was
sellotaped in the log book next to the report about the error and the fix
-- the earliest known case of a literal computer “bug”.

I remember reading about the bug, either in the contacts of a vacuum
valve/tube, or in the contact of a relais. The thing sellotaped is new
to me. I guess the actual history has gone around a lot and the facts
are fuzzy by now :-)

As I remember it, Cdr Hopper describes the incident in her memoir (which
I have not read). But the ComputerWorld article is probably the better
story. AtlasObscura has a photo of the logbook page, which is at the
Smithsonian.

https://daily.jstor.org/the-bug-in-the-computer-bug-story/
https://sciencenotes.org/september-9-today-science-history-first-computer-bug/
https://www.computerworld.com/article/1537941/moth-in-the-machine-debugging-the-origins-of-bug.html
https://www.atlasobscura.com/places/grace-hoppers-bug
https://en.wikipedia.org/wiki/Grace_Hopper

[Scott Lurndal]

Post by Carlos E.R.

The Blinkenlights blurb was endlessly photocopied and posted on computer
room doors and windows starting in the late 1950s.

Ah yes. I remember that. You’d see it in every computer room, just about.
Remember that early case, of a computer malfunction that was traced down
to a dead moth caught in a circuit or some such? (I think Grace Hopper
might have been involved in tracking that down.) The actual bug was
sellotaped in the log book next to the report about the error and the fix
-- the earliest known case of a literal computer “bug”.

I remember reading about the bug, either in the contacts of a vacuum
valve/tube, or in the contact of a relais. The thing sellotaped is new
to me. I guess the actual history has gone around a lot and the facts
are fuzzy by now :-)

The admiral recounted the incident in her speech at the 1980 ACM conference.

[Lawrence D'Oliveiro]

Back in the days when the main computer at the University where I was
studying was a PDP-11/70 running the DEC RSTS/E operating system, there
was a powerful, if cryptic, command-driven text editor called TECO.

This was installed so that it could be invoked via either of two commands:

TECO «filename»

to open the existing file «filename» before starting the editing session,
or

MAKE «filename»

to create a new file named «filename», and open it before starting the
editing session.

Or you could just type the “TECO” command without any filename to start
the editor without pre-opening any files.

The startup sequence that interpreted the command line was itself written
in TECO. And it had a little Easter egg in it. If you typed the command

MAKE LOVE

then it would print the message “Not war?” before creating and opening the
file named LOVE as directed.

[Rich Alderson]

Post by Lawrence D'Oliveiro
Back in the days when the main computer at the University where I was
studying was a PDP-11/70 running the DEC RSTS/E operating system, there
was a powerful, if cryptic, command-driven text editor called TECO.
TECO «filename»

I don't know what you typed to get them, but the characters around "filename"
are Arabic letters.

Post by Lawrence D'Oliveiro
to open the existing file «filename» before starting the editing session,
or
MAKE «filename»
to create a new file named «filename», and open it before starting the
editing session.
Or you could just type the "TECO" command without any filename to start
the editor without pre-opening any files.
The startup sequence that interpreted the command line was itself written
in TECO. And it had a little Easter egg in it. If you typed the command
MAKE LOVE
then it would print the message "Not war?" before creating and opening the
file named LOVE as directed.

This particular joke originated at the Stanford Artificial Intelligence
Laboratory (on the PDP-6) and was ported to DEC versions of TECO.

[Carlos E.R.]

Post by Rich Alderson

Post by Lawrence D'Oliveiro
Back in the days when the main computer at the University where I was
studying was a PDP-11/70 running the DEC RSTS/E operating system, there
was a powerful, if cryptic, command-driven text editor called TECO.
TECO «filename»

I don't know what you typed to get them, but the characters around "filename"
are Arabic letters.

Huh. Here they are standard quote symbols. «». I have them on [AltGr] +
Z or X

https://en.wikipedia.org/wiki/Quotation_mark

says they are called “Guillemets”


There is a long summary table listing the primary and secondary quote
symbols on many languages.

[Lawrence D'Oliveiro]

Following on from the pioneering ENIAC (the “Electronic Numerical
Integrator And Computer”), there was a fashion for a while for giving
those early big, room-filling machines names ending with “AC”, typically
standing for “Automatic Computer”. For example, EDVAC, EDSAC, UNIVAC,
JOHNNIAC, BINAC, ILLIAC ... and, inevitably, MANIAC
<https://en.wikipedia.org/wiki/List_of_vacuum-tube_computers>.

But how would you pronounce “CSIRAC”?

[ArseClown32]

Post by Lawrence D'Oliveiro
... I came across a T-shirt which read
C:DOS.
C:DOS:RUN.
RUN:DOS:RUN.
RUN:RUN:RUN.
What’s your earliest example of geek humour?

Windows ME

[Grant Taylor]

Post by ArseClown32
Windows ME

Windows CE ME NT

[geodandw]

Post by Grant Taylor

Post by ArseClown32
Windows ME

Windows CE ME NT

Any version of Windows is a joke.

[David LaRue]

Post by geodandw

Post by Grant Taylor

Post by ArseClown32
Windows ME

Windows CE ME NT

Any version of Windows is a joke.

Agreed.

I did DOS 3.3 full screen apps, then moved to a team that tried out the very
new OS/2 1.0 and the dozen feet or so of manuals. After OS/2 Warp 4.0 ended
I was lured to an NT job for double the pay. I still prefer the OS/2
toolsets to anything Microsoft ever created and for a while kept recreating
various incantions of the classes in my Linux work.

In case you haven't used OS/2 2.1, it was better to NT 3.0 and released years
earlier. The last OS/2 app we wrote was ported to NT using the same
compiler/toolchain and required only one line to be changed to make it work
on NT. That was the begining of my multiple application and multiple
computer projects as reliability and cross site applications were being built
everywhere with PCs instead of mainframes.

[Lawrence D'Oliveiro]

Post by David LaRue
In case you haven't used OS/2 2.1, it was better to NT 3.0 and released
years earlier.

That was the victim of, not just one mistake on the part of IBM, but an
entire litany of incompetence.

The whole sad saga is chronicled in excruciating detail here

[Peter Flass]

Post by David LaRue

Post by geodandw

Post by Grant Taylor

Post by ArseClown32
Windows ME

Windows CE ME NT

Any version of Windows is a joke.

Agreed.
I did DOS 3.3 full screen apps, then moved to a team that tried out the very
new OS/2 1.0 and the dozen feet or so of manuals. After OS/2 Warp 4.0 ended
I was lured to an NT job for double the pay. I still prefer the OS/2
toolsets to anything Microsoft ever created and for a while kept recreating
various incantions of the classes in my Linux work.
In case you haven't used OS/2 2.1, it was better to NT 3.0 and released years
earlier. The last OS/2 app we wrote was ported to NT using the same
compiler/toolchain and required only one line to be changed to make it work
on NT. That was the begining of my multiple application and multiple
computer projects as reliability and cross site applications were being built
everywhere with PCs instead of mainframes.

OS/2 Warp was better than anything that came later.

[Lawrence D'Oliveiro]

Post by Peter Flass
OS/2 Warp was better than anything that came later.

Even then, they completely stuffed it up with the name.

[Peter Flass]

Post by Lawrence D'Oliveiro

Post by Peter Flass
OS/2 Warp was better than anything that came later.

Even then, they completely stuffed it up with the name.

I always though they should have pushed it more as the PC OS “for
business” and portrayed windows as the OS for teenage hackers and gamers.
Of course, they would have needed the right software, and most of their
software was garbage.

[Charlie Gibbs]

Post by Grant Taylor

Post by ArseClown32
Windows ME

Windows CE ME NT

WinCE

[Chris Ahlstrom]

Post by Grant Taylor

Post by ArseClown32
Windows ME

Windows CE ME NT

WinCE

Windows CF

[Radey Shouman]

Post by ArseClown32

Post by Lawrence D'Oliveiro
... I came across a T-shirt which read
C:DOS.
C:DOS:RUN.
RUN:DOS:RUN.
RUN:RUN:RUN.
What’s your earliest example of geek humour?

Windows ME

Windows ME harder
--