Hacker News new | past | comments | ask | show | jobs | submit login
Print this file, your printer will jam (2008) (nedbatchelder.com)
492 points by segfaultbuserr 61 days ago | hide | past | favorite | 208 comments

My dad had a similar story about a bug report. This was back in the day when terminals still used paper rather than CRTs; actual teletypes. The bug report was something like "if I print a page feed on such and such terminal model, it will catch fire."

The bug report form (which was paper in those days) had a few of the usual checkboxes and fields to fill in, including one for "is the problem reproducible?" That box was checked. Someone had actually gone to the effort of standing by their terminal with a fire extinguisher, running the same command and putting out the fire when it caught fire again.

It turns out the problem was in some software that emulated page feeds by doing repeated line feeds. Some overflow or underflow bug caused an integer to wrap around, 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. It was using those perforated strips at the sides, with the pegs that went into the holes. The pegs and holes weren't perfectly aligned, so the pegs would sometimes clip the holes a bit, causing some bits of paper to shred and get kicked up as dust. Along with a spark, I don't recall if it was from the motor or just static buildup caused by the friction of the paper, and the paper dust would ignite, causing the terminal to catch fire.

I just love the image of whoever submitted that bug report, 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.

> 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.

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

> 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.

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

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:

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.

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:

  (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.

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.

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

"Field change order"

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

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

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!

> 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.

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.

That’s not the definition of reproductivity.

Tell me if this is a bug...

After driving a new car to work for 2 years, the traction control started kicking in on certain curves. I take a windy road to work and had never had traction control activate. When it kicked in, it pulsed the right front brake and slowed the car quickly, likely unnerving the guy tailgating me. This happened several times, both going to and from work. The road was perfectly dry, no snow or rain. Same turns at the same speed as always.

The clues are was that my rear tires had worn and I replaced them a few days before. And, I drive a Tesla Model 3. It's a rear-wheel drive version and the front tires still had good tread so I didn't replace them.

Why the right front tire?

What I finally brained out, which you may have quickly realized, is that the diameters of the worn front and new rear tires were then slightly different. The front had a lower diameter than the rear and therefore turned at a slightly faster rate when driving.

When I took a hard bank, the outside wheels also turned faster than the inside as they do in any turn. That increased the delta in spin rate the most between the outside worn front tire and the inside new rear tire. The traction control determined that the right front must be slipping and pulsed the brake on it.

I replaced the front tires and everything went back to normal.

Sounds like a safety critical bug. Rotating tires and replacing them asymmetrically (for example, after a tire explosion for me) is regular practice. If a small difference in wear disables critical safety systems and engages them in inappropriate circumstances, this can lead to deaths.

It seems simple enough to detect that, on a straight road with the steering wheel balanced, one of the wheels makes more rotations on average; then you calibrate the algorithm based on that. Sounds like a bug in this very algorithm, or maybe some hardware defect on your specific vehicle (i.e a sensor) that interferes with it.

Many AWD cars require replacing tires in sets in the manual

As a long-time owner of AWD performance vehicles (Midwest for you, possible snow eight months of the year!) I can assure that whether or not you replace your tires four, two, or even just one at a time, there are absolutely zero visible/immediately tangible repercussions and the issue described with the Tesla is absolutely not normal even under those circumstances.

As for the long term ramifications, you’ll definitely see increased wear/camber on the opposing tire(a) and I’ve read it could theoretically cause issues with the diff, but I find that extremely hard to believe at least for the cats I’ve driven, because the front:back power ratio is dynamically recalculated and changed continuously depending on driving conditions. If it were 4WD rather than AWD, that might be the case though.

Okay here is anecdotal experience. I had a set of treads on my rear tire at 15/32 while the fronts where at 9/32. Viscous coupled AWD with traction control via four-wheel braking. I first noticed something was up when the car would launch rather quickly. I added an odb-2 reader and saw my AWD clutch was engaging a lot. Thought this was by design due to my heavy foot. Then the clunking started.

The AWD would rather stay engaged which puts strain on the transmission to shift harder. Over time this showed up as increased transmission temperatures. My transmission is sensitive to heat but has a poor design which makes any heat a very big deal. At about the same time I was researching new wheels and determined I could fit 9” wide tires in the rear vs 8.5” in the front. A staggered wheel set would give me more rear wheel power bias, but the closest I could get in tire size was still almost .5% larger in diameter.

In all my research it turns out you need tires of the same size within 3/16 wear of each other to avoid non-full time AWD transmissions from doing dumb things like my car does. You see, the AWD clutch simply engages a power transfer unit and then depends on ABS to control power sent by the differential to individual wheels. That system needs to recalibrate itself regularly and it does this when the clutch disengages. When it doesn’t, all sorts of warnings are tripped (in my car I went down 6 floors of a spiraling parking garage exit at 15-20mph and at the 2nd floor a “service stabili-trak” icon appeared on my dashboard)

In cars with a well designed AWD system this will not happen.. but most cars are not designed to engage in AWD for prolonged periods of time and are really there as a beefed up version of traction control. For instance my Torsen Quattro AWD Audi had full time AWD and never had this problem nor would a Nissan GT-R. But for that fancy Lexus or Hyundai AWD, you may want to make sure you stick to the recommended tire rotation schedule

To end my story, I was at the service center and they mentioned I should get my transmission checked out by the bigger repair bay because of the clunking. I suggested it may be the wear of the tires and they agreed to see if that solved the problem. New set of tires and the clunking, extra AWD engagement, and transmission temps went away.

Interesting story. And yes, I was specifically referring to full-time AWD with or without a rear bias, like that in the Audi Quattro (who I personally think does an excellent job).

I actually don’t consider a car that doesn’t have full-time AWD to be AWD at all, isn’t that considered 4WD?

I understand AWD to be exactly that, all wheels providing driving traction. We have advanced long from the Audi 200 days to where part-time AWD is as simple as $700 in parts (for my car).

4WD (4x4) is full time (typically selectable but cannot be changed while in motion). 4WD has a greater gear ratio to really put power to the wheels that have grip, so while all 4WD cars can be considered AWD, AWD cannot be considered 4WD. I’m sure some jeep owner can give a better rundown on why 4WD is named the way it is..

In the US, 4WD (4x4) means when the system is engaged, the center diff is locked. Sometimes there'll be some combo of front and rear lockers or LSD units, but not always. When engaged, the center diff is locked, so these systems are typically only engaged off-road or in snow.

And AWD is any system that drives all 4 wheels permanently. In fancy systems, the ratio sent to front vs rear might vary from 50/50 to 0/100, but it's always engaged to some extent. These systems are safe for regular on-road use.

Pick-up trucks and truck-based SUVs usually have 4x4 systems (with a few exceptions like the Land Cruiser and Lexus GX which are both AWD).

Cute utes and cross-overs, plus the odd-ball sedans and wagons (Subaru, VW 4Motion, Audi) are usually AWD.

Edit - as noted in a sibling comment, the line has definitely blurred with fancy electronically controlled and viscous couplings, but generally "truck" = 4x4 and cross-over/wagon = AWD.

I don’t think 4WD/4x4 is a strict subset of AWD or the other way around. One is typically manually selected, the other is typically always on at a certain ratio but (at least in modern variants) dynamically adjusted (or at least theoretically adjustable) either on a front/back or even on a per-wheel basis based on dynamic real-time feedback.

TBH the line has blurred considerably in recent years and what once would have been 4x4 (manually engaged fixed-ratio four wheel mode) is being marketed as AWD. I’m sitting in a rental GMC Terrain (very crappy car, with or without AWD) and it must be manually switched from 2WD to 4WD mode but it’s an electronic button (rather than gear selection lever) that can be changed at speed, and can also be used in 4WD mode at highway speeds without redlining. This is considerably different from body-on-frame SUVs/pickups with “true” 4x4 mode that have regular 2WD but can be changed into 4L or 4H to get different gearing ratios inside the transfer case for four wheel drive.

> typically selectable but cannot be changed while in motion

Not true for a long time now. Manually locking hubs required egress while stopped but at some point 4wd tech progressed.

Yeah, the most advanced systems can switch between 4WD and RWD while the drivetrain is under considerable stress too. For instance, the F90 M5 can engage the front wheels on command while in the middle of a power slide and let the front wheels pull the car out of the slide.

M5 is not 4WD. Just an electronically controlled clutch like my car.

there are different forms of awd. Some "awd" is mechanical with even 50:50 or a 40:60 distribution of power like the quattro system that have a center differential. These systems still work great with large differences in traction: if you put snow tires on the front and regular tires on the rear, you can bust some sweet drifts and drive right out no problem. I wouldn't try bad tires on the front though. Other systems use electronic sensors and have a front bias giving 80+% to front wheels while giving rear varying amounts when the front loses traction. It reacts much slower and there is probably a bit of over/under correction from the control system if the tires don't have even traction. I could see this leading to a quickly cycling clutch that would over heat your system.

> In all my research it turns out you need tires of the same size within 3/16 wear of each other to avoid non-full time AWD transmissions from doing dumb things like my car does.

9/32 + 3/16 = 15/32 so I guess not

Opel Calibra is extremely sensitive to asymmetric tyre wear. The speed difference damages the third, central differential. To prevent the problem, you need to rotate your tyres periodically.

It’s one of the main reasons why that car is notorious in terms of maintenance.

Too bad, I love that car though.

I don't know if it does or does not actually cause issues, but the manual for my friends Subaru definitely says the tire wear needs to be even (possibly in pairs?). It came up when she got a nail through one tire about halfway through the lifetime.

Ugh this is my story right now. $500 cost for a new tire. I will probably get it patched and then put on a set of winter wheels while I figure out the next step

None. Arguing with Tesla people on the internet is like arguing with vegans... not a productive exercise for either party.

I have a guy at work who has been without a car for 4 months due to Tesla fuckups, and he basically defends Elon’s honor on the internet as a hobby.

It's almost like arguing with any other fanboy on the internet. Maybe the brand doesn't really make a difference, maybe it's just the being of a fanboy.

Some fanboys are more numerous than others.

Personally I find discussing Toyota on the internet to be far less productive than Tesla.

Make Apple Great Again

The op isn’t in an awd vehicle. He’s in a Tesla with only RWD.

Whoa, wait! >... for example, after a tire explosion for me...

I'm 72 and have yet to experience a tire explosion or be in the vicinity of one. How many have you had?

I've witnessed one on a huge truck about 300m in front of me. It was loud as hell, could feel it in my whole body. I was super confused and didn't realize what happened right away. Luckily there wasn't much traffic and the driver managed to pull over safely.

Trucks use retread tires to save money with the trade off of higher blowout rates.

The driver could pull over safely as each axle has more than one tire.

This is also why retreads are not popular these days (or illegal) for car use as you don't have redundancy if a tire blows.

This is not a bug.

I also drive a Model 3, spiritedly. Of course, I’ve rotated my tires many times, on schedule, but I replace them all at the same time. It’s standard practice. I’ve never experienced OPs behavior.

The algorithm is such that there’s a limit to the amount of “slippage” it will accept before traction control engages. A difference in tire diameters, exacerbated by a hard curve, leads to more slippage than the algorithm is willing to accept. What do you think would happen if traction control was off? :)

