31 ms·

“My wife has complained that OpenOffice will never print on Tuesdays” (2009)

419 points by hardmath123 10y ago

alblue 10y ago
The TL;DR is that the "file" utility was miscategorising files that had "Tue" in the first few bytes of a file as an Erlang JAM file, with knock on effects for PostScript files generates with a header comment with Tue in the date.
- kaizensoze 10y ago
  The circumstances under which I discovered/reported the bug were totally coincidental too. I noticed a friend use the file command and thought to myself "Hmm I've never actually used that command before. Let me try it out." Ran it on a TODO list text file I had lying around, scratched my head over the "Erlang JAM file" output, and went from there.
- wrs 10y ago
  Because it was trying to identify that type of file by looking for a particular full date string (bizarre in itself) and the wrong syntax was used to specify the string (unescaped spaces).
mpeg 10y ago
The title reminds me of "the 500 mile email" http://www.ibiblio.org/harris/500milemail.html http://www.ibiblio.org/harris/500milemail.html
- K-Wall 10y ago
  This is one story I always enjoy when it is brought up.
  - ChristianBundy 10y ago
    Me too. Are there any others you could recommend?
    - kirrent 10y ago
      Real programmers don't use PASCAL never fails to crack me up. A bit closer to the grandparent comment is the famous story of Mel. http://web.mit.edu/humor/Computers/real.programmers http://web.mit.edu/humor/Computers/real.programmers https://www.cs.utah.edu/~elb/folklore/mel.html https://www.cs.utah.edu/~elb/folklore/mel.html
      - nickpsecurity 10y ago
        Real programmers was the funniest shit I've read in a while. Even had jokes embedded in the references like the Lucasfilms one. I needed that laugh. :)
    - dandelany 10y ago
      Some of my favorite hacker folklore: Always Mount a Scratch Monkey http://edp.org/monkey.htm http://edp.org/monkey.htm The Magic Switch https://www.cs.utah.edu/~elb/folklore/magic.html https://www.cs.utah.edu/~elb/folklore/magic.html Quake3's Fast InvSqrt() https://www.beyond3d.com/content/articles/8/ https://www.beyond3d.com/content/articles/8/ The Battle Chess Duck http://blog.codinghorror.com/new-programming-jargon/ http://blog.codinghorror.com/new-programming-jargon/ (#5) and of course, The Story of Mel, a Real Programmer https://www.cs.utah.edu/~elb/folklore/mel.html https://www.cs.utah.edu/~elb/folklore/mel.html edit to add: Ford and the $10,000 chalk mark (Ctrl+F Ford) http://www.smithsonianmag.com/history/charles-proteus-steinmetz-the-wizard-of-schenectady-51912022/ http://www.smithsonianmag.com/history/charles-proteus-steinm...
      - frank_jaeger 10y ago
        Big second for Quake's Fast InvSqrt, that is a really cool story.
      - Splines 10y ago
- n72 10y ago
  Great story. Also, never knew about units.
Adaptive 10y ago
I've noticed that printing is still one of the poorest UX aspects of *nix/OSS and regularly seems to suffer from errors so egregious that they can only be attributed to OSS devs not dogfooding these features. I'm assuming they just don't print much (I mean, we ALL print less than 20 years ago, but all the more reason to test these features which, when you need them to work you REALLY need them to work).
- ultramancool 10y ago
  Perhaps you're thinking back to the days of manually configuring CUPS? Any recent printer I've used has just been plug it in and hit print. A better experience than Windows in terms of included drivers and bonjour support too.
  - dbcurtis 10y ago
    No, you've simply been lucky.
    - chrisfosterelli 10y ago
      I can say my experience matches the above posters as well. Printing in Ubuntu works better than OSX and Windows for the 4 different printers I use regularly.
      - kiwijamo 10y ago
        My experience with both OSX and Windows is that you just need to plug a printer in and it just works. Can't remember that ever happening with BSD/Linux in my experience. :( But it sounds like things have improved which is good to know.
        cyphar 10y ago
        In Arch Linux (and this is Arch Linux) all I ever had to do was install avahi (explained in the docs) and CUPS would find the printers automatically. On the other hand, I know of several cases where an OS X machine would cause unauthenticated printers on the same network (without any printing being done by the user) to start printing hundreds of pages of what looked like service discovery packets.
Animats 10y ago
Did this get fixed, 7 years later? Yesterday, we had a story about Microsoft's disk management service using lots of CPU time if the username contained "user". Microsoft's official reply was not to do that. I once found a bug in Coyote Systems' load balancers where, if the USER-AGENT ended with "m", all packets were dropped. They use regular expressions for various rules, and I suspect someone typed "\m" where they meant "\n". Vendor denied problem, even after I submitted a test case which failed on their own web site's load balancer. Many, many years ago, I found a bug in 4.3BSD which prevented TCP connections from establishing with certain other systems during odd numbered 4 hour periods. It took three days to find the bug in BSD's sequence number arithmetic. A combination of signed and unsigned casts was doing the wrong thing.
- raldu 10y ago
  Yes, it got fixed: https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619 https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619 The `file` utility failed to recognize PostScript files due to conflicting signature data at the magic file. The issue has been resolved long ago.
  - BrandonM 10y ago
    Yep, a month and a half after the bug was filed. Not too shabby for OSS!
  - tremon 10y ago
    If it was my software, I would not have accepted that as a proper fix though. For me, the real bug is to rely on the "file" command (a user diagnostic tool) to choose different code paths in a printing program.
    - hidroto 10y ago
      i doubt that this was a 'system "file $my_file"' as i believe there is a library that contains the file determination functionality in it.i can definitely see this a being an intended use of the file library.
carapace 10y ago
Stuff like this is why I find "Synthetic Biology" so fucking scary.
- Terr_ 10y ago
  Don't worry, the natural stuff is probably just as messy, or worse. If it helps, remember that grey-goo already took over the world, and you were born part of it.
