“My wife has complained that OpenOffice will never print on Tuesdays” (2009)(bugs.launchpad.net)
bugs.launchpad.net
“My wife has complained that OpenOffice will never print on Tuesdays” (2009)
https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28
160 comments
My favorite was a story from the 1980s of a program which would crash depending on the phase of the Moon!
Turned out to be because it was generating a date by calling a general purpose astronomical routine, then parsing the date out of that. The astronomical routine among other things included the phase of the moon, and during some phases you would overflow the buffer that was passed in.
Another classic was a tech support call from the 1990s where the person's computer rebooted every time they flushed the toilet. Turns out that the person was at the end of the electrical line..and on a septic system. Flush the toilet, the septic system came online, causing a power dip, and that was enough to reboot the computer. A UPS fixed that.
Turned out to be because it was generating a date by calling a general purpose astronomical routine, then parsing the date out of that. The astronomical routine among other things included the phase of the moon, and during some phases you would overflow the buffer that was passed in.
Another classic was a tech support call from the 1990s where the person's computer rebooted every time they flushed the toilet. Turns out that the person was at the end of the electrical line..and on a septic system. Flush the toilet, the septic system came online, causing a power dip, and that was enough to reboot the computer. A UPS fixed that.
My favorite was the server that couldn't send email further than 500 miles away.
http://www.ibiblio.org/harris/500milemail.html
http://www.ibiblio.org/harris/500milemail.html
That story was what got me using GNU Units. Which turns out to be a surprisingly powerful, and very much units aware, calculator.
Want to convert acreage into MWh of annual solar electric potential, or figure out the oil equivalent energy in a nation's poop? Units can do that. And much more.
Want to convert acreage into MWh of annual solar electric potential, or figure out the oil equivalent energy in a nation's poop? Units can do that. And much more.
Didn't someone prove this to be nonsense?
The author notes at the outset it's embellished to be entertaining, but nothing in the actual big seemed outlandish. The only thing that struck me as unlikely was that someone would actually work out and notice the radius. But I also know people like that, so I'd give the story the benefit of the doubt.
The user in the story is the chairman of statistics dept.
Don't ruin our industry's good anecdotes with reality!!!
> My favorite was a story from the 1980s of a program which would crash depending on the phase of the Moon!
Do you have a name for this program? It sounds a lot like an urban legend - when would you ever find it easier to parse a date out of an astronomical program than to use actual date handing capabilities from the system or a library?
Do you have a name for this program? It sounds a lot like an urban legend - when would you ever find it easier to parse a date out of an astronomical program than to use actual date handing capabilities from the system or a library?
Here is a reference to a program that crashed based on the phase of the moon for slightly different reasons: http://www.catb.org/jargon/html/P/phase-of-the-moon.html
The one that I described I first remember hearing about in undergrad. I heard it from an astronomy student. I guess that makes it an urban legend, but a highly believable one. In my experience inexperienced programmers are very good at unexpectedly repurposing whatever they happen to know for new purposes. And in an astronomy department it is easy to find inexperienced programmers with astronomical routines at hand.
The one that I described I first remember hearing about in undergrad. I heard it from an astronomy student. I guess that makes it an urban legend, but a highly believable one. In my experience inexperienced programmers are very good at unexpectedly repurposing whatever they happen to know for new purposes. And in an astronomy department it is easy to find inexperienced programmers with astronomical routines at hand.
More that it was including the phase of the moon in the output and it would crash of the output ended up being too long.
I've never heard of this either but early programmers did creative things to work around limitations. It might not be as complicated as we imagine. The first "computer", the Antikythera, was designed for this very purpose.
[deleted]
A BeOS bug story similar to the phase of the Moon:
Two [BeOS] test engineers were in a crunch. The floppy drive they were currently
testing would work all day while they ran a variety of stress tests, but the
exact same tests would run for only eight hours at night.
After a few days of double-checking the hardware, the testing procedure, and the
recording devices, they decided to stay the night and watch what happened. For
eight hours they stared at the floppy drive and drank espresso. The long dark
night slowly turned into day and the sun shone in the window. The angled sunlight
triggered the write-protection mechanism, which caused a write failure. A new
casing was designed and the problem was solved.
I heard a story about a terminal in a public terminal room that a user was able to consistently log in to if they were sitting down in a chair in front if the terminal, but never if they were standing up.
They thought it might be static electricity, or some mechanical problem, or "problem exists between keyboard and chair", but finally they noticed something else was amiss...
It turns out some joker had re-arranged the 1234567890 keys to be 0123456789, so when the user was standing up, they looked down at the keyboard and typed their password (which contained a digit, of course) by looking at the keys. But when they were sitting down, they touch typed without looking at the keys, and got their password correct!
They thought it might be static electricity, or some mechanical problem, or "problem exists between keyboard and chair", but finally they noticed something else was amiss...
It turns out some joker had re-arranged the 1234567890 keys to be 0123456789, so when the user was standing up, they looked down at the keyboard and typed their password (which contained a digit, of course) by looking at the keys. But when they were sitting down, they touch typed without looking at the keys, and got their password correct!
I have a slightly more boring anecdote. We were making a 2 Mbit/s multiplexer (E1 to POTS and ISDN lines thing) and ISDN lines worked fine during the day in the test lab but they were always dead the next morning. The unit was otherwise running fine the following day but ISDN was stuck. We never got this to repeat at other times. If you booted it at midnight and came to work at 6AM, it was stuck. But it would run OK from 6AM to midnight so it wasn't any buffer overflow or such.
So, eventually, just decided to stay at lab for the night. At 5AM the air conditioning came on (it was shut for the night). The ISDN circuit got stuck.
It was electromagnetic interference from the massive AC unit fan which was not too far above our lab table. Improving the grounding of the ISDN chip helped.
So, eventually, just decided to stay at lab for the night. At 5AM the air conditioning came on (it was shut for the night). The ISDN circuit got stuck.
It was electromagnetic interference from the massive AC unit fan which was not too far above our lab table. Improving the grounding of the ISDN chip helped.
Yes, it got fixed: 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.
The `file` utility failed to recognize PostScript files due to conflicting signature data at the magic file. The issue has been resolved long 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.
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.
Yep, a month and a half after the bug was filed. Not too shabby for OSS!
Used to own a PCMCIA wi-fi adapter that predated finalization of the 802.11b standard and which could reliably be induced to blue screen if I caused an HTTP request to be sent over the interface containing a lowercase x.
This reminds me of that old joke: "How many Microsoft engineers does it take to replace a broken light-bulb?"
The answer is "None - Microsoft simply change the standard to darkness"
------------------------------------------
Also reminds me of the fact that there are no bugs in Microsoft software - only "Features".
The answer is "None - Microsoft simply change the standard to darkness"
------------------------------------------
Also reminds me of the fact that there are no bugs in Microsoft software - only "Features".
I think these are re-purposings of jokes about Unix, which is justly infamous for having lists of bugs that would've been easier to fix than to reproduce, for canonizing its bugs as standards of behavior to work around, and for having startlingly lazy components to begin with (especially the POSIX string-handling libraries -- strcmp() can be written in minutes).
See _The UNIX-HATERS Handbook_ for more. https://en.wikipedia.org/wiki/The_Unix-Haters_Handbook
See _The UNIX-HATERS Handbook_ for more. https://en.wikipedia.org/wiki/The_Unix-Haters_Handbook
I have an Acer laptop (2008 model) which doesn't boot when pressing the power button (since a few years).
Interestingly after pressing the power button you've to close the lid and then gentally press the closed lid once/twice (top center of lid where back of the camera is positioned) and then it immediately boots :)
The power button is on the opposite side (at the bottom left of the lid) so it can't be getting a pressure when lid is pressed after closed.
The power button is on the opposite side (at the bottom left of the lid) so it can't be getting a pressure when lid is pressed after closed.
You might want to fix that "gentally" because it is easy to misread, and the instruction becomes definitely not office-safe.
These kinds of issues fascinate me, aside from how frustrating they can be. They highlight the immense complexity that underlies what I, a lowly web developer, do on a daily basis, and what effect some decisions can have. It definitely motivates me to be a lot more careful and thorough about the code I write, and that's probably a good thing considering that I'm a painfully self-aware javascript coder who eschews, among other things, writing tests for my code and who thoughtlessly uses modules that solve whatever problem I'm facing.
I could go on to write a love-letter to how a number of HN posts make me want to be a better programmer, but I'll keep it a simple as possible.
Being here, even now, and even though I do sort of feel like one of the 'older crew' suspiciously eyeing what appears to be an influx of 'others', to put it vaguely, ultimately what I love most about this place is reading about the 'old-timers' and how they worked, the 'oldest code that is still in use', the argument for and against LISPs, the problems of the JS/Node ecosystem (bit sick of that), the crazy shit some programmer created, and so on.
I'm pretty much addicted to HN, while I managed to cut out Facebook and Reddit. What keeps me here is the intense desire to be a hacker, and how, even now, HN fuels it. To not just make websites or work with the latest framework, but to geek out on things and become better at what I truly believe is a craft.
If at some point the noise overpowers the substance that I care for, I hereby request anyone who takes pity to let me know where to move on to. But so far, with dangs good moderation, I'm impressived with how well HN is holding out.
I could go on to write a love-letter to how a number of HN posts make me want to be a better programmer, but I'll keep it a simple as possible.
Being here, even now, and even though I do sort of feel like one of the 'older crew' suspiciously eyeing what appears to be an influx of 'others', to put it vaguely, ultimately what I love most about this place is reading about the 'old-timers' and how they worked, the 'oldest code that is still in use', the argument for and against LISPs, the problems of the JS/Node ecosystem (bit sick of that), the crazy shit some programmer created, and so on.
I'm pretty much addicted to HN, while I managed to cut out Facebook and Reddit. What keeps me here is the intense desire to be a hacker, and how, even now, HN fuels it. To not just make websites or work with the latest framework, but to geek out on things and become better at what I truly believe is a craft.
If at some point the noise overpowers the substance that I care for, I hereby request anyone who takes pity to let me know where to move on to. But so far, with dangs good moderation, I'm impressived with how well HN is holding out.
Do you have the link to the MS disk management story?
https://support.microsoft.com/en-us/kb/3053711
(from the link)
Resolution
To resolve the issue, do not create a user account contains the string "user" on the computer.
(from the link)
Resolution
To resolve the issue, do not create a user account contains the string "user" on the computer.
Applies to
...
Windows 8.1 with Bing
Windows 8.1 with Bing is sold at a very low price with a 100% rebate (I.e it is free).
Google shares ad revenue from bundled searches, if you use Google on Firefox then Mozilla takes 20%. Likewise for Windows OEMs and Apple Safai.
Google shares ad revenue from bundled searches, if you use Google on Firefox then Mozilla takes 20%. Likewise for Windows OEMs and Apple Safai.
Where can I read more about this?
It's a free version of Windows with Bing installed as the default search engine. Meant to compete with Chromeos.
Oh. That explains a lot.
In the spirit of POC||GTFO, I created a user called "testuser" on my work machine (running Windows 8.1) today, and I couldn't reproduce the problem. It seems the missing "with Bing" part may be responsible...
In the spirit of POC||GTFO, I created a user called "testuser" on my work machine (running Windows 8.1) today, and I couldn't reproduce the problem. It seems the missing "with Bing" part may be responsible...
It applies to every version of Windows 8.1, according the docs, not only Windows 8.1 with Bing. To be fair, its an intermittent problem, so could just happen on longer intervals or some other scenario.
We can't have that. Someone fix that bug and get it to start using up CPU cycles!
I had a bug with a Bank of America payment system which wouldn't accept registrations with upper-case Zs in the company name. I went into super sleuth mode and somehow found the company they hired to make it and got a number for their development department. After explaining the problem to the guy who answered his only response was, "How did you get this number??"
How did you get that number?
"shibboleet" https://xkcd.com/806/
A few years ago I discovered that the wells-Fargo website would log you in by typing the correct password and some additional n characters after the password. I reported it to the security group and that still worked until I stopped banking with them a year or so later.
I've heard of systems like these, which would essentially store passwords as n-length strings, and upon registration/verification simply truncate the given string to n characters.
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:
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;
}
}
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).
The title reminds me of "the 500 mile email"
http://www.ibiblio.org/harris/500milemail.html
http://www.ibiblio.org/harris/500milemail.html
Great story. Also, never knew about units.
This is one story I always enjoy when it is brought up.
Me too. Are there any others you could recommend?
Some of my favorite hacker folklore:
Always Mount a Scratch Monkey http://edp.org/monkey.htm
The Magic Switch https://www.cs.utah.edu/~elb/folklore/magic.html
Quake3's Fast InvSqrt() https://www.beyond3d.com/content/articles/8/
The Battle Chess Duck 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
edit to add: Ford and the $10,000 chalk mark (Ctrl+F Ford) http://www.smithsonianmag.com/history/charles-proteus-steinm...
Always Mount a Scratch Monkey http://edp.org/monkey.htm
The Magic Switch https://www.cs.utah.edu/~elb/folklore/magic.html
Quake3's Fast InvSqrt() https://www.beyond3d.com/content/articles/8/
The Battle Chess Duck 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
edit to add: Ford and the $10,000 chalk mark (Ctrl+F Ford) http://www.smithsonianmag.com/history/charles-proteus-steinm...
I just love the magic switch.
It's so obviously impossible, yet anybody that built complex hardware has seen equally impossible things happen.
It's so obviously impossible, yet anybody that built complex hardware has seen equally impossible things happen.
That was so fun and a great prank whether true or not. Like you, I've seen enough oddities to think it's possible. I'm going to challenge two hardware guys I know... one an expert on esoteric stuff. to come up with a way to make that happen. Maybe I'll do it to a RaspPI at a maker space near MIT to screw with them. ;)
If the case of the switch was connected to the unused terminal it may have served a purpose by connecting signal and chassis grounds.
I prefer the idea that it was magic :)
I prefer the idea that it was magic :)
Big second for Quake's Fast InvSqrt, that is a really cool story.
Another favorite of mine. I won't spoil it, it's an entertaining read: http://www.ee.ryerson.ca/~elf/hack/recovery.html
That is awful. Surely there was a sign attached saying that this equipment is attached to live Monkeys - not just a "do not remove" sign.
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 https://www.cs.utah.edu/~elb/folklore/mel.html
http://web.mit.edu/humor/Computers/real.programmers https://www.cs.utah.edu/~elb/folklore/mel.html
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. :)
Here's the car allergic to vanilla ice cream. http://www.cgl.uwaterloo.ca/smann/IceCream/humor.html
Some more:
The disappearing Polish S https://medium.engineering/the-curious-case-of-disappearing-...
System Shock "A story of a 25-year-old font coming back with a vengeance" https://medium.com/designing-medium/system-shock-6b1dc6d6596...
The disappearing Polish S https://medium.engineering/the-curious-case-of-disappearing-...
System Shock "A story of a 25-year-old font coming back with a vengeance" https://medium.com/designing-medium/system-shock-6b1dc6d6596...
The fact that Polish language has 2 keyboard layouts installed by default probably costed humanity millions of dollars in wasted time, helpdesk calls, etc.
You see - the "typist layout" (the one nobody uses) has "z" and "y" switched. And by default both layouts are enabled, and the shortcut to switch between them is Alt+Space (or Ctrl+Space - I think it changed at some point?). So when you have "z" or "y" in your password and you accidently pressed "alt+space" - your password "stops working". But you won't see why - because it's all stars. So you try 3 times and you have to call helpdesk.
You see - the "typist layout" (the one nobody uses) has "z" and "y" switched. And by default both layouts are enabled, and the shortcut to switch between them is Alt+Space (or Ctrl+Space - I think it changed at some point?). So when you have "z" or "y" in your password and you accidently pressed "alt+space" - your password "stops working". But you won't see why - because it's all stars. So you try 3 times and you have to call helpdesk.
“COMPUTER-RELATED HORROR STORIES, FOLKLORE, AND ANECDOTES”
http://wiretap.area.com/Gopher/Library/Techdoc/Lore/rumor.ne...
“Computer Stupidities”
http://www.rinkworks.com/stupid/
http://wiretap.area.com/Gopher/Library/Techdoc/Lore/rumor.ne...
“Computer Stupidities”
http://www.rinkworks.com/stupid/
Computer stupidities almost gave me a case of fatal hilarity when I first discovered it. Especially the section about smoke is priceless.
This one too:
https://en.wikipedia.org/wiki/Lp0_on_fire
Sometimes Wikipedia does have a sense of humour:
> While modern inkjet and laser printers are nowhere near as flammable as their mainframe ancestors,[citation needed].
> While modern inkjet and laser printers are nowhere near as flammable as their mainframe ancestors,[citation needed].
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?"
Yes, I would have never put those together either. One of the duplicate bugs has a similar thread, where a user describes reinstalling his system three times and failing to print every time. But after running updates after the third install, it suddenly worked again.
A helpful response then pointed out that after the third reinstall, his system clock must have gone past midnight, which means it was no longer Tuesday...
A helpful response then pointed out that after the third reinstall, his system clock must have gone past midnight, which means it was no longer Tuesday...
[deleted]
only someone who doesn't understand computers would notice it, programmers would say "that doesn't matter" :)
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.
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.
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.
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...
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...
Not having preconceptions about likely causes surely helped but it's possible that her use of the printer was not uniform across weekdays which might make it stand out more.
Every Tuesday morning I have to re-authenticate the 2FA that lets me connect to various things at work, and it isn't documented anywhere, but you'd better believe I figured out the pattern real fast. Being annoyed at the same time of the work week is very noticeable.
I have a Google Hangouts Tuesday mornings. Once a month, reliably, I'd suddenly be kicked off my own Hangout because Google has decided it's time for me to type my password back in.
Of course I do, reliably pushing the problem another month down the road.
Of course I do, reliably pushing the problem another month down the road.
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 :)
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 :)
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
But "Tue" is not at the fourth byte in the example, which has:
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.
%%CreationDate: (Tue Mar 3 19:47:42 2009)
%%(Tue Mar 3 ...)
-+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
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.
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).
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.
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.
I agree completely. I set up a relative with Linux Mint KDE 17.3 a couple weeks ago and even I was surprised at how easy it was to set up the two printers he wanted to use: one was an old 2003-vintage LaserJet 1012 personal-sized laser printer with USB, the other a newer (I'm guessing 4yo) HP color inkjet of some kind that was WiFi-connected. For the first, I just plugged in the USB cable and a print queue was immediately and automatically set up; I didn't have to do anything. For the latter, I just went into the printer configuration utility, let it search the network, it found the printer and told me its model name/number, then I selected the appropriate driver and printed a test page. No driver downloads, no problems.
By contrast, I had a contract job a year or so ago at a large company where I was given a Win7 laptop and tried to connect to a big Ricoh laser printer. I spent hours messing around with driver downloads trying to get that to work. I finally had to call IT and they sent someone over, and he couldn't get it to work either; he finally found some crazy work-around which I've totally forgotten the details of now.
The only real problem I see with printing on Linux now is that, sometimes, there's multiple CUPS drivers for the same printer (foomatic, hpijs, Postscript, etc.), so it won't automatically pick one and it's not clear which is the best so you might have to just try one and see if it works. Most likely, they all work, but some might have additional features. HP printers are probably the best, though, since they seem to explicitly support Linux (such as with their hpijs drivers). If all printer makers had this level of support, and they cleaned up the redundant/competing drivers, there wouldn't be complaints.
By contrast, I had a contract job a year or so ago at a large company where I was given a Win7 laptop and tried to connect to a big Ricoh laser printer. I spent hours messing around with driver downloads trying to get that to work. I finally had to call IT and they sent someone over, and he couldn't get it to work either; he finally found some crazy work-around which I've totally forgotten the details of now.
The only real problem I see with printing on Linux now is that, sometimes, there's multiple CUPS drivers for the same printer (foomatic, hpijs, Postscript, etc.), so it won't automatically pick one and it's not clear which is the best so you might have to just try one and see if it works. Most likely, they all work, but some might have additional features. HP printers are probably the best, though, since they seem to explicitly support Linux (such as with their hpijs drivers). If all printer makers had this level of support, and they cleaned up the redundant/competing drivers, there wouldn't be complaints.
No, you've simply been lucky.
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.
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.
>My experience with both OSX and Windows is that you just need to plug a printer in and it just works.
It's never been that way for Windows: you've obviously never used a network printer in a large office.
It's never been that way for Windows: you've obviously never used a network printer in a large office.
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.
CUPS is better, no doubt. And from a sysadmin perspective CUPS is great, but there are still crazy gotchas.
Part of this is the byzantine config of network discovery, CUPS, driver sources, etc. A big part of the problem is the pieces may be there but distros have done a mediocre job getting everything together on this in the best way for the user.
Part of this is the byzantine config of network discovery, CUPS, driver sources, etc. A big part of the problem is the pieces may be there but distros have done a mediocre job getting everything together on this in the best way for the user.
In my experience it is the exact opposite. My Linux computers are always able to quickly connect and print to any printer I point them towards. I have never had as many problems as I have had when using Windows or OS X.
I can't say it's been any "easier" to connect to my Brother MFC-J4420DW on Fedora as it is on Windows, but it's no harder. Download the installation script from Brother, run it, it asks me for the hostname of my printer and I'm up and running.
> Download the installation script from Brother, run it, it asks me for the hostname of my printer and I'm up and running.
But this is already sounding archaic and difficult isn't it? Just download and run an installation script? Give it the host name? No way a nontechnical user is going to be able to do either of those things.
Why doesn't the printer just appear like it does on my Mac? I'm not even sure what my printer's host name is so I wouldn't even be able to do that step myself!
But this is already sounding archaic and difficult isn't it? Just download and run an installation script? Give it the host name? No way a nontechnical user is going to be able to do either of those things.
Why doesn't the printer just appear like it does on my Mac? I'm not even sure what my printer's host name is so I wouldn't even be able to do that step myself!
However worse that installation may be on Linux compared to your Mac, it pales in comparison to the atrocious Windows experience.
"Download this .ZIP file from the Brother website. Then unpack it somewhere. Go through these dialog boxes from the Devices and Printers control panel. Be sure to uncheck such and such before clicking next in such and such. Then at this point, choose "Have Disk" and browse for where you unzipped the drivers and find the ".inf" file in there somewhere."
If the printer is on a dynamically assigned IP address, chances are that the port created for it will use a hard-coded entry like "192.168.1.13" which will break. The DHCP host name requested by the printer can be used, but you will have to manually enter that. It is some awful serial number: a mixture of random digits and letters. It's better to navigate to the printer's web firmware first, and rename it to some human-readable name, then edit the printer port to match.
"Download this .ZIP file from the Brother website. Then unpack it somewhere. Go through these dialog boxes from the Devices and Printers control panel. Be sure to uncheck such and such before clicking next in such and such. Then at this point, choose "Have Disk" and browse for where you unzipped the drivers and find the ".inf" file in there somewhere."
If the printer is on a dynamically assigned IP address, chances are that the port created for it will use a hard-coded entry like "192.168.1.13" which will break. The DHCP host name requested by the printer can be used, but you will have to manually enter that. It is some awful serial number: a mixture of random digits and letters. It's better to navigate to the printer's web firmware first, and rename it to some human-readable name, then edit the printer port to match.
> If the printer is on a dynamically assigned IP address, chances are that the port created for it will use a hard-coded entry like "192.168.1.13" which will break. The DHCP host name requested by the printer can be used [...]
Personally, I've never understood this. Are there a lot of admins who let their printers take IPs from the DHCP pool?
Personally, I've never understood this. Are there a lot of admins who let their printers take IPs from the DHCP pool?
> Are there a lot of admins who let their printers take IPs from the DHCP pool?
You mean just about every single home network?
Although, in an enterprise setting, if you count DHCP reservations then that's what we do, having our whole office use them has greatly simplified our network configuration.
I could imagine a world where printers had a built-in DDNS client which would make them truly plug-and-play in an office but that's probably more complicated than it's worth.
You mean just about every single home network?
Although, in an enterprise setting, if you count DHCP reservations then that's what we do, having our whole office use them has greatly simplified our network configuration.
I could imagine a world where printers had a built-in DDNS client which would make them truly plug-and-play in an office but that's probably more complicated than it's worth.
> Although, in an enterprise setting, if you count DHCP reservations then that's what we do, having our whole office use them has greatly simplified our network configuration.
Pretty much my de-facto solution for networking, managing static IP's is a pain even with something like Puppet - one mistake with the configuration and I have to open up vCenter to get to the console and fix the configuration to get network connectivity. I literally use DHCP reservations for everything with the exception of intra-cluster communication for my PostgreSQL replicas (those are on a separate VMWare network and I manage those statically, but they never change).
> I could imagine a world where printers had a built-in DDNS client which would make them truly plug-and-play in an office but that's probably more complicated than it's worth.
This is what a DHCP hostname is for, no? My cheapie ASUS AC1900 at home uses the DHCP hostname from any device it allocates an IP address to as a local DNS alias, if I run `nslookup ls410d9a3.local 192.168.1.1` on any system on my home network it will point me to my Buffalo NAS (without needing multicast DNS, though that would still work as a fallback) - same for BRW142D2763B66E.local (which is my printer).
I could just as easily configure any dhcp server I use to automatically register DNS entries for new hosts if I wanted (probably in a separate DNS zone to prevent peoples phones from showing up in the default DNS search path).
Pretty much my de-facto solution for networking, managing static IP's is a pain even with something like Puppet - one mistake with the configuration and I have to open up vCenter to get to the console and fix the configuration to get network connectivity. I literally use DHCP reservations for everything with the exception of intra-cluster communication for my PostgreSQL replicas (those are on a separate VMWare network and I manage those statically, but they never change).
> I could imagine a world where printers had a built-in DDNS client which would make them truly plug-and-play in an office but that's probably more complicated than it's worth.
This is what a DHCP hostname is for, no? My cheapie ASUS AC1900 at home uses the DHCP hostname from any device it allocates an IP address to as a local DNS alias, if I run `nslookup ls410d9a3.local 192.168.1.1` on any system on my home network it will point me to my Buffalo NAS (without needing multicast DNS, though that would still work as a fallback) - same for BRW142D2763B66E.local (which is my printer).
I could just as easily configure any dhcp server I use to automatically register DNS entries for new hosts if I wanted (probably in a separate DNS zone to prevent peoples phones from showing up in the default DNS search path).
> You mean just about every single home network?
Bingo!
No home user is going to statically assigns an IP to their printer on Wi-Fi; that would require a power user who even knows what that is.
Bingo!
No home user is going to statically assigns an IP to their printer on Wi-Fi; that would require a power user who even knows what that is.
I learned years ago to always assign IP addresses to printers via DHCP but to set up reservations for them so that the IP doesn't change. Of course, this was at the time that configuring an IP address manually on a printer involved a two-line LCD screen (if you were lucky) and clicking buttons on the front to increment each octet of the IP address by one each time you clicked.
Re-addressing a couple hundred printers was not fun when each of them was configured manually via the front panel.
Re-addressing a couple hundred printers was not fun when each of them was configured manually via the front panel.
> clicking buttons on the front to increment each octet of the IP address by one each time you clicked.
That is exactly how, just over a week ago, I gave that brand new printer its Wi-Fi password: moving a cursor and incrementing through a character set.
Just like naming the presets on a Yamaha audio effects processor I bought in 1989.
That is exactly how, just over a week ago, I gave that brand new printer its Wi-Fi password: moving a cursor and incrementing through a character set.
Just like naming the presets on a Yamaha audio effects processor I bought in 1989.
There are a lot of people who install a printer despite not having access to the router.
Exactly. On my Linux systems, it's just like your Mac (and considering that CUPS is owned by Apple and used on Macs just like on Linux, this makes sense): you just let the printer appear when it searches the local network, and select one of the already-loaded drivers. Why would you need to download some "installation script" from the manufacturer? How ridiculous.
I just got a Brother LED printer: the HL-3170CDW. Very nice printer. Works fine on with one 64 bit Win-7 system. With another system, a 32 bit Win-7, it won't work at all. Printing a test page fails with 0x000000D, and no application can print. (The printer is seen, and its status can be monitored and so on, but Windows just won't print!) This is whether or not it is on Wi-Fi or USB. I tried three versions of the drivers, and every possible remedy: I applied a Microsoft HotFix for repairing Win7/SP1 systems. I ran sfc /scannow. I run chkdsk /F on the C: drive. (The machine is an older system, but the SMART info shows that the drive is in perfect health: low temperature, no bad sectors.) I reset Windows Update and got it into a sane state. I went through every possible trouble-shooting procedure that could be googled up that could be related to the issue. Fixed things in the registry according to various steps. No dice.
In my experience printing in Linux has been pretty solid for at least the last 5 years or so. CUPS is CUPS, drivers are plentiful and one apt-get away, UIs get better.
Of course I'm limited to occassional document or a few tickets.
Of course I'm limited to occassional document or a few tickets.
One of these days, someone may give me a credible explanation of why printing involves a systemwide daemon, but I kind of doubt it. I'd love to see a rearchitecting of the whole mess such that the whole print daemon runs in in a sandbox with user privileges.
How would you avoid having a common print queue, when all the documents can't fit in the printer memory?
It's been a while since I bought a printer that connected via any means other than Ethernet or Wifi, so the printer already needs to manage its own queue regardless of what the client computers do.
For printer that attach directly, there could be a daemon that arbitrates access and handles accounting or the system could simply allocate the printer to the logged-in user. For directly connected printers on multi-user systems, you'd want a real daemon, of course.
For daemons that mediate access, IMO the arbitration and accounting should be split from formatting and rasterization (if needed). For accounting and arbitration, the right way to do it is to speak something like Printer Job Language. I actually wrote a daemon like this years ago. I wonder if I still have the code. It actually counted pages regardless of how they were submitted.
Anyway, for a normal desktop machine, I think that the system daemon is silly these days.
For printer that attach directly, there could be a daemon that arbitrates access and handles accounting or the system could simply allocate the printer to the logged-in user. For directly connected printers on multi-user systems, you'd want a real daemon, of course.
For daemons that mediate access, IMO the arbitration and accounting should be split from formatting and rasterization (if needed). For accounting and arbitration, the right way to do it is to speak something like Printer Job Language. I actually wrote a daemon like this years ago. I wonder if I still have the code. It actually counted pages regardless of how they were submitted.
Anyway, for a normal desktop machine, I think that the system daemon is silly these days.
I think you overestimate the queue size of a regular printer. Many still only have 32MB of RAM, so they can barely hold more than a few pages, if they have graphics. In my office, it's common for the OS queue to be waiting for the printer queue to free up some space.
So what?
If three users on a workstation each print a document that uses lots of RAM, two of them are going to have to wait no matter what.
If three users on a workstation each print a document that uses lots of RAM, two of them are going to have to wait no matter what.
My point is that you still want a workstation daemon for a networked printer, because the printer can't hold three documents in its queue, yet the other users don't want to have to manually retry printing until they get a spot in the queue.
Have the printer act as a server to which each of the sandboxed print queues talks directly, seeking permission to send data, and let the printer handle flow control.
Not saying this is necessarily a good idea, but it avoids a system-wide print queue, all you need at the system level is a service locator to let you know where the printer is that you need to contact.
Not saying this is necessarily a good idea, but it avoids a system-wide print queue, all you need at the system level is a service locator to let you know where the printer is that you need to contact.
It's not a bad idea, that's a print server or IP printer. But it's a modern system, and the print daemon architecture predates printers having their own microprocessors. It may even predate TCP.
The need to print documents predates Unix. :) Remember that the official excuse for getting a PDP-11 for developing Unix was to work on troff.
Ostensibly, you're right, but then the answer to "why do we need a system daemon" is "because Linux distros don't control the firmware of all printers nor can they tell manufacturers what to do."
In the case where a printer isn't intelligent enough to act as its own server, you could create another daemon whose sole function is to control access to the printer. Separation of concerns: formatting of pages and access control need not be the same piece of software.
you could create another daemon whose sole function is to control access to the printer
You could call it 'lpd' and then the circle would be complete.
You could call it 'lpd' and then the circle would be complete.
[deleted]
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/
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/
CERN: LEP data confirm train time tables
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-ju...
CERN: Is the moon full? Just ask the LHC operators http://www.quantumdiaries.org/2012/06/07/is-the-moon-full-ju...
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
Wait till you see where they found the print server!
http://www.informationweek.com/server-54-where-are-you/d/d-i...?
http://www.informationweek.com/server-54-where-are-you/d/d-i...?
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.
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.
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.
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.
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.
Here's a great collection of classic bug reports (including the never-printing-on-tuesdays): https://news.ycombinator.com/item?id=10309401
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
[2] 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
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
[2] 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
; 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 ;)I vote this as the best heisenbug I've read so far. That's sounds like such a nightmare to debug. I might have never found it due to throwing the thing in the trash and buying a different machine. Forth is easy to port after all. :)
Funny, I remember that bug very well, it was used on the earlier apple IIs, sometime on purpose (!) (mostly by game protections). This was fixed on the 65c02.
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.
"tue" means "kill" in french... I wonder if a french programmer somewhere had something to do with this?
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
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
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.
And you do what the neurons in your brain make you do.
Article from today - http://www.theatlantic.com/magazine/archive/2016/06/theres-n...
Article from today - http://www.theatlantic.com/magazine/archive/2016/06/theres-n...
[deleted]
You might be interested in what Scott Adams (the Dilbert cartoonist) has to say about the current presidential election: http://blog.dilbert.com/
Nope.
Off topic and no arguments to support your case, sounds like downvote material to me.
People die all the time from "bugs" in the genes, or from acquired defects. This doesn't stop the rest of the people and the race going on.
Same thing with AI. Some will crash and burn. Others will manage to continue.
Nothing is eternal. We only need stuff to work for a while for it to be useful.
Same thing with AI. Some will crash and burn. Others will manage to continue.
Nothing is eternal. We only need stuff to work for a while for it to be useful.
So what's the lesson here? What should we learn from that?
Lesson is: Not every post here should teach a lesson?
Make sure you escape spaces? Or: https://news.ycombinator.com/item?id=11718716
Is it just me or does this get posted every month?
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.
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
Probably because it gets mentioned often in addition to be reposted often.
https://hn.algolia.com/?query=openoffice%20tuesday
Probably because it gets mentioned often in addition to be reposted often.
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.
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.
> 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.
This bug had nothing to do with OO. This was just a cute manifestation of the actual bug.
This bug had nothing to do with OO. This was just a cute manifestation of the actual bug.
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.