Hacker News Reader

> so instead of advancing a few lines to the next page, it would try to advance thousands or millions of lines. This particular terminal model was a new, high speed one, so it would try to advance the paper really fast. [...] causing some bits of paper to shred and get kicked up as dust. Along with a spark [...] causing the terminal to catch fire.

Great story! It really gives a new interpretation to the classic phase "halt and catch fire." The original interpretation was the apocalyptic myth that the CPU starts switching the bus really fast, overheats the bus drivers, and eventually ignites the electronics, which doesn't make much sense. Now we have a more realistic one. To be precise, not "halt and catch fire", but "CRLF and catch fire"?

BTW, legends also say that the flammability of early printers was the origin of Unix's "lp0 on fire!" joke error message, which can still be seen in Linux for USB printers.

    /*
     * Get and print printer errors.
     */

    static const char *usblp_messages[] = 
        { "ok", "out of paper", "off-line", "on fire" };

The flammability of old printers came from a combination of paper dust, worn out printing ribbon and possible presence of a flammable cleaning solution IIRC.

More details are here: https://marc.info/?l=linux-kernel&m=102893054014512&w=2

So at the end of the day, it's more of a reality than a joke, sadly.

So at the end of the day, it's more of a reality than a joke, sadly.

Don't let later-day internet revisionist history take the joy out of you. No matter what the Wikipedia warriors profess, it was real.

So much truth has been lost in the last ten years because people who didn't experience the past don't believe the things that happened; and if references aren't a link away, they tell the world things that happened before their time are false.

> No matter what the Wikipedia warriors profess

BTW, I was reading your Twitter the other day, and saw that you complained that Wikipedia doesn't have any information about TTY - only two paragraphs and nothing more. Now you are here, I have to tell you that you have accidentally set your browser's Wikipedia language to "Simple English" [0], which is a special edition of Wikipedia for English learners, it only has few editors, thus most articles are incomplete. On the other hand, the normal "English" Wikipedia has a fairly standard introduction to TTY [1], around 16 pages on my screen. You've missed a lot, don't forget to switch your language back to "English" if you haven't done it already ;-)

[0] https://simple.wikipedia.org/wiki/Teletypewriter

[1] https://en.wikipedia.org/wiki/Teleprinter

you have accidentally set your browser's Wikipedia language to "Simple English"

I don't understand how that could have happened, so I won't address that issue. But this leaves me baffled:

I was reading your Twitter the other day,

This has to be the single worst decision you've made this month.

As far as I'm concerned, my Twitter feed is write-only memory. The SMS equivalent of dev/null.

If you're ever tempted to do so in the future, reconsider. Go for a walk. Write some poetry. Make love to your wife. Do anything else. We get so little time on this planet, please don't waste what you have looking at what I have to say.

> This has to be the single worst decision you've made this month.

Many months ago, mid-June I believe. Not this month.

> If you're ever tempted to do so in the future, reconsider. Go for a walk. Write some poetry. Make love to your wife. Do anything else. We get so little time on this planet, please don't waste what you have looking at what I have to say.

AWESOME :)

I just laughed at some of your tweets. Thank you fine sir ;-)

Since Twitter disabled their legacy no-javascript page, the world became a bit greener again.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

The IBM mainframe high-speed printers from decades ago made it possible to overprint the same line several times.

My memory of this was fuzzy, but I believe when you sent lines to the printer, there was a control code in the first column to have normal printing or to overprint the last line:

  |
  v
   line-of-text
  +this-overprints-previous-line

There were all kinds of things that you could do that were non-optimal, like overprinting lots and lots of stuff until it wore out the paper or making many things print simultaneously. If you did too much, the printer would stop and open the cover - think a 5x5x8 box opening its lid.

To be clear - these were basically chain saws with hammers behind the chain all controlled by software.

yes. the printers had 132 columns. you sent a buffer of 133 chars, the first being carriage control. blank was line feed, i forget what was page-eject/form-feed (1?? memory fuzzy). + was overprint.

As a student, I had a part-time job as an I/O clerk. (feed the card reader, file printouts). We disabled overprint on student jobs because it caused a lot of headaches from bugs. Form feed in an infinite loop was enough hassle.

The original IBM printer did not document + for overprint, it was the result of a logic optimization in the controller and someone discovered it. So IBM installed a field change order that disabled that function, but included a switch that for an additional monthly fee would upgrade your printer to a model that supported it.

The automatic openning of the lid at the end of a box of paper destroyed coffee cups on a regular basis.

"Field change order"

So essentially a change order carried out by IBM in "the field", meaning your university. Interesting ;)

I am reminded of Fortran 77. In Fortran 77, the first character of a record to be printed out determined vertical spacing as follows:

    Blank     One line
      0       Two lines
      1       To first line of next page
      +       No advance

Overstrike was essential in the early days.

Some printers didn't have question marks, so we used a capital P, instead.

Some didn't even have a space character, or world trim them out, so a lowercase b (for "blank") with a / on top of it would represent a space.

that’s crazy. Did you do P and a . over stroke for question Mark?

Or just, like thisP

Like thisP.

But text was precious, so questions were often condensed into one word.

"Do you want to get pizza?" Became simply "PizzaP"

Just curious: does that happen to have anything to do with lisps' -p for predicate suffix?

I really have no idea, as I've never worked with Lisp.