lifeisstillgood 10y ago
And this is why we won't ever get AI. Humans seem to only manage to get to a certain level of complex before it all gets too much. There are supposedly people in Boeing who understand literally every part of a 747, the wiring and the funny holes in the windows. But there is probably no one who understands all parts of Windows 10. We're doomed to keep leaping like dolphins to reach a fish held too high by a sadistic Orlando world trainer
- dilemma 10y ago
  As I've said and been downvoted for before, there will never be Artificial Intelligence because a machine merely does what its program tells it. There will be plenty of Artificial Stupidity, however, as evidenced by this thread.
  - 21 10y ago
    And you do what the neurons in your brain make you do. Article from today - http://www.theatlantic.com/magazine/archive/2016/06/theres-no-such-thing-as-free-will/480750/ http://www.theatlantic.com/magazine/archive/2016/06/theres-n...
    - dilemma 10y ago
      Nope.
    - deleted 10y ago
      [deleted]
    - mark-r 10y ago
      You might be interested in what Scott Adams (the Dilbert cartoonist) has to say about the current presidential election: http://blog.dilbert.com/ http://blog.dilbert.com/
  - sspiff 10y ago
    Off topic and no arguments to support your case, sounds like downvote material to me.
kazinator 10y ago
But "Tue" is not at the fourth byte in the example, which has: %%CreationDate: (Tue Mar 3 19:47:42 2009) Something munged he the data. Perhaps some step which removes all characters after %%, except those in parentheses? %%(Tue Mar 3 ...) Now we're at the fourth byte. Another hypothesis is that the second incorrect match is kicking in. That is to say, some fields are added above %% CreationDate such that the Tue lands on position 79. The bug that was fixed in the magic database is this: -+4 string Tue Jan 22 14:32:44 MET 1991 Erlang JAM file - version 4.2 -+79 string Tue Jan 22 14:32:44 MET 1991 Erlang JAM file - version 4.2 ++4 string Tue\ Jan\ 22\ 14:32:44\ MET\ 1991 Erlang JAM file - version 4.2 ++79 string Tue\ Jan\ 22\ 14:32:44\ MET\ 1991 Erlang JAM file - version 4.2 (This is a patch of a patch: a fix to a an incorrect patch.) There are two matches for this special date which identifies JAM files: one at offset 4, but a possible other one at offset 79 which will cause the same problem. The real bug here is arguably the CUPS script. It should identify the file's type before munging it. And it shouldn't use a completely general, highly configurable utility whose data-driven file classification system is a moving target from release to release! This is a print script, so there is no reason to suspect that an input file is a Doom WAD file, or a Sun OS 4 MC68000 executable. The possibilities are quite limited, and can be handled with a bit of custom logic. Did Brother people write this? If so, I'm not surprised. Nobody should ever write code whose correct execution depends on the "file" utility classifying something. That is, not unless you write your own "magic" file and use only that file; then you're taking proper ownership of the classification logic, such that any bugs are likely to be your own. The fact that file got something wrong here is a red herring; the file utility is wrong once in a while, as anyone knows who has been using various versions of it regularly regularly for a few decades. Installations of the utility are only suitable for one-off interactive use. You got a mystery file from out of the blue, and need a clue as to what it is. Run file on it to get an often useful opinion. It is only usable in an advisory role, not in an authoritative role.
mark-r 10y ago
I love the modification that pipes the output of cat into sed; doesn't he realize that cat is redundant at that point?
- adzm 10y ago
  I'll admit to being a superfluous cat user. I just like typing cat.
nilstycho 10y ago
The weirdest case at my tenure as a neighborhood computer tech was a personal notebook computer that would not boot up at the customer's apartment. Of course we assumed user error, but further investigation revealed that if the computer were running as it approached the home, it would bluescreen about a block away. We guessed it was due to some kind of RF interference from a transmitter on the apartment building. Removing the WiFi module and the optical drive had no effect, so we further guessed it was interference within the motherboard or display. Rather than investigate further, we replaced the notebook at that point.
- jon_richards 10y ago
  My car radio goes from everything working fine to complete static on every station in like 10 feet as I drive into my local Safeway parking lot. I'm pretty sure they are jamming the signal, I just don't know why.
  - acranox 10y ago
    Some places with shopping carts have an "invisible fence" that locks up one of the wheels of the cart when you push the cart outside the property. These are usually marked with a yellow line on the ground. I presume they use some kind of RF field with an underground wire. Maybe that Safeway has some issues with theirs.
sampsonetics 10y ago
Reminds me of my favorite bug story from my own career. It was in my first year or two out of college. We were using a commercial C++ library for making HTTP calls out to another service. The initial symptom of the bug was that random requests would appear to come back with empty responses -- not just empty bodies, but the entire response was empty (not even any headers). After a fair amount of testing, I was somehow able to determine that it wasn't actually random. The empty response occurred whenever the size in bytes of the entire request (headers and body together) was exactly 10 modulo 256, for example 266 bytes or 1034 bytes or 4106 bytes. Weird, right? I went ahead and worked around the problem by putting in a heuristic when constructing the request: If the body size was such that the total request size would end up being close to 10 modulo 256, based on empirical knowledge of the typical size of our request headers, then add a dummy header to get out of the danger zone. That got us past the problem, but made me queasy. At the time, I had looked at the code and noticed an uninitialized variable in the response parsing function, but it didn't really hit me until much later. The code was something like this: void read_status_line(char *line) { char c; while (c != '\n') { c = read_next_byte(); *(line++) = c; } } Obviously this is wrong because it's checking c before reading it! But why the 10 modulo 256 condition? Of course, the ASCII code for newline is 10. Duh. So there must have been an earlier call stack where some other function had a local variable storing the length of the request, and this function's c variable landed smack-dab on the least-significant byte of that earlier value. Arrrrgh!
- thoman23 10y ago
  That sounds shockingly like a bug I remember one of our best developers finding when I worked at Homestead in the late 90's (and I remember being in awe then of his ability to deduce the pattern out of the seeming randomness).
gregschlom 10y ago
So what's the lesson here? What should we learn from that?
- kaizensoze 10y ago
  Make sure you escape spaces? Or: https://news.ycombinator.com/item?id=11718716 https://news.ycombinator.com/item?id=11718716