Furthermore, there are unknowns here - OP hasn’t specified the diameter (between 2 and 8/32’s) of their old tires. They simply stated that the tires had enough tread to meet their personal standards. Clearly traction control sees the situation differently.

Definitely a bug. If tires are within spec the traction control should not trigger, it should trigger when a wheel slips, not when it is in fact having good traction.

A bug? In a Tesla? Naaaaaaah ...

It's fine, they will update your car remotely and remove the bug. Eventually. By the end of a year.

Still want one though.

tried driving a Taycan yet?

No, there is no Porsche Taycan to rent in my area. It seems to be a very nice car.

Why would AI or fuzzy logic need to be provided with perfect sensors when human drivers are not? If you break 101 times out of 100, whoever rear ends you is at fault, 99 out of 100, OTOH..

Because traction control is a safety system and if it kicks in when you don't expect it it can turn a safe system into an unsafe one.

I guess people already forgot what caused 737 MAX

Had an '05 Jeep Grand Cherokee that LOVED to kick in traction control right at the critical moment of trying to make an abrupt U-turn. Like pedal down, lurch.... ummmm, think... ok, here's SOME throttle... while there's a SEMI barreling toward you... Ya learned NOT to try u-turns that might require haste.

Oh that seriously sucks.

My TC does the same thing. All cars after 2008 will cut throttle and apply brakes if losing traction. Turning off traction control disables this system until you press the brakes which then enables passive traction control (the car will not actively brake but will cut power)