Huh. That's an interesting question. I looked up the original LISP paper (http://www-formal.stanford.edu/jmc/recursive.pdf), and it looks like the -p convention hadn't been established yet at that point, none of the predicates have that suffix in the paper. But it does say this:

  (LABEL, SUBST, (LAMBDA, (X, Y, Z), (COND ((ATOM, Z), 
  (COND,(EQ, Y, Z), X), ((QUOTE, T), Z))), ((QUOTE, T), (CONS, 
  (SUBST, X, Y,(CAR Z)), (SUBST, X, Y, (CDR, Z)))))))

  This notation is writable and somewhat readable. It can be 
  made easier to read and write at the cost of making its 
  structure less regular.  If more characters were available 
  on the computer, it could be improved considerably.[4]
  
  ----
  [4] 1995: More characters were made available on SAIL and 
  later on the Lisp machines.Alas, the world went back to 
  inferior character sets again—though not as far back as 
  when this paper was written in early 1959

So at the very least, some of the syntactic conventions of LISP were mostly due to limited character sets at the time.

Trying to binary search through history to figure out when the -p convention was introduced, I checked the original Scheme paper (https://web.archive.org/web/20171201033214/http://repository...), which has some examples in Scheme as well as implementation code in MacLISP. It looks like the predicate convention wasn't really strongly established at that point; in a few places, they use variables with a trailing `?` in the Scheme code, but I don't see any use of a predicate convention in the MacLISP implementation code.

Going back a bit, I do see the predicate convention mentioned in an Interlisp manual from 1974, but without an explanation of its origin (http://bitsavers.trailing-edge.com/pdf/xerox/interlisp/Inter...).

A MacLISP manual from the same year also mentions the -p convention, but not its origins. So looks like it had been firmly established by 1974: http://www.softwarepreservation.org/projects/LISP/MIT/Moon-M...

Going back further, the LISP 1.5 manual (second edition, 1965, though the printing was from 1979) has a number of numeric predicates with the -p suffix, but it does not make note of the suffix convention (https://archive.org/details/lisp15programmer00john/page/26/m... , free registration required). It does use a lot of language discussing "predicate" and use the term "p position of a conditional expression" (https://archive.org/details/lisp15programmer00john/page/22/m...), so the use of "p" for "predicate" rather than "?" seems to be somewhat well established. LISP 1.5 had a very restrictive syntax for identifiers, they were just alphanumeric.

So, I'm going to say that while it's possible that the usage of P for this purpose comes from substitutiong P for ?, all of the sources I've found seem to indicate that it stands for "predicate."

Thank you so much for all that research on just an idle question of mine! I just noticed the similarity, but you really dug into it.

It's interesting the creativity (like all art) that comes out when limitations and obstacles are met.

Why do I still have this odd desire to have my own personal line printer? Something about reading printouts on green and white paper (sacriledge to flip it over to the white side) always made debugging easier. And the sound is the best!

Even better some of the early printers (e.g. IBM 1132) had a wheel for every character position, all on a common axle, so you told the printer which character you wanted, then set bit fields in memory for which positions to strike, then wait for interrupt and repeat until you have printed all the characters that were used on that line, then told it to advance. The timing for this was finicky, to the point that the cheap 1130 wasn't capable of doing this fast enough, which was solved by IBM by making it run at a higher clock speed when at interrupt level 1. As you might imagine many of those machines spent a lot of time at interrupt level 1 doing things unrelated to printing

> seeing the "is it reproducible" checkbox on the form, and standing by the terminal with a fire extinguisher to put it out while doing the same thing to make sure the problem was reproducible.

I don't think somebody would repeat the problem just because there's a field in a form. It's way more likely that he reproduced the problem again and again before determining that the LF was causing the fire.

That part is a slight amount of hyperbole for humor value.

But the fact of the matter is, the submitter did actually reproduce the problem enough times that they were able to effectively characterize the problem.

And that's what I love about this story. Given how many bug reports I get in which no effort has been put in to trying to reproduce, characterize, or minimize the problem, I love that this reporter was willing to do enough of that to file a good bug report even for a problem that caused a fire in a piece of expensive equipment.

Yeah, that’s dedication! Most bug report handlers today won’t even try to reproduce the bug on a weaker machine. Forget fire risk!

I don't know about you, but if I ever got a bug report that says "do these things, and it will catch on fire," you can be damn sure I'd be trying to reproduce it with a fire extinguisher nearby. :P

Yes! This is why I love this story so much. I triage so many bug reports that don't even have the barest of effort putting in to reproducing or minimizing them, so it's like pulling teeth to figure out what the problem actually is.

The fact that someone put enough effort in to reproducing and characterizing a bug report for a bug that actually caused a fire is amazing!

Realistically the printer probably caught fire under normal operations, then they went through everything that happened leading up to it, one step at a time, to figure out what caused it to catch fire. That is what let them submit a bug report with "this causes it to catch fire" rather than, "Printer caught fire randomly."

In the process of narrowing down which command did it, they demonstrated reproducibility.

That’s not the definition of reproductivity.

Yes, that's pretty much what I was picturing as well. Sorry if it didn't come through in the way I told the story.

But yeah, the part of this story that I love is that as someone who reads and triages a lot of bug reports, I'm always disappointed by how few people put in even the barest of efforts to reproduce and characterize a bug.

This person, on the other hand, spent the time and effort to reproduce a bug that would actually cause a fire, and characterize it well enough that it could be reproduced and fixed.