- anonymoose123 10y ago
  Lesson is: Not every post here should teach a lesson?
jpatokal 10y ago
Relevant: https://gyrovague.com/2015/07/29/crashes-only-on-wednesdays/ https://gyrovague.com/2015/07/29/crashes-only-on-wednesdays/
meeper16 10y ago
Yet another reason I don't let OpenOffice or any Linux UIs slow me down. It's all about the command line and always will be.
- Spivak 10y ago
  > So it's not a problem w/ openoffice.org, cups, or the brother printer drivers. It is a bug in the `file` utility, and documented at https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619 https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619. This bug had nothing to do with OO. This was just a cute manifestation of the actual bug.
gsylvie 10y ago
Here's a great collection of classic bug reports (including the never-printing-on-tuesdays): https://news.ycombinator.com/item?id=10309401 https://news.ycombinator.com/item?id=10309401
broodbucket 10y ago
Is it just me or does this get posted every month?
- jon-wood 10y ago
  I've never seen it before to my recollection, and I spend a possibly unhealthy amount of time checking up on the stories here, so my guess is no it doesn't.
  - broodbucket 10y ago
    It was a rhetorical question that was incorrect. Every month is a little bit too frequent, but not by much... https://hn.algolia.com/?query=openoffice%20tuesday https://hn.algolia.com/?query=openoffice%20tuesday Probably because it gets mentioned often in addition to be reposted often.
icambron 10y ago
The most interesting part of this story to me is actually that his wife noticed that the printer didn't work on Tuesdays. I'd have never, ever put that together, no matter how many times I saw it succeed or fail. I'd actually be more likely to figure it out by debugging the CUPS script than I would be observing my printer's behavior. Can a lot of people pick up on correlations like that? "Ever notice how it's always Tuesday when the printer won't work?"
- linuxfan2718 10y ago
  only someone who doesn't understand computers would notice it, programmers would say "that doesn't matter" :)
  - beambot 10y ago
    You'd figure it out eventually, especially if it was exceedingly annoying and/or your job depended on it. Example: what if your internet drops out for an hour every Sunday morning at 2am? You'd notice. (Mine does. Damn it Comcast!) If guy's wife relied on the printer similarly, it might be as acute as losing internet for you.
  - paublyrne 10y ago
    You wouldn't notice if you printed things on average once a week. But if you printed multiple times a day you'd soon notice the pattern, I suspect.
- Nacraile 10y ago
  I remember a time when I was a relatively computer-illiterate youngling and my favourite game was not particularly stable. I remember churning through many progressively more elaborate superstitions in search of some correlation I could exploit to prevent the dreaded crashes. Of course, I never succeeded. But the point should stand: people are built around finding and exploiting correlations to their benefit, and we're actually quite good at it. It is not terribly surprising to me that somebody quickly noticed that the annoying bad thing that is consistently happening today also happened consistently for a day precisely one week ago. When the pattern repeats again for a third time...