Thank Ford+Bridgestone for this

Yes and a good driver can get you killed from good reaction time. Driving is a game of russian roulette that involves a lot of intelligences with poor senses doing random things.

Yes, but you don't add extra complications to see if the drivers reaction time is 'good enough' or not, especially not since (1) this is a solved problem and (2) it is supposed to make you safer, not less safe. Tesla should simply fix this.

Then maybe follow your manufacturers maintenance guidance and stop assuming all cars are made the same?

This is table stakes for TC which companies like Bosch solved and commoditized. I don't know why you're defending it.

Sounds like fail-safe design. It decelerates instead of spinning out of control. You’re overreacting a bit.

Traction control can selectively apply the brake to the wheel that it thinks is spinning too fast. If the wheel isn't spinning too fast that that can throw the vehicle into a skid (the reason traction control exists is to avoid going in to a skid).

So it's not just decelerating the vehicle, it's decelerating the wheel that it thinks is rotating too fast to make it match the speed of the road. When in a curve as described by the OP if the wheel is a front & driven wheel this could cause severe understeer causing the car to move further out, which will in turn cause the inboard wheels to slow down further relative to the outboard ones. This could cause a positive feedback loop. Note that if you start braking one wheel that's on a diff the other wheel will attempt to speed up.

It may be "within spec" for a Tesla, but other brands with traction control don't have this problem. And that is a typical issue with Tesla, they have too many software guys and too little real world automotive experience. So they'll create these kinds of problems by implementing their own things instead of going with proven existing tech.

The most rampant example was the rain sensor on the early model S. They decided not to buy the same perfectly working sensor that any German car had for 10+ years at the time, no they decided to implement the rain sensor by training some image recognition on the camera that's behind the windscreen. Worst idea ever, because it meant the 100k+ euro Model S had no automatic wipers for a long time and when they got there it was worse at detecting rain than the standard sensor on a 20k euro VW Golf...

To specify further: this is a problem in Teslas with autopilot 2.0+ hardware, where they switched from 1 front facing camera to 3. That left no room for the Bosch rain/light/humidity sensor, so they put developed their own light/humidity sensor, but still didn't have enough room for rain sensing hardware. The solution was left up to the autopilot team since it was assumed (wrongly) that sensing rain using a camera was easier than using specific optical sensors designed for the task.

Source: I worked on the replacement TH sensor.

It is an odd design decision, since I assume a rain sensor at its core is simply an LED and a light sensor carefully arranged. Total cost of the core components: $0.03. Neither need to be physically large either.

It's even more odd considering the cameras can totally also be used as light sensors (simply read back the exposure time for example). Why get rid of one unnecessary sensor without getting rid of another?

I wonder if perhaps it was done to force the vision teams to become less science/research oriented and more 'we need this result now, we have angry customers waiting' based.

Mine thinks that a chip in the windshield is a raindrop. I had to turn off automatic wipers.

I believe tesla will recalibrate all this after you drive for a certain distance.

Thing is - they would get complaints because the system would disable certain functions with a message during recalibration.

I wonder if they have now turned the dial too far the other way.

If they can't recalibrate in the background, that's an entirely different problem. It's not a matter of turning a dial, it's fixing a flaw.

This is a bug.

The slippage calculation should take tire size into account. Anything else gives you wrong numbers.

uhoh. you're going to rattle the Tesla fanbois.

This is a bug...

The system should learn the tyre diameters after driving a half mile or so on a new set.

Are you a car safety expert or is this your assumption how a car should behave?

I doubt it is a road safety requirement for a car to learn tire diameters.

>I doubt it is a road safety requirement for a car to learn tire diameters.

If you want to have hair trigger traction control systems then it kind of is.

You do tire rolling radius adaption. Otherwise you can't have fancy traction control.

A leaking tire will also give smaller rolling radius and that is usually how leak warnings works.

It's standard for most cars to detect the tire diameters. Not in the last place because most "sports car" brands also allow you to choose a different width rear tire. And that typically also has a slightly different diameter.

They do learn tire diameters, they can even detect a flat using this information.

And to be clear, flat detection using slippage, dynamically calibrating to the actual tire diameter, is the cheapest way of doing it. Since flat detection is required by law, at least in the EU, every 10k€ new car sold in the last 5 years does it. Tesla does some marvelous stuff, but they also have some unbelievable inability to provide functionality that is nowadays just expected from a car.

In one of my cars (124 Spider) the method used to detect tire pressure actually depends on the trim chosen for that reason

I chose one that comes with performance oriented changes and interestingly enough that includes using a direct TPMS sensor in each wheel

Meanwhile the base trim uses an indirect system designed around the ABS sensors

Many cars like 4WD require all tires to be replaced at the same time to avoid weird issues like this with the automated systems

There might be some software issues at play with some modern AWD systems that I am not aware of, but it's traditionally a mechanical issue with 4WD and AWD. 4WD has a physical link, so having two different diameters linked stresses the links and tears the rubber. With AWD there is a differential, and different diameters cause mechanical stress and wear in a mechanical diff.

My understanding is that AWD has computer controlled power distribution and 4WD has a diff. My 4WD has a (lockable) center diff.

Not quite: AWD has diffs between each of (FR,FL), (RR,RL), (F,R).