chris_wot 10y ago
Wait till you see where they found the print server! http://www.informationweek.com/server-54-where-are-you/d/d-id/1010340 http://www.informationweek.com/server-54-where-are-you/d/d-i...?
mark-r 10y ago
I have an anecdote, which isn't mine but comes from someone I know personally. This guy was working as a service tech, and was called out to diagnose a problem with a computer that had been recently moved. It worked most of the time, but any attempt to use the tape drive failed within a certain number of seconds (this was long ago, when tape drives were still a thing). Everything had worked fine before the move, and diagnostics didn't show anything out of place. Then he happened to look out the window - this was a military installation, and there was a radar dish rotating nearby. The failures occurred exactly when the radar dish was pointed their direction. It turns out the computer had been moved up one floor, which strengthened the interference just enough to cause the failure.
BrandonM 10y ago
Near the end of that post, the commenter suggested a fix that includes the most qualified Useless Use of Cat entry[0] that I've ever seen! cat | sed ... > $INPUT_TEMP [0] http://porkmail.org/era/unix/award.html#cat http://porkmail.org/era/unix/award.html#cat
DonHopkins 10y ago
My 6502 based FORTH systems would sometimes crash for no apparent reason after I tweaked some code and recompiled it. Whenever it got into crashy mode, it would crash in a completely different way, on a randomly different word. I'd put some debugging code in to diagnose the problem, and it would either disappear or move to another word! It was an infuriating Heizenbug! It turns out that the 6502 has a bug [1] that when you do an indirect JMP ($xxFF) through a two byte address that straddles a page boundary, it would wrap around to the first byte of the same page instead of incrementing the high half of the address to get the first byte of the next page. And of course the way that an indirect threaded FORTH system works is that each word has a "code field address" that the FORTH inner loop jumps through indirectly. So if a word's CFA just happened to straddle a page boundary, that word would crash! 6502 FORTH systems typically implemented the NEXT indirect threaded code inner interpreter efficiently by using self modifying code that patched an indirect JMP instruction on page zero whose operand was the W code field pointer. [2] JMP indirect is a relatively rare instruction, and it's quite rare that it's triggered by normal static code (since you can usually catch the problem during testing), but self modifying code has a 1/256 chance of triggering it! A later version of the 65C02 fixed that bug. It could manifest in either compiled FORTH code, or the assembly kernel. The FIG FORTH compiler [3] worked around it at compile time by allocating an extra byte before defining a new word if its CFA would straddle a page boundary. I defined an assembler macro for compiling words in the kernel that automatically padded in the special case, but the original 6502 FIG FORTH kernel had to be "checked and altered on any alteration" manually. [1] http://everything2.com/title/6502+indirect+JMP+bug http://everything2.com/title/6502+indirect+JMP+bug [2] http://forum.6502.org/viewtopic.php?t=1619 http://forum.6502.org/viewtopic.php?t=1619 "I'm sure some of you noticed my code will break if the bytes of the word addressed by IP straddle a page boundary, but luckily that's a direct parallel to the NMOS 6502's buggy JMP-Indirect instruction. An effective solution can be found in Fig-Forth 6502, available in the "Monitors, Assemblers, and Interpreters" section here. (The issue is dealt with at compile time; there is no run-time cost. The word CREATE pre-pads the dictionary with an unused byte in the rare cases when the word about to be CREATEd would otherwise end up with a code-field straddling a page boundary.)" [3] http://www.dwheeler.com/6502/FIG6502.ASM http://www.dwheeler.com/6502/FIG6502.ASM ; The following offset adjusts all code fields to avoid an ; address ending $XXFF. This must be checked and altered on ; any alteration , for the indirect jump at W-1 to operate ! ; .ORIGIN *+2 [...] .WORD DP ;) .WORD CAT ;| 6502 only. The code field .WORD CLIT ;| must not straddle page .BYTE $FD ;| boundaries .WORD EQUAL ;| .WORD ALLOT ;)
rcthompson 10y ago
I once found a bug in a weather applet that only occurred when the temperature exceeded 100 degress. The 3-digit temperature caused a cascade of formatting issues that rendered part of the applet unreadable. I believe the author used Celsius, and so would never have encountered this bug on their own.
t0mek 10y ago
During my studies I had a course called "Advanced Network Administration". I learnt about the OSPF routing protocol and its Quagga [1] implementation and I had to prepare a simple installation that consisted of 3 Linux machines. They were connected with cheap USB network adapters. After everything was configured I started the Quagga daemons and somehow they just didn't want to talk to each other. I've opened tcpdump to see what happens and the OSPF packets were exchanged properly. After a while the communication and routing was established. I thought that maybe the services just needed some time to discover the topology. I've restarted the system to see if it's able to get up automatically, but the problem reoccured - daemons just didn't see each other. Again, I launched tcpdump, tweaked some settings and now it worked - until it didn't a few minutes later. It take me a long time to find out that diagnostic tool I've used had actually changed the observed infrastructure (like in the quantum world). tcpdump enables the promiscuous mode on the network interfaces and apparently this was required for Quagga to run on the cheap USB ethernet adapters. I've used the ifconfig promisc and after that the OSPF worked stable. [1] http://www.nongnu.org/quagga/ http://www.nongnu.org/quagga/
mazda11 10y ago
My most memorial bugfix was when I was on a team ,temporary ,that did email encryption/decryption. They had one customer where some mails could not get decrypted, they had been figthing with this for one year, no one could figure out what was going on. I told them to do a dump for a week with the good and bad emails. After one week I was given the dump of files, looked at the count of bad vs good, did some math in my head and said: "Hmm, it appears that about 1/256 mails is bad.That could indicate that the problem is releated to a specific byte having a specific value in the random 256 bit AES key. If there is a specific value giving problems it is probaly 0x00 and the position I would guess being at the last or first byte." I did a check by decoding all SMIME mails to readable text with openssl- sure, all bad emails had 0x00 as the least signicant byte. Then i looked at asn1 spec and discovered it was a bit vague about if the least significant byte had to be there if it was 0x00. I inserted a line into the custom written IBM 4764 CCA driver written in c called by JNI. Then all emails decrypted. The team dropped their jaws- they had been figthing with it for 1 year and I diagnosed the bug only by looking at the good/bad ratio :) I might remember some details wrong- but the big picture is correct :)
- pwang 10y ago
  Respect. I think the singular power of an experienced programmer is being able to reason about high-level structure, while being able to deep-dive into any lower level detail, anywhere in the overall system, and therefore be able to carve out large swaths of problem space just by /thinking/. That's much faster than typing-and-executing-and-reading-logs.
annebass 10y ago
Fascinating bug :)
sklogic 10y ago
No, it is a cups bug indeed. File was never guaranteed to be precise in the first place, it is not a good idea to rely on it.
gchadwick 10y ago
Surely the real bug is the reliance on the 'file' utility in the first place? It attempts to quickly identify a file that could be literaly anything so it's not surprising (and indeed should be expected) that sometimes it gets it wrong. I don't know the details of the CUPS script but presumably it can only deal with a small number of different file types. Implementing it's own detection to positively identify PS vs whatever other formats it deals with vs everything else would be far more robust.
pif 10y ago
CERN: LEP data confirm train time tables http://cds.cern.ch/record/1726241 http://cds.cern.ch/record/1726241 CERN: Is the moon full? Just ask the LHC operators http://www.quantumdiaries.org/2012/06/07/is-the-moon-full-just-ask-the-lhc-operators/ http://www.quantumdiaries.org/2012/06/07/is-the-moon-full-ju...
kinai 10y ago
I once had the case with a desktop system that when you sat down and started typing it often hardware reseted. Turned out Dell left some metal piece in the case which was hanging between the case and the motherboard (in those few millimeter) and with some stronger desk vibration caused a shortcut.
GigabyteCoin 10y ago
"tue" means "kill" in french... I wonder if a french programmer somewhere had something to do with this?
krylon 10y ago
One of our users complained that she could no longer print PDF documents. Everything else, Word, Excel, graphics, worked fine, but when she printed a PDF ... the printer did emit a page that - layout-wise - pretty much looked like it was supposed to, except all the text was complete and utter nonsense. Or was it? I took one of the pages back to my desk, and later in the day I had an idle moment, and my eyes wandered across the page. The funny thing is, if I had not known what text was supposed to be on the page, I would not have noticed, but the text was not random at all. Instead, all the letters had been shifted by one place in the alphabet (i.e. "ABCD" became "BCDE"). I went back to the user and told her to check the little box that said "Print text as graphics" in the PDF viewers printing dialog, and voila - the page came out of the printer looking the way it was supposed to. Printing that way did take longer than usual (a lot longer), but at least the results were correct. To this day, I have no clue where the problem came from, and unfortunately, I did not have the time to investigate the issue further. I had never seen such a problem before or after. In a way it's part of what I like about my job: These weird problems that seem to come out of nowhere for no apparent reason, and that just as often disappear back into the void before I really understand what is going on. It can be oh-so frustrating at times, but I cannot deny that I am totally into weird things, so some part of me really enjoyed the whole experience.

419 points by hardmath123 10y ago

The TL;DR is that the "file" utility was miscategorising files that had "Tue" in the first few bytes of a file as an Erlang JAM file, with knock on effects for PostScript files generates with a header comment with Tue in the date.

kaizensoze 10y ago
The circumstances under which I discovered/reported the bug were totally coincidental too. I noticed a friend use the file command and thought to myself "Hmm I've never actually used that command before. Let me try it out." Ran it on a TODO list text file I had lying around, scratched my head over the "Erlang JAM file" output, and went from there.
wrs 10y ago
Because it was trying to identify that type of file by looking for a particular full date string (bizarre in itself) and the wrong syntax was used to specify the string (unescaped spaces).

mpeg 10y ago

The title reminds me of "the 500 mile email" http://www.ibiblio.org/harris/500milemail.html http://www.ibiblio.org/harris/500milemail.html

K-Wall 10y ago
This is one story I always enjoy when it is brought up.
- ChristianBundy 10y ago
  Me too. Are there any others you could recommend?
  - kirrent 10y ago
    Real programmers don't use PASCAL never fails to crack me up. A bit closer to the grandparent comment is the famous story of Mel. http://web.mit.edu/humor/Computers/real.programmers http://web.mit.edu/humor/Computers/real.programmers https://www.cs.utah.edu/~elb/folklore/mel.html https://www.cs.utah.edu/~elb/folklore/mel.html
    - nickpsecurity 10y ago
      Real programmers was the funniest shit I've read in a while. Even had jokes embedded in the references like the Lucasfilms one. I needed that laugh. :)
  - dandelany 10y ago
    Some of my favorite hacker folklore: Always Mount a Scratch Monkey http://edp.org/monkey.htm http://edp.org/monkey.htm The Magic Switch https://www.cs.utah.edu/~elb/folklore/magic.html https://www.cs.utah.edu/~elb/folklore/magic.html Quake3's Fast InvSqrt() https://www.beyond3d.com/content/articles/8/ https://www.beyond3d.com/content/articles/8/ The Battle Chess Duck http://blog.codinghorror.com/new-programming-jargon/ http://blog.codinghorror.com/new-programming-jargon/ (#5) and of course, The Story of Mel, a Real Programmer https://www.cs.utah.edu/~elb/folklore/mel.html https://www.cs.utah.edu/~elb/folklore/mel.html edit to add: Ford and the $10,000 chalk mark (Ctrl+F Ford) http://www.smithsonianmag.com/history/charles-proteus-steinmetz-the-wizard-of-schenectady-51912022/ http://www.smithsonianmag.com/history/charles-proteus-steinm...
    - frank_jaeger 10y ago
      Big second for Quake's Fast InvSqrt, that is a really cool story.
    - Splines 10y ago
n72 10y ago
Great story. Also, never knew about units.

Adaptive 10y ago

I've noticed that printing is still one of the poorest UX aspects of *nix/OSS and regularly seems to suffer from errors so egregious that they can only be attributed to OSS devs not dogfooding these features. I'm assuming they just don't print much (I mean, we ALL print less than 20 years ago, but all the more reason to test these features which, when you need them to work you REALLY need them to work).

ultramancool 10y ago
Perhaps you're thinking back to the days of manually configuring CUPS? Any recent printer I've used has just been plug it in and hit print. A better experience than Windows in terms of included drivers and bonjour support too.
- dbcurtis 10y ago
  No, you've simply been lucky.
  - chrisfosterelli 10y ago
    I can say my experience matches the above posters as well. Printing in Ubuntu works better than OSX and Windows for the 4 different printers I use regularly.
    - kiwijamo 10y ago
      My experience with both OSX and Windows is that you just need to plug a printer in and it just works. Can't remember that ever happening with BSD/Linux in my experience. :( But it sounds like things have improved which is good to know.
      - cyphar 10y ago
        In Arch Linux (and this is Arch Linux) all I ever had to do was install avahi (explained in the docs) and CUPS would find the printers automatically. On the other hand, I know of several cases where an OS X machine would cause unauthenticated printers on the same network (without any printing being done by the user) to start printing hundreds of pages of what looked like service discovery packets.

Animats 10y ago

Did this get fixed, 7 years later? Yesterday, we had a story about Microsoft's disk management service using lots of CPU time if the username contained "user". Microsoft's official reply was not to do that. I once found a bug in Coyote Systems' load balancers where, if the USER-AGENT ended with "m", all packets were dropped. They use regular expressions for various rules, and I suspect someone typed "\m" where they meant "\n". Vendor denied problem, even after I submitted a test case which failed on their own web site's load balancer. Many, many years ago, I found a bug in 4.3BSD which prevented TCP connections from establishing with certain other systems during odd numbered 4 hour periods. It took three days to find the bug in BSD's sequence number arithmetic. A combination of signed and unsigned casts was doing the wrong thing.

raldu 10y ago
Yes, it got fixed: https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619 https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619 The `file` utility failed to recognize PostScript files due to conflicting signature data at the magic file. The issue has been resolved long ago.
- BrandonM 10y ago
  Yep, a month and a half after the bug was filed. Not too shabby for OSS!
- tremon 10y ago
  If it was my software, I would not have accepted that as a proper fix though. For me, the real bug is to rely on the "file" command (a user diagnostic tool) to choose different code paths in a printing program.
  - hidroto 10y ago
    i doubt that this was a 'system "file $my_file"' as i believe there is a library that contains the file determination functionality in it.i can definitely see this a being an intended use of the file library.

carapace 10y ago

Stuff like this is why I find "Synthetic Biology" so fucking scary.

Terr_ 10y ago
Don't worry, the natural stuff is probably just as messy, or worse. If it helps, remember that grey-goo already took over the world, and you were born part of it.

lifeisstillgood 10y ago