4WD has diffs between (FR,FL) and (RR,RL), but it has a transfer case (like a permanently locked center diff) between F and R.

So you’re not supposed to use 4WD on dry asphalt roads because the natural slippage between front and rear has no easy way to release itself.

Modern diffs are usually limited slip, which helps prevent spinning tires. LSD can either be mechanical or computer controlled. Computer controlled LSD can apply brakes to individual tires.

Interesting. So I think I technically have AWD, but I do have a transfer case with a 2X reduction available and a locking center diff.

That would be probably most cars with some form of electronic differential lock (EDL), similar system to the one described here.

It's a terrible bug, but at least Tesla should be able to fix it quickly.

Just need to add a check that calculates the average of these values over the past few hours or days, and decides to modify the tipping points for traction control accordingly.

Did you consider contacting Tesla and submitting a bug report?

Isn't individual rotation speed how most cars detect underinflated tires? I imagine this problem would also happen if the tires had different tire pressures.

I believe some older cars used this method. Nowadays, all the monitoring systems use little sensors mounted on the wheel to transmit pressure information.

Not a bug. This is a weird but documented phenomenon. There are multiple published technical bulletins on similar issues caused by uneven tire wear/replacement. I must admit that I never came across traction control false activation due to 2 new tires. I have seen burnt transfer cases on AWD with this though. Were you advised by a shop to change just 2 or was it your independent decision?

Why not just move the tires from the front wheels to the back?

Just so the laymen here don’t think this is some kind of hack, this is what is referred to as “rotating your tires”, which should sound familiar.

The problem is that tires are often not rotatable due to staggered setups where the front and back tires are different sizes (very common) or due to directionality of tires (less common).

Different sizes means you can swap left to right and right to left. Directionality means you can swap front to back and back to front. Directional tires of different sizes means you can’t swap a damn thing (as drivers of Porsche and some BMW configurations find out quickly enough.)

In commercial tire shops in the US the tires with the most tread always go on the back regardless of any other consideration.

This is because losing traction in front causes understeer, which is usually easily managed by typical drivers. On the other hand losing traction in back causes oversteer, which is often very rapid in attack and severe in extent. For some vehicles it is essentially impossible for a non-professional driver to maneuver out of an oversteer event.

So for safety sake the best tread always goes on the back. Most shops will refuse to do anything else.

Then there is my eldest daughter.

“Dad, car has been a little bumpy for the past month”

I hop in go down to road. Experience is best described as driving on square tires. https://youtu.be/QF7odK55gkI

Both front tires had massive bulges sticking out.

She had been driving like that for a month.

She's your daughter...

Oh I have my own stories of being completely oblivious, or not wanting to bother others.

However she was a special needs adoption due to age. Only had her ~4 years at that point.

This is one of those myths that just needs to die.

"Put the good tires on the back" is a terribly inaccurate rule of thumb. Whether you want the good tires on the rear or the front is gonna depend on how the vehicle handles. Most modern mom-mobile type crossover are so biased toward under-steer (usually from a combination of rear weight and stiff front sway bar) that they need all the help they can get up front and putting the better two tires on the rear is just wasting traction because that end was never going to break traction anyway.

Also, Firestone happily puts fronts only on my junk.

The problem is that vehicle handling is dependent on equal grip from all 4 tires. When you introduce differential in traction front to rear, you can throw the "understeer or oversteer bias" directly out the window. Modern cars do a great job compensating for less than ideal conditions but there is a limit. If you still think the new tire on the rear rule of thumb is inaccurate, watch this:


Re-read what I said. I'm specifically talking about the ass-heavy FWD crossovers and minivans that dominate the roads today (though I suppose there's a few FWD sedans out there with similiar handling). They all have a very respectable sway bar up front for good "car-like" handling and they all have a lot of weight out back. This results in a class of vehicles that mostly cannot go sideways even if you try (and believe me, I have tried). Someone with one of those cars comes in with four nearly bald tires and wants two good ones put on and you put them on the rear then you have improved their handling by exactly zero because the fuse in the system is still the front traction. Adding more rear traction doesn't help because handling/performance is determined by the weakest link in the chain and that's still the front which is unchanged . If you put the tires up front then sure, there's a 2% chance of going sideways rather than a 1% chance but you've also improved the handling greatly by addressing the weakest link which is end that was lacking in traction. The vehicle will corner and stop much better because the threshold for loss of traction is much higher.

Does this make as much sense for front wheel drive cars? Both of my FWD cars get front tires to wear more, and if I wanted to keep the better tread on the back, I'd never rotate them, and fronts would wear out much faster than the backs.

Not to mention that front wheels also have bigger brake rotors, so worse tread up front would also mean worse breaking.

Definitely makes sense on FWD cars, common throughout Europe. And indeed we don’t rotate tyres here, as you point out, the front ones wear out faster anyway, so when they’re dead you move the back ones to the front and put new ones on the back

Far better to lose some steering and braking power from worn front tires than to have your back flip out on you

But back wheels only rotate as a result of moving against the ground. Grip on the back tires seems most important for balanced braking.

I am likely missing on some obvious basic physics here, but I wonder how does better grip in the back on a FWD car help reduce oversteer. Any pointers?

I guess the easiest way to see it in practice is in winter when FWD cars put snow chains on the front wheels. As long as they’re driving uphill it’s OK, but as soon as you drive down the mountain you’ll see cars spinning out of control. At the slightest turning circle, The inertia of the car will push the back out, and 99% of drivers don’t know how to deal with that situation- so they brake and try to turn harder, which makes things even worse.

Obviously if everyone was used to driving RWD and countering oversteer , you wouldn’t need to put the best tires at the back. But the reflexes for the vast majority of drivers are to brake of things get tricky (which is perfectly fine for normal FWd driving)

Does any of that matter for cars with ESC?

Yeah isn't this why you should rotate your tires regularly?

You get downvoted but yes, that's the reason for swapping front to back and vice versa.

Might have different tire size front and back - https://tiresize.com/tires/Tesla/Model-3/2020/