And this is why we won't ever get AI. Humans seem to only manage to get to a certain level of complex before it all gets too much. There are supposedly people in Boeing who understand literally every part of a 747, the wiring and the funny holes in the windows. But there is probably no one who understands all parts of Windows 10. We're doomed to keep leaping like dolphins to reach a fish held too high by a sadistic Orlando world trainer

dilemma 10y ago
As I've said and been downvoted for before, there will never be Artificial Intelligence because a machine merely does what its program tells it. There will be plenty of Artificial Stupidity, however, as evidenced by this thread.
- 21 10y ago
  And you do what the neurons in your brain make you do. Article from today - http://www.theatlantic.com/magazine/archive/2016/06/theres-no-such-thing-as-free-will/480750/ http://www.theatlantic.com/magazine/archive/2016/06/theres-n...
  - dilemma 10y ago
    Nope.
  - deleted 10y ago
    [deleted]
  - mark-r 10y ago
    You might be interested in what Scott Adams (the Dilbert cartoonist) has to say about the current presidential election: http://blog.dilbert.com/ http://blog.dilbert.com/
- sspiff 10y ago
  Off topic and no arguments to support your case, sounds like downvote material to me.

kazinator 10y ago

But "Tue" is not at the fourth byte in the example, which has: %%CreationDate: (Tue Mar 3 19:47:42 2009) Something munged he the data. Perhaps some step which removes all characters after %%, except those in parentheses? %%(Tue Mar 3 ...) Now we're at the fourth byte. Another hypothesis is that the second incorrect match is kicking in. That is to say, some fields are added above %% CreationDate such that the Tue lands on position 79. The bug that was fixed in the magic database is this: -+4 string Tue Jan 22 14:32:44 MET 1991 Erlang JAM file - version 4.2 -+79 string Tue Jan 22 14:32:44 MET 1991 Erlang JAM file - version 4.2 ++4 string Tue\ Jan\ 22\ 14:32:44\ MET\ 1991 Erlang JAM file - version 4.2 ++79 string Tue\ Jan\ 22\ 14:32:44\ MET\ 1991 Erlang JAM file - version 4.2 (This is a patch of a patch: a fix to a an incorrect patch.) There are two matches for this special date which identifies JAM files: one at offset 4, but a possible other one at offset 79 which will cause the same problem. The real bug here is arguably the CUPS script. It should identify the file's type before munging it. And it shouldn't use a completely general, highly configurable utility whose data-driven file classification system is a moving target from release to release! This is a print script, so there is no reason to suspect that an input file is a Doom WAD file, or a Sun OS 4 MC68000 executable. The possibilities are quite limited, and can be handled with a bit of custom logic. Did Brother people write this? If so, I'm not surprised. Nobody should ever write code whose correct execution depends on the "file" utility classifying something. That is, not unless you write your own "magic" file and use only that file; then you're taking proper ownership of the classification logic, such that any bugs are likely to be your own. The fact that file got something wrong here is a red herring; the file utility is wrong once in a while, as anyone knows who has been using various versions of it regularly regularly for a few decades. Installations of the utility are only suitable for one-off interactive use. You got a mystery file from out of the blue, and need a clue as to what it is. Run file on it to get an often useful opinion. It is only usable in an advisory role, not in an authoritative role.

mark-r 10y ago

I love the modification that pipes the output of cat into sed; doesn't he realize that cat is redundant at that point?

adzm 10y ago
I'll admit to being a superfluous cat user. I just like typing cat.

nilstycho 10y ago

The weirdest case at my tenure as a neighborhood computer tech was a personal notebook computer that would not boot up at the customer's apartment. Of course we assumed user error, but further investigation revealed that if the computer were running as it approached the home, it would bluescreen about a block away. We guessed it was due to some kind of RF interference from a transmitter on the apartment building. Removing the WiFi module and the optical drive had no effect, so we further guessed it was interference within the motherboard or display. Rather than investigate further, we replaced the notebook at that point.

jon_richards 10y ago
My car radio goes from everything working fine to complete static on every station in like 10 feet as I drive into my local Safeway parking lot. I'm pretty sure they are jamming the signal, I just don't know why.
- acranox 10y ago
  Some places with shopping carts have an "invisible fence" that locks up one of the wheels of the cart when you push the cart outside the property. These are usually marked with a yellow line on the ground. I presume they use some kind of RF field with an underground wire. Maybe that Safeway has some issues with theirs.

sampsonetics 10y ago

Reminds me of my favorite bug story from my own career. It was in my first year or two out of college. We were using a commercial C++ library for making HTTP calls out to another service. The initial symptom of the bug was that random requests would appear to come back with empty responses -- not just empty bodies, but the entire response was empty (not even any headers). After a fair amount of testing, I was somehow able to determine that it wasn't actually random. The empty response occurred whenever the size in bytes of the entire request (headers and body together) was exactly 10 modulo 256, for example 266 bytes or 1034 bytes or 4106 bytes. Weird, right? I went ahead and worked around the problem by putting in a heuristic when constructing the request: If the body size was such that the total request size would end up being close to 10 modulo 256, based on empirical knowledge of the typical size of our request headers, then add a dummy header to get out of the danger zone. That got us past the problem, but made me queasy. At the time, I had looked at the code and noticed an uninitialized variable in the response parsing function, but it didn't really hit me until much later. The code was something like this: void read_status_line(char *line) { char c; while (c != '\n') { c = read_next_byte(); *(line++) = c; } } Obviously this is wrong because it's checking c before reading it! But why the 10 modulo 256 condition? Of course, the ASCII code for newline is 10. Duh. So there must have been an earlier call stack where some other function had a local variable storing the length of the request, and this function's c variable landed smack-dab on the least-significant byte of that earlier value. Arrrrgh!

thoman23 10y ago
That sounds shockingly like a bug I remember one of our best developers finding when I worked at Homestead in the late 90's (and I remember being in awe then of his ability to deduce the pattern out of the seeming randomness).

gregschlom 10y ago

So what's the lesson here? What should we learn from that?

kaizensoze 10y ago
Make sure you escape spaces? Or: https://news.ycombinator.com/item?id=11718716 https://news.ycombinator.com/item?id=11718716
anonymoose123 10y ago
Lesson is: Not every post here should teach a lesson?

jpatokal 10y ago

Relevant: https://gyrovague.com/2015/07/29/crashes-only-on-wednesdays/ https://gyrovague.com/2015/07/29/crashes-only-on-wednesdays/

meeper16 10y ago

Yet another reason I don't let OpenOffice or any Linux UIs slow me down. It's all about the command line and always will be.

Spivak 10y ago
> So it's not a problem w/ openoffice.org, cups, or the brother printer drivers. It is a bug in the `file` utility, and documented at https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619 https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619. This bug had nothing to do with OO. This was just a cute manifestation of the actual bug.

gsylvie 10y ago

Here's a great collection of classic bug reports (including the never-printing-on-tuesdays): https://news.ycombinator.com/item?id=10309401 https://news.ycombinator.com/item?id=10309401

broodbucket 10y ago

Is it just me or does this get posted every month?

jon-wood 10y ago
I've never seen it before to my recollection, and I spend a possibly unhealthy amount of time checking up on the stories here, so my guess is no it doesn't.
- broodbucket 10y ago
  It was a rhetorical question that was incorrect. Every month is a little bit too frequent, but not by much... https://hn.algolia.com/?query=openoffice%20tuesday https://hn.algolia.com/?query=openoffice%20tuesday Probably because it gets mentioned often in addition to be reposted often.

icambron 10y ago

The most interesting part of this story to me is actually that his wife noticed that the printer didn't work on Tuesdays. I'd have never, ever put that together, no matter how many times I saw it succeed or fail. I'd actually be more likely to figure it out by debugging the CUPS script than I would be observing my printer's behavior. Can a lot of people pick up on correlations like that? "Ever notice how it's always Tuesday when the printer won't work?"

linuxfan2718 10y ago
only someone who doesn't understand computers would notice it, programmers would say "that doesn't matter" :)
- beambot 10y ago
  You'd figure it out eventually, especially if it was exceedingly annoying and/or your job depended on it. Example: what if your internet drops out for an hour every Sunday morning at 2am? You'd notice. (Mine does. Damn it Comcast!) If guy's wife relied on the printer similarly, it might be as acute as losing internet for you.
- paublyrne 10y ago
  You wouldn't notice if you printed things on average once a week. But if you printed multiple times a day you'd soon notice the pattern, I suspect.
Nacraile 10y ago
I remember a time when I was a relatively computer-illiterate youngling and my favourite game was not particularly stable. I remember churning through many progressively more elaborate superstitions in search of some correlation I could exploit to prevent the dreaded crashes. Of course, I never succeeded. But the point should stand: people are built around finding and exploiting correlations to their benefit, and we're actually quite good at it. It is not terribly surprising to me that somebody quickly noticed that the annoying bad thing that is consistently happening today also happened consistently for a day precisely one week ago. When the pattern repeats again for a third time...

chris_wot 10y ago

Wait till you see where they found the print server! http://www.informationweek.com/server-54-where-are-you/d/d-id/1010340 http://www.informationweek.com/server-54-where-are-you/d/d-i...?

mark-r 10y ago

I have an anecdote, which isn't mine but comes from someone I know personally. This guy was working as a service tech, and was called out to diagnose a problem with a computer that had been recently moved. It worked most of the time, but any attempt to use the tape drive failed within a certain number of seconds (this was long ago, when tape drives were still a thing). Everything had worked fine before the move, and diagnostics didn't show anything out of place. Then he happened to look out the window - this was a military installation, and there was a radar dish rotating nearby. The failures occurred exactly when the radar dish was pointed their direction. It turns out the computer had been moved up one floor, which strengthened the interference just enough to cause the failure.

BrandonM 10y ago

Near the end of that post, the commenter suggested a fix that includes the most qualified Useless Use of Cat entry[0] that I've ever seen! cat | sed ... > $INPUT_TEMP [0] http://porkmail.org/era/unix/award.html#cat http://porkmail.org/era/unix/award.html#cat

DonHopkins 10y ago

My 6502 based FORTH systems would sometimes crash for no apparent reason after I tweaked some code and recompiled it. Whenever it got into crashy mode, it would crash in a completely different way, on a randomly different word. I'd put some debugging code in to diagnose the problem, and it would either disappear or move to another word! It was an infuriating Heizenbug! It turns out that the 6502 has a bug [1] that when you do an indirect JMP ($xxFF) through a two byte address that straddles a page boundary, it would wrap around to the first byte of the same page instead of incrementing the high half of the address to get the first byte of the next page. And of course the way that an indirect threaded FORTH system works is that each word has a "code field address" that the FORTH inner loop jumps through indirectly. So if a word's CFA just happened to straddle a page boundary, that word would crash! 6502 FORTH systems typically implemented the NEXT indirect threaded code inner interpreter efficiently by using self modifying code that patched an indirect JMP instruction on page zero whose operand was the W code field pointer. [2] JMP indirect is a relatively rare instruction, and it's quite rare that it's triggered by normal static code (since you can usually catch the problem during testing), but self modifying code has a 1/256 chance of triggering it! A later version of the 65C02 fixed that bug. It could manifest in either compiled FORTH code, or the assembly kernel. The FIG FORTH compiler [3] worked around it at compile time by allocating an extra byte before defining a new word if its CFA would straddle a page boundary. I defined an assembler macro for compiling words in the kernel that automatically padded in the special case, but the original 6502 FIG FORTH kernel had to be "checked and altered on any alteration" manually. [1] http://everything2.com/title/6502+indirect+JMP+bug http://everything2.com/title/6502+indirect+JMP+bug [2] http://forum.6502.org/viewtopic.php?t=1619 http://forum.6502.org/viewtopic.php?t=1619 "I'm sure some of you noticed my code will break if the bytes of the word addressed by IP straddle a page boundary, but luckily that's a direct parallel to the NMOS 6502's buggy JMP-Indirect instruction. An effective solution can be found in Fig-Forth 6502, available in the "Monitors, Assemblers, and Interpreters" section here. (The issue is dealt with at compile time; there is no run-time cost. The word CREATE pre-pads the dictionary with an unused byte in the rare cases when the word about to be CREATEd would otherwise end up with a code-field straddling a page boundary.)" [3] http://www.dwheeler.com/6502/FIG6502.ASM http://www.dwheeler.com/6502/FIG6502.ASM ; The following offset adjusts all code fields to avoid an ; address ending $XXFF. This must be checked and altered on ; any alteration , for the indirect jump at W-1 to operate ! ; .ORIGIN *+2 [...] .WORD DP ;) .WORD CAT ;| 6502 only. The code field .WORD CLIT ;| must not straddle page .BYTE $FD ;| boundaries .WORD EQUAL ;| .WORD ALLOT ;)