That sounds unreasonable to me. The (virtual, on a Tesla?) differential should allow at least the amount of slip induced by a new tire.

I may have told this story before (perhaps back in 2008 if this was posted then) -- but my first gig in tech was QA for Hewlett Packard testing printer/scanner/copier units. At some point I scanned a photo of my then-girlfriend and crashed the unit. Was able to do it repeatedly, provided I scanned the image in straight/cleanly. I didn't come across any other images that reproduced the issue, only this one photo. The underlying bug was a buffer overrun of some sort, was fixed before shipping -- and the image became a part of the durable regression test suite for that department.

Not surprised there was a bug, but I am surprised it was patched (before or after shipping). I have an “enterprise grade” HP scanner (3500 F1) with buggy Twain drivers I had to manually disassemble and patch that will crash any time you try to duplex scan a single-sided sheet of paper. The blank page detection algorithm caused a null pointer dereference if two-sided mode was selected but the second side was elided.

The bug reproduced 100% of the time with all available versions of their drivers in any application using the TWAIN rather than WIA or proprietary scanner interface. It was as simple as scanning any one-sided document in duplex mode. I escalated the issue to their engineers who kept insisting the issue was with my PC until the product was EOL’d just a year or two after production.

I had other hardware issues pop up and ended up getting a Fujitsu for ADF document scanning and keeping the HP for scanning photos with the flatbed. Not many stand-alone hi-res dual color ADF/flatbed scanners out there.

If you're in software, you probably know this, but your bug was likely ignored not because it couldn't be reproduced, but because the engineers on the project were prioritizing feature work for the next version of the scanner, and did not have any support from management for fixing bugs in an already-shipping product. Sadly, driver software quality tends to max out at the level where customers won't return the hardware for a refund, and then the company abandons it and works on the next shiny new device.

> If you're in software, you probably know this, but your bug was likely ignored not because it couldn't be reproduced, but because the engineers on the project were prioritizing feature work for the next version of the scanner, and did not have any support from management for fixing bugs in an already-shipping product.

Well, yes, but is it normal to insist no bug exists?

perhaps if HP support admitted there's a bug, depending on the support contract (if applicable), HP would have had to fix it

That is actually correct.

Well, that's why the parent commenter was surprised that the scanning bug in the grandparent comment was fixed at all.

I can't help but wonder if Alexander Hamilton or Benjamin Franklin would cause printer problems too (for a different reason)

Counterfeit protection does work on image recognition, but not necessarily the faces. https://en.wikipedia.org/wiki/EURion_constellation

This makes me wonder what'd happen if you had the EURion tattooed on your face.

Sad that this rings a GDPR bell in my mind.

You don't need GDPR for this to have legal issues.

As an amateur photographer, I'm pretty sure that you'd formally need a model release form for a commercial use of it to be legitimate[1].

Of course, as with any legal issue, the company would weigh the probability of it being enforced vs. the hassle of doing it right... and it's pretty clear where the balance is in most cases.

[1] https://www.dmlp.org/legal-guide/using-name-or-likeness-anot...

That's a publishing consideration, not really an image in a box in the engineering lab consideration.

As far as photography is concerned, the act of making a photograph and giving it away to someone constitutes publishing. Here, the engineer published the photo by giving it to his employer (and making it a part of the test suite).

Not publishing would be keeping it to himself, which the engineer did not do. For all we know, his girlfriend did not consent for that photo to be distributed to other people. Model release forms exist for that reason.

But that's not merely a publishing consideration anyway; the law is more general than that.

In the end, it's someone's face being used for a commercial purpose without consent, and this is exactly what the law is about.

Everything is commercial if you squint hard enough.

Is it enough to buy her bottle of wine or something in exchange for being able to keep the photo indefinitely?

It's up to her. Some people are OK with that without being compensated. Some aren't. That's the reason model release forms exist.

What if her name was Lena?

Lena Forsén's photo was taken from a magazine - the appropriate model lease forms have surely been signed by her at some point.

My favorite bug like this was me in my buddy's 2000 VW Jetta. The car had some electrical issues, but my buddy once remarked that the windows stopped working whenever he gave me a ride.

I'm 6'4" and always slide the seat back whenever I get in a car. Turns out the circuitboard controlling the windows was under the passenger seat and had come loose. Moving the seat back caused a short, "breaking" the power windows.

Turns out, the windows _did_ stop working when he gave me a ride.

edit: "I have him" => "he gave me"

I had a Citroen ID 19B which had a pretty neat quirk: the starter relay would only get power if you switched on the headlights. I don't know if that was on purpose or not (some primitive anti-theft device) but I left it in because it was actually a neat feature.

It’s a legal requirement to have headlights on any time the car is in operation (day or night) in some territories and manufacturers had different ways of enforcing it. Some unconditionally turned on the headlights for models sold in those countries, others had special variants earmarked for export to those countries. It seems Citroen found a clever way that didn’t require too much fiddling to meet the legal requirement.

Not in 1968, the year that car was manufactured in, and none of the other ID's that I've seen had this particular quirk, it was either done by one of the (many) previous owners or a fluke. The wiring in those cars got very brittle over time and shorts were pretty common. That car came from France to NL (I imported it).

Anyway, it was a fun gimmick and it helped to dissuade people from taking it for a ride. I never did find out if it was on purpose or accidental, that dash was not one to disassemble if you didn't need to.

Ah that would indeed be way too early for what I’m talking about; the earliest laws for mandatory operation or non-switchable daytime headlamps on a nationwide, full time basis I can find after a cursory search is Canada starting in 1989. Before that many countries had requirements that applied in certain areas or at certain times of the year (e.g. Finland on rural roads starting 1972) which would not account for such a design.

If you find yourself in such a car and needing to drive or have the car running with the headlights out, you might try setting just the first click of the emergency/parking brake and see if that turns the headlamps off.

That is such an offbeat fact that I am glad to learn it. Thanks for sharing!

Lol “OpenOffice can’t print on Tuesdays” https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...

Back in the days of Windows 98, the HP LaserJet caused no end of headaches for me. The problem that was introduced by the compiler they used to build the print driver. To compute the paper size, margins, etc., floating point operations were used... but by then the driver had allowed the libraries that emulated the floating point processor to be unloaded, to save memory. (Due to the optimizing compiler)

Any operation that involved computing the page size would crash, only if the floating point library had idled out of memory.

I ended up forcing the library to be loaded at boot on all machines, and then things were stable.

One thing which I always considered a misdesign in Windows, is its tendency to run third-party code in-process. This includes COM objects, printer drivers, and many more.

We had a problem similar to yours at a previous company. The software was written in a proprietary language which had its own runtime, and that runtime expected a particular value for the floating point control word. There are some third-party DLLs, including some printer drivers and Explorer extensions, which when loaded overwrite the floating point control word with their own notion of what should be the correct value (this behavior, as far as I could determine, is introduced by the compiler used to build these third-party DLLs). The unexpected value for the floating point control word would then lead to crashes, but these crashes would not happen immediately, and they would only happen if the user had done something which led to one of these third-party DLLs being loaded, like opening/saving a file (the open/save dialog in Windows loads Explorer extensions) or printing (which loads the printer driver).

The solution was to, after every point in the code which opens a file chooser or prints anything, call into a small stub DLL we wrote, which had code to reset the floating point control word to what the runtime expected.

It's worse than that, at one point printer drivers were run in the kernel. I remember a customer site where just opening a queue blue screened the server.

Yeah, I've had a variant of that, wherein the printer driver turned on fpes.

What is the floating point control word?

The floating point control word is a register in the Intel 8087 FP coprocessor and in all later Intel/AMD/etc. processors that implement the 8087 instruction set.

That register contains bits that control various aspects of how the floating-point instructions must behave, e.g. rounding mode, precision and exception masks (also infinity type in coprocessors older than 80387).

For the later SSE/AVX instruction sets there is another register with similar control bits for the SSE/AVX instructions.

Related issue:

>There have been various instances in the past (printer drivers from a manufacturer who shall not be named) that would enable floating-point exceptions and leave them enabled, meaning that some perfectly legitimate software would start crashing after calling into third-party code (such as after printing).


No wonder that one of the DevOps success stories revolves around HP printer drivers and firmware:


I got my start at Xerox working in their photocopier "QA" department. I say "QA" because it was more a factory setup than quality assurance office. Anyway we had test cases in folders with instructions on the front to configure the copier. Just the usual things like two-page scan to offset or collated with staples and a cover sheet, etc.

Every now and then a "strange" case would be sent down of a certain job type that would cause the copier to break and hit "UM" or "unscheduled maintenance" exactly like this story.

Had some interesting things pop up such as very creative ways people managed to bypass the currency detection to prevent printing (totally crap) currency copies or causing the printer to fail correctly printing the Machine Identification Code, even one scan to email job that caused a crash in the SMTP client so it would endlessly loop sending the same scan to the same email address every 5 minutes (300 second timeout) until you rebooted the machine.

Fun times! This was actually how I got started with software development. I was interested in the copiers ESS (Electronic Sub System) which was a very basic Intel system running LynxOS essentially bolted to the back of the copier. I was chatting to some of the OS devs about RTOS and how it differed from a "normal" OS so learnt C with books they gave me and answered many of my questions.