rcthompson 10y ago

I once found a bug in a weather applet that only occurred when the temperature exceeded 100 degress. The 3-digit temperature caused a cascade of formatting issues that rendered part of the applet unreadable. I believe the author used Celsius, and so would never have encountered this bug on their own.

t0mek 10y ago

During my studies I had a course called "Advanced Network Administration". I learnt about the OSPF routing protocol and its Quagga [1] implementation and I had to prepare a simple installation that consisted of 3 Linux machines. They were connected with cheap USB network adapters. After everything was configured I started the Quagga daemons and somehow they just didn't want to talk to each other. I've opened tcpdump to see what happens and the OSPF packets were exchanged properly. After a while the communication and routing was established. I thought that maybe the services just needed some time to discover the topology. I've restarted the system to see if it's able to get up automatically, but the problem reoccured - daemons just didn't see each other. Again, I launched tcpdump, tweaked some settings and now it worked - until it didn't a few minutes later. It take me a long time to find out that diagnostic tool I've used had actually changed the observed infrastructure (like in the quantum world). tcpdump enables the promiscuous mode on the network interfaces and apparently this was required for Quagga to run on the cheap USB ethernet adapters. I've used the ifconfig promisc and after that the OSPF worked stable. [1] http://www.nongnu.org/quagga/ http://www.nongnu.org/quagga/

mazda11 10y ago

My most memorial bugfix was when I was on a team ,temporary ,that did email encryption/decryption. They had one customer where some mails could not get decrypted, they had been figthing with this for one year, no one could figure out what was going on. I told them to do a dump for a week with the good and bad emails. After one week I was given the dump of files, looked at the count of bad vs good, did some math in my head and said: "Hmm, it appears that about 1/256 mails is bad.That could indicate that the problem is releated to a specific byte having a specific value in the random 256 bit AES key. If there is a specific value giving problems it is probaly 0x00 and the position I would guess being at the last or first byte." I did a check by decoding all SMIME mails to readable text with openssl- sure, all bad emails had 0x00 as the least signicant byte. Then i looked at asn1 spec and discovered it was a bit vague about if the least significant byte had to be there if it was 0x00. I inserted a line into the custom written IBM 4764 CCA driver written in c called by JNI. Then all emails decrypted. The team dropped their jaws- they had been figthing with it for 1 year and I diagnosed the bug only by looking at the good/bad ratio :) I might remember some details wrong- but the big picture is correct :)

pwang 10y ago
Respect. I think the singular power of an experienced programmer is being able to reason about high-level structure, while being able to deep-dive into any lower level detail, anywhere in the overall system, and therefore be able to carve out large swaths of problem space just by /thinking/. That's much faster than typing-and-executing-and-reading-logs.

annebass 10y ago

Fascinating bug :)

sklogic 10y ago

No, it is a cups bug indeed. File was never guaranteed to be precise in the first place, it is not a good idea to rely on it.

gchadwick 10y ago

Surely the real bug is the reliance on the 'file' utility in the first place? It attempts to quickly identify a file that could be literaly anything so it's not surprising (and indeed should be expected) that sometimes it gets it wrong. I don't know the details of the CUPS script but presumably it can only deal with a small number of different file types. Implementing it's own detection to positively identify PS vs whatever other formats it deals with vs everything else would be far more robust.

pif 10y ago

CERN: LEP data confirm train time tables http://cds.cern.ch/record/1726241 http://cds.cern.ch/record/1726241 CERN: Is the moon full? Just ask the LHC operators http://www.quantumdiaries.org/2012/06/07/is-the-moon-full-just-ask-the-lhc-operators/ http://www.quantumdiaries.org/2012/06/07/is-the-moon-full-ju...

kinai 10y ago

I once had the case with a desktop system that when you sat down and started typing it often hardware reseted. Turned out Dell left some metal piece in the case which was hanging between the case and the motherboard (in those few millimeter) and with some stronger desk vibration caused a shortcut.

GigabyteCoin 10y ago

"tue" means "kill" in french... I wonder if a french programmer somewhere had something to do with this?

krylon 10y ago

One of our users complained that she could no longer print PDF documents. Everything else, Word, Excel, graphics, worked fine, but when she printed a PDF ... the printer did emit a page that - layout-wise - pretty much looked like it was supposed to, except all the text was complete and utter nonsense. Or was it? I took one of the pages back to my desk, and later in the day I had an idle moment, and my eyes wandered across the page. The funny thing is, if I had not known what text was supposed to be on the page, I would not have noticed, but the text was not random at all. Instead, all the letters had been shifted by one place in the alphabet (i.e. "ABCD" became "BCDE"). I went back to the user and told her to check the little box that said "Print text as graphics" in the PDF viewers printing dialog, and voila - the page came out of the printer looking the way it was supposed to. Printing that way did take longer than usual (a lot longer), but at least the results were correct. To this day, I have no clue where the problem came from, and unfortunately, I did not have the time to investigate the issue further. I had never seen such a problem before or after. In a way it's part of what I like about my job: These weird problems that seem to come out of nowhere for no apparent reason, and that just as often disappear back into the void before I really understand what is going on. It can be oh-so frustrating at times, but I cannot deny that I am totally into weird things, so some part of me really enjoyed the whole experience.