From there I managed to get a job up in the "real" QA department testing the printer drivers for Windows 9x, NT4, 2000 and the "soon to be released" Windows XP (or Whistler as it was known during development). I learnt how to use the Windows Debugger and about printer driver development which almost made me want to leave humanity and live in a cave somewhere in South America (:

Luckily I got to move into the "nicer" world of C++/MFC and then .NET (anyone remember Managed Extensions for C++ aka C++/CLI?!). Like I said, Fun Times!

I hit a similar issue in OpenGL on macOS about 10 years ago. We had a fairly complex set of draw calls. It worked fine on high-end machines, and was perfectly usable, if a bit slow, on mid-range machines, but on low-end iMacs with crappy Intel graphics cards, it would cause the machine to panic and reboot.

It ended up being that the draw calls filled up the smaller command buffer on the low end card, and the driver would crash. In talking with the implementors, they explained the situation, so I asked, "How do I determine that I'm filling up the command buffer?" The answer was basically, "The size of the command buffer is an implementation detail and there's no way to query OpenGL for it or for the size of the commands you're adding." Gee, thanks!

We ended just breaking up the draw calls into more smaller calls and it solved the problem, but this entire bug was such an ordeal. Thankfully we're moving away from OpenGL and things are a bit more sane in Metal. Had I not had access to the OpenGL team at Apple at the time, there's no way I would have been able to figure out what was going on. I'm not sure if I would have thought to do the same work in smaller batches.

I wonder if this was related to a kernel panic bug I ran into in Chrome around the same time! Long story short, we were using a library (Modernizr) on our web product that checked for some kind of OpenGL support that we didn't actually need, and just running that code would trigger a driver bug. Disabling that fixed it!

That's a driver bug.

For the last 5~7 years, thousands of software-only programmers have been discovering Arduino and Raspberry Pi, and have been learning about the real-world consequences of interfacing to hardware. I help out at a local hackerspace and the excitement of someone discovering a software/hardware interface bug is contagious.

Here's an example: someone was trying to make a plant watering machine and was using a FET to control the DC motor. The wire to the FET was about 15 feet long so the slope from the poor GPIO was horrendous, and the motor would basically brownout because it couldn't overcome the initial stall di/dt. The idea that not all edges are perfect 90 degrees was eye opening to him.

Oh, dang, yeah. Hackerspace here too, and software people colliding face-first with electrical reality is an endless source of learning, amusement, and project delays. Some quality time with an oscilloscope goes a long way, but still cannot overcome all stubbornness.

Is that because many software programmers use “genetic coding” techniques where bugs are randomly fixed until the software works? Or were you mostly dealing with newbie programmers?

It’s not like software doesn’t have similar failure modes to hardware, right?

I don't think it was... maybe? I've seen people hack circuits they way they hack code: keep trying small tweaks until it works. Then when they connect two circuits and it doesn't work, they go back to the fundamental RTFM. It could also be the skillset: circuits are more a creative art form, logic is more... logic. (But that doesn't always hold because I've encountered cache/CAM RTL designs that were beautiful.)

Failure modes are different. A transistor can go bad if you accidentally drove it too hard, so now you might need to replace every part until the circuit works. And maybe one of the xtors in your box is bad. Or maybe a wire isn't making a good contact. Just the physical aspects alone without bringing an oscilloscope into the mix ("Why is my signal so noisy? Oh, it's the fluorescent lights, or the cheap USB hub noise in 400MHz spectrum, or the wall-wart...") can be maddening.

Mostly I think the people I helped out seemed to forget that "digital" only exists inside the O/S, whereas the real world is analog, and real-world debuggers are more abstract than using, say, gdb or journalctl.

But then I work with MY mentors, and they have an even larger set of debug skills based on extensive component knowledge that reminds me of chess grandmasters who know all the openings. E.g, being told I'm using the wrong OpAmp because that particular device's temperature sensitivity isn't suitable for frequency-range I'm designing.

There are some reasons Electrical Engineering is a thing. When you open the datasheet for a chip, all the cool numbers in nice tables are not just there to be pretty, but because they are useful to design a circuit to put the chip in... And then you have your classic engineering subjects applied to electrical circuit constructs, like filtering, stability of feedback loops, etc.

In the end you can design simple/medium-complexity digital electronics PCB with some common knowledge on PSUs, digital interfaces (including layout/return-current/impedance control) with the right tools, but non-trivial analog I would not even bother, I leave it to people with a real training in this field.

I have seen a bug where the device came from clients completely wiped. Mind, that this device has been distributed to millions of people. We would see couple hundred of these came every day, with completely clean flash.

The interesting part was that nowhere in the code was any sequence that could clear the flash.

After very lengthy and expensive bug hunting we have determined the cause.

The flash protocol had an unlock sequence that required a bunch of magic operations before the write could be performed. Somebody, at some point decided to use "unlock bypass" function to disable this magic sequence, ie. allow writes without magic bypass sequence. This was done to improve write performance when the software was upgraded in the field (with customers potentially impatiently waiting for it to complete).

Unbeknownst, there was a coupling between a remote part of the circuit and the lines between MCU and the flash that caused noise to be introduced to the communication. The unlock sequence was the only thing that prevented noise to be interpreted as valid operation. The probability was still very low of this happening, but with millions of devices in the field it was enough to get about 100 failures a day.

That's nothing. With Star Trek computers, type in something illogical and either the computer will explode or the poor keyboardist will get electrocuted and thrown across the bridge.

I attribute much of the trepidation from early computer users to typing in the wrong thing to having watched Star Trek.

From the comments, the 500-mile email: http://www.ibiblio.org/harris/500milemail.html

This brings me back to night shift production support: My infrastructure buddy came to my desk at about 1 AM and said, 'Hey, I emailed you a Word doc, could you print it for me?'. I opened it and hit print and my computer immediately went to blue screen. He said 'Yea, that happened to me too, I wondered if it was just my computer'.

Nowadays, the suspicion meter is much more sensitive.

This reminds me of a fun story about another unusual failure mode involving some supposedly valid (but highly specific) input content: Where listening to a certain podcast in your Mazda will reliably crash the car's stereo system.

"The Roman Mars Mazda Virus" https://gimletmedia.com/shows/reply-all/brh8jm

That one was wonderful. C programmers would stop at the mention of '%' and go "aha!", but no!

It's reassuring to know that printers have always been crap.

Can we appreciate, though, the mechanical difficulty of a machine dealing with a stack of microns-thin sheets and precisely plucking 1 of them at a time off of it fairly consistently despite variances in environment humidity and paper thickness? Probably static electricity plays havoc in some cases here.

I've worked with million dollar printing equipment in a factory before and it needed daily coddling as well.

On the other hand, the printer software/protocol/driver developers have no excuses at this point. There's no reason for that to still be as bad as it is in 2020.

Honestly, paper jams and messed up pages and dry ink wells don't enrage me too much because that's where I appreciate they have a difficult task.

It's the trash-fire software and the hilariously opaque UIs and the obscene razors/blades business models that drive me nuts.

That said I don't hate my current Brother networked printer/scanner but that may simply be because I basically never print anything.

Reminds me of a box machine at a local plant. Kept messing up and manufacturers trouble shooters were brought in. When they got there they found one of the workers sleeping on the pile of cardboard. Problem solved.

Printers being crap led to the Free Software movement and the GPL

Please tell?

> In 1980, Stallman and some other hackers at the AI Lab were refused access to the source code for the software of a newly installed laser printer, the Xerox 9700. Stallman had modified the software for the Lab's previous laser printer (the XGP, Xerographic Printer), so it electronically messaged a user when the person's job was printed, and would message all logged-in users waiting for print jobs if the printer was jammed. Not being able to add these features to the new printer was a major inconvenience, as the printer was on a different floor from most of the users. This experience convinced Stallman of people's need to be able to freely modify the software they use.


My 2 least favorite things about computers: Printing and Fonts.

Importantly, it was the two things that early Macs got right. Other than price, a 1990 Mac/LaserWriter combo is superior than a modern equivalent.

Current status of apple printer setup seems right to me too. I'm happy that I can print wirelessly from macOS or iOS, without installing any drivers or configuring anything (other than the wifi password).

Yeah Apple typically get printing and audio right. Hi res too.

Lots of things they aren’t so strong on but they have always been good at the above.

This is why I love bugs, especially the sporadic ones--often you grow in understanding of the underlying system or code as you solve them.

> especially the sporadic ones

Yes, but there's only a fine line between "sporadic but solvable by analysis" and "too sporadic to be reproduced or solved..." Device driver problems are often from the second category... Nevertheless, it can get interesting if the problem is reproducible like the "500 miles email" or this printer.

Nothing is too sporadic to be reproduced, you just haven't found how to reproduce it yet :)

I once solved a once-in-a-petabyte bug at Google, when I was still working there. One of our systems ran in two data centers on the same data, and the cross-check was detecting a record offset mismatch but not a data mismatch (?!); retrying the process almost always fixed it. Long story short, there was a buffer overread in Google's bespoke zlib compressor that caused it to emit slightly less efficient compressed data (one or two bytes longer) nondeterministically, even though the data was perfectly well-formed. We were detecting compressed records being at different offsets, even though the uncompressed data matched.

Another Google one involved doing a postmortem on a single instance of bad data ending up on a system. I traced that back purely from logs to having been caused by a kernel panic two systems upstream, that caused disk data to not be flushed while metadata was, so on reboot the system picked up garbage from the disk sectors in the file, which turned out to be well formed data from a different file and it trickled down the layers.

Also, this one has made the rounds on HN a couple times (second time I fix a golang runtime heisenbug too; first one was also fun):


And I recently fixed an OBS bug that has been randomly crashing audio for streamers for at least 3 years. I found a reliable repro that involved scripting monitoring mode toggles dozens of times per second; along the way I found and fixed 3 other bugs. That one was exacerbated by some of the OBS developers having built a rhetoric that those failures were caused by user configuration mistakes, because they often went away after changes - when what was actually going on was that users were blindly trying things to solve the problem, and sometimes stumbling on a somewhat stable workaround. (That one hasn't been reviewed/merged, still in the pipes).

Then there was that bug in The Homebrew Channel that I introduced after adding freetype/TTF support... That was a heap corruption that was crashing things way later (embedded baremetal code, so no memory protection or debugging tools beyond remote gdb). Finding that one ended up involving dumping memory around the corrupted heap and following pointers to what eventually turned out to be graphics queue entries, then following texture pointers and teaching myself how to read swizzled character textures from hexdumps... I eventually found I was not allocating entries for space characters in strings, but was incrementing the index on spaces anyway.

Lots of fun bug hunting stories...

Funniest bug report i had to deal with was when i was working in a company building iOS apps, and one of our testers filed a bug with the following reproduce steps:

1. Open the app

2. Rub the phone screen on your shoulder to clean the screen

3. The app will crash

Perplexed, i tried it, and couldn't reproduce it. I went to the tester to ask about it, and even though it was hard to reproduce, he managed to crash the app a couple of times. Turns out there was a bug in handling multitouch gestures which was interacting with his clothing.

Any change of state in a system with inertia should have hysteresis! In this case, a minimum duration before restarting would have done the trick.

> Any change of state in a system with inertia should have hysteresis!

Or noise.

Here's a semi-related question that maybe somebody can answer.

Why is it that despite listening on TCP 9100, some printers will just print the source code when you send them a PDF or Postscript file with netcat?

Is there some special PJL command to put it into Postscript mode? Are there any networked printers around nowadays that don't support Postscript?

“...despite listening...”

Yes, there’s a protocol behind that port. Just like there’s one behind port 22, 80, 443... you can’t just dump http to 443 and get a useable document in return.

Actually that is exactly how the printers listened on port 9100. You open a connection and dump the raw print file. This "protocol" was introduced by HP with their JetDirect print servers.

> you can’t just dump http to 443 and get a useable document in return.

Not on 443, but on 80 you basically would. You'd just have to skip the response headers.

>Is there some special PJL command to put it into Postscript mode?

>Are there any networked printers around nowadays that don't support Postscript?


> Why is it that despite listening on TCP 9100, some printers will just print the source code when you send them a PDF or Postscript file with netcat?

Not all printers interpret those languages on that port. For example, Zebra printers interpret ZPL there, and I think most Postscript would look like plain text to a ZPL interpreter.

> Are there any networked printers around nowadays that don't support Postscript?

I'd be somewhat surprised if most label printers and receipt printers accept Postscript. I wouldn't be surprised if there are more niche types of networked printers where it might not make sense to support Postscript.

A lot of printers, by default, function like an ancient teletype. They interpret incoming data as something like ASCII and print out the text. You need to send the correct escape sequence (i.e. a sequence of bytes starting with 0x1B) to switch into a more modern mode.

A lot of Postscript printers are configured to print source code when there’s a syntax error in the file. My 2017 HP laser printer has this as an optional feature.

A lot of printers default to PCL first which allows plain text printing. Some will auto detect the language but to be safe you would use PJL (Printer Job Language) to specify the print file format.

If you keep jamming few times, it would heat up the printer which would change the absolute clock frequency and the printer would start working again - just a thought. As a software guy, "it works locally but when it is tested in production real world, it does not", lol

Considering PostScript is Turing complete, it is still possible, and will always be possible, to make a PostScript file that takes 3 seconds to interpret, despite advances in CPU technology.

Have modern laser printers solved the problem mechanically?

Computing power is cheap enough that I'd expect modern printers to just rasterize everything ahead of time before even starting the printing mechanism so this would eliminate this problem and make the logic simpler.

I work on mobile games and my favorite QA report ever was, "game crashes when banana placed on screen, does not repro with other fruit"

(it was actually a boring enough bug, the banana triggered a lot of touches all at once)

Did you actually get a banana to test it?

When I have had to build out SCM systems the bane of my existence always seems to be working with printers.

I understand that we now have wonderful tools like cups that abstract a lot of the worst of it away from us, however even today minor discrepancies between models/drivers/environments have always given me headaches. Especially when trying to deploy systems in facilities with physically antiquated hardware. I swear I would encounter issues similar to the one described in this article every time I had to make a new deployment.

I really wish this was an industry with a little more standardization.

Slightly related: Has anyone had their modern HDMI monitors change color (over the whole screen) when a small portion is displaying a heavily stippled image (like a classic MacOS screenshot?)

My printer jams with anything I want to print. I do not even understand how we got here. There are 21313 different software installed on my system because of this printer and it is pretty useless.

My printer consistently prints the large 'F' logo in first class postage upside down.

Definitely a bug.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact