Some years back I had a case where a co-worker complained his mouse didn't work in the afternoon. Eventually I went to have a look, and he demo'ed the issue; sure enough the mouse was completely unresponsive. Luckily I guessed the issue immediately and quicky demonstrated - with a shrug - that the mouse "works fine for me".
Thing was I'd spotted there was strong sunlight through the window hitting the mouse; guessing it was probably swamping the optosensors I made sure I covered the side of the mouse with my hand when using it. His puzzled looks as the mouse worked for me but not for him were priceless (I did let him in on the secret after a few minutes).
I was an admin for a company that had lots of open plan offices. In one of these offices a specific row of computers kept failing. Although they were cheap (Compaq Evos with NT4), they were pretty damn reliable throughout the rest of the company.
Lot of head scratching ensued about the fault. Nothing really made sense.
Totally by chance we found out what was wrong. One Saturday when the office was empty and with no a/c background noise one of the other admins noticed the PCs in the problem row weren't making any fan noise. A quick investigation revealed that the PSU fans had been blocked with paperclips and bits of paper causing the CPU to overheat.
An older member of staff who was in that row found the PSU fan noise irritating and just decided to take action to stop it. She genuinely didn't realise she was breaking the PCs.
Here is a similar story from the childhood of computers: One of the first computers installed in a Norwegian university was of course in high demand, and students generally had to stay up at night to be able to use it. One morning, around 3 o'clock, the line printer came to a a halt and locked up the computer. They tried everything they could think of to get it going again, to no avail.
In the end they called the person in charge of the computer. He came over and closed the curtains, and the printer started up again. He left without a word of explanation.
That explanation emerged later: The early morning sun (the sun rises early in the summer here) was shining in, through the paper in the printer, onto the out-of-paper sensor, making the printer think it had no paper. Closing the curtain fixed it.
That is absolutely hilarious. Flashback to a similar technology `sleight of hand` -
Back in middleschool, when JavaScript's window.open allowed you easily to launch a fullscreen window with no browser chrome, and setting the background-image to a screenshot of the desktop... it was so entertaining watching students and teachers alike try to use the machine and thinking it was frozen!
Similar story in the USAF. We transitioned the academy from Banyon Vines to TCP/IP. An entire building wing went offline every day. A team was flown out with a network analyzer. Sure enough, same time every day, the entire wing of the building went offline. Turns out, the person buffing the floor needed a place to plug in the buffer and the only place they could find had this big box with lots of blinky LED's on it, so they unplugged it, buffed the floor and plugged it back in. Half-split troubleshooting may have saved a plane flight.
I did an industrial automation class in college. We had a PLC setup with optical sensors and were sorting cylinders by height.
We wired it up tested it, then called the TA over to review. It failed despite no changes and working minutes earlier.
We changed some logic, tested again, and again called the TA over. It failed. We had another team look at our code and see if we were missing something obvious. Nope, it looked the same.
Finally I realized I was standing when we did the testing. I shaded the sensors and kept them from being overloaded with sunlight. We were the only table in direct sunlight, so only we were experiencing the issue.
Back in college (90's) we had a professor who, about once a year, would send an email to help desk saying his monitor had gotten blurry and he needed a new one. We'd go to his office, wipe off the thick layer of dust and it'd be as good as new again.
This reminds me of a similar issue I've experienced. A colleague always put his jacket onto his chair. Almost every time he took it off, his monitor connection broke for a few seconds. This mystery was never fully solved, but our best guess was some static (from the jacket-chair-friction) causing issues with his VGA-HDMI adapter.
Remember exactly same thing happening to me some 18-19 years ago lol! It was in the time when mice still had balls, so the reading sensor got blinded by sunlight in at least one direction - sometimes mouse won't work at all, sometimes would but only on X or only on Y axis. Fix: install window shutters.
I work at a K-12 school and had a similar experience working in a school. The teacher complained the Smartboard touch capability wouldn't work in the morning, but worked in the afternoon. I said nonsense. Went in there and surely it didn't work, but I noticed a bit of a glare from the reflection of the light on the window. I asked her to turn down the shade and the Smartboard instantly started working... felt awesome lol.
20+ years ago, machines with a monochrome and a color monitor. One machine the color monitor would fail every afternoon.
Turns out that for some reason there was a little notch cut in one slat of the blinds. (Presumably to fit around something that was no longer there.) That allowed the sunlight to strike the video card, apparently that was just enough heat to push it over the edge. (This was before PCs were full of cooling fans.)
As support IT in an office, I have a lot of mouse "issues", particularly with the wireless Apple Magic Mouse ... using it turned around 180 deg., making things disappear by not recognizing that the surface can be used to scroll horizontally, battery dying ... to name a few.
We had an xbox 360 that kept ejecting the CD. Later we discovered that it was due to the sunlight coming from the door. After putting it in a dim place the issue never recurred.
I had a user once calling me real desperately saying she was hacked. Got to her desk and nothing was going on.
She then sit or her desk and started talking me through what she was doing, then suddenly the screen started to move by itself, stuff getting typed everywhere, applications opening and closing all around.
Turns out she had accidentally turned on speech recognition on her mac, and the laptop was simply trying to parse - in English - everything we were saying - in Portuguese - into valid commands.
Arguably the most famous example of a bug like this is the person who would drive to the store to buy ice cream and depending on what flavor of ice cream they bought, the car would or would not start back up.
I had a 2011 Macbook Air that would go blank randomly. After some investigation, I determined it was often when I was moving it from one place to another (sometimes even just repositioning on my lap), and that it was going to sleep, not completely crashing.
Of course, MBAs have no moving parts, and there were no rattles when I shook the machine and listened. Apple also could not figure it out. After replacing several parts, they eventually replaced the unit with a newer model (it was 2014 at the time).
Soon after getting my new MBA up and running, it experienced the exact same glitch. I knew it had to be something environmental, since the odds would be astronomical that they would have replaced my unit with one that had the same rare glitch. But I was traveling, which eliminated anything relating to my house, neighborhood, power lines, etc.
Then I looked at my wrist, on which I wore a Seiko Kinetic watch. It was triggering the magnetic lid-closure detector, which is on the sides of the base of the MBA. When I picked up my computer with my left hand (I'm right-handed, so this was less common), it would trip the sensor.
Interestingly, there is a very easy fix for this (and similar issues, mentioned in other comments in this thread), which is to only sleep the machine if both left AND right sensors are triggered. If it seems like the left side of the lid is closed and the right side is not closed, probably it's a false positive!
One of my favorite pieces of debug folklore was the story of a minicomputer or some other serious machine rebooting in the middle of the night. I can't remember exactly but it was in some university during the 70s/80s. An important server would spontaneously reboot in the middle of the night on some days but not all.
Finally, someone sat up all night to watch what happens and observed a cleaning lady unplugging the machine from power in order to plug in a vacuum. When she was finished, she plugged the computer back in and left.
Another on of my favorites, not bug but more malicious, was someone wrote a program to swing the heads on one of those old giant hard drives back and forth. At the right frequency, the back and forth momentum would cause the drive to walk away from the wall and eventually unplug itself.
I had a bug on a small system (basically an embedded computer with some custom I/O hardware), where the report was a unit "wouldn't reboot if it was turned off for too long(!?)".
Focused testing easily reproduced the problem. If you power cycled the machine and the off time was less than 30 seconds, it always rebooted correctly. If the off time was greater than 2 minutes, it ALSO always rebooted correctly, but if the off time was around 1 minute, it would reliably hang during the boot process. This behavior was rapidly confirmed on a number of other units taken off the production line.
Needless to say this was very confusing.
The eventual root cause was that during boot, a file-system was created in DRAM, similar to what a modern system would use initramfs for. The file system creation routine had originally been written for non-volatile memory, so it would by default check for a superblock to see if there was already a file system in place at the creation location and if there was, just use that (after unlinking all pre-existing files). If no pre-existing FS was found it would create a new one.
But this was in DRAM, not non-volatile memory so:
- if the off time was less than 30 seconds, the filesystem was STILL IN THE DRAM and the ramfs_create() routine would happily re-use it.
- if the off time was over two minutes, there were enough bit errors in the DRAM that ramfs_create() would fail to recognize the superblock, overwrite it with a new one, and everything STILL worked fine.
- in the critical timing zone, the number of bit errors in the superblock in DRAM would be small enough that the FS creation would recognize that there was a pre-existing filesystem, but large enough to cause the ramfs_create() function to error out. The boot would then hang when the DRAM filesystem was accessed.
Of course there was no error checking on the ramfs_create() return.
The solution was to change the flags to ramfs_create() to overwrite unconditionally. After that, booting was reliable with any amount of off time.
Lesson is - cold boot attacks on DRAM contents are real, and we managed to do it to ourselves by accident.
I love bugs like this. As a developer or Sysadmin you'd think the users are crazy again but then you dig deeper until you lose all hope and already book flights to become a farmer in the midwest and then you find something like thís
I can't find it, but a while ago there was a post on some StackExchange page (SuperUser maybe?) and reddit that had the following problem: Whenever a specific person passed a specific cubicle, one of the monitors would turn black/lose signal and turned back on after the person was away again. I don't remember how it got resolved or rather what the problem was. Since it only happened on a specific person people were guessing it was about static electricity from the specific clothing(-style) or similar in the early process. Maybe someone else had heard of this or can find it?
My most recent one was that 3 minutes after someone else would SSH into my workstation, my X11 session would crash, but when I would SSH into my workstation, there was no error.
It turns out the default configuration for systemd-logind is to sandbox it away from networking; it's an NIS setup where I am, but I had a local passwd entry for myself so that my home directory would be local. There was a 3 minute timeout on something NIS related, which would cause an error. Then systemd-logind would restart system-wide, including my local login.
I'm gonna argue that the bug is not in "file". The bug is that the workflow uses file, which by it's very nature must be based on heuristics and will get things wrong occasionally.
EDIT: Well file really had a bug in this case, where they didn't detect what they thought they were, but the point stands.
I agree that you should use care when using file. My app relied on "file" to identify file types, and in some cases it mis-identified some Microsoft Office files. The problem was that Apple ships a very old magic file with macOS, and when I reported the bug they said they don't care.
I'm not sure to agree: if/as *nix systems do not use the extension to know the filetype, then `file`-like heuristics is the only other way to know the file nature, or do I miss someting?
It's both really. A workflow using "file" only (and without -k or so) is silly because, as everybody knows, some files are valid for more than one file format. "file" was obviously wrong in the described circumstances...
I wish filesystems would commonly support to store the Mime type. File extensions seem to me still a residue from MS DOS times. That would also make working with static (file) webservers much easier. (It's such a breeze to work with blob stores that allow to save the mime type...)
I ran into another strange doesn't-work-at-this-time issue at my first job, network/systems admin in the early 00s. We had a point to point microwave link that would go down at about 4:30pm every day. It was really bizarre; this was on kit on the roofs of two hospitals, and a pain to physically access.
We spent quite a bit of time chasing down various options for it to be a software issue. Someone went and checked the kit and visually saw that we had clean line-of-sight for the link.
It kept happening.
Eventually, a colleague went out while it was down. It turned out that there was a crane on a building site, and when they parked it stationary it blocked line of sight.
This is why one of my favorite features in the original MacOS filesystem was type/creator fields (four uppercase letters each). Yes, it was possible for developers to create collisions, but it was still better than the UNIX method of applying fragile heuristics to the file contents. IMO it would still be a good idea to replicate this (minus the four-character limitation) with a standardized extended attribute, falling back to the heuristic method only when that fails.
The separation between type and creator had other beneficial side effects. The Type code told you which apps _could_ open a file (by drag and drop or via the file chooser dialog). The creator code told you which app _would_ be chosen when the file was opened in the Finder (e.g., double-clicked). So HTML documents I had created in some web authoring tool would open in it for editing, whereas those I had saved from a web browser would open in it for viewing.
I don't remember it being possible to change either code using tools that shipped with the OS. I obtained a tool on one of MacFormat's early cover disks...
My favorite part was that MacOS's user account permissions used those creator codes to decide whether you were allowed to run an application or not.
Want to run the Unreal Tournament demo in the school computer lab? ResEdit its creator code to something you were allowed to run, and it'd fire right up.
"RASM" was a favorite, belonging to the remote access status monitor utility. All users automatically had access to run it, and it didn't have any document relationships that were going to be confused by applying it to other applications.
It also had some way of quickly finding what apps were on a volume and what file types they handled.
This meant that if you had a file and did not have the correct app to open it, all you had to do was insert a floppy or CD that contained a Mac volume that had a copy of that app, and then you could open the file.
Most apps would run fine off a CD, so you could keep a CD with all the big apps that you rarely used and just insert it whenever you had to deal with a file using one of those apps.
In my first install of Arch linux, I figured that using the bleeding edge software meant everything was supported. Upon plugging in an external monitor into my Dell laptop, it, indeed worked.
Well, until I moved my mouse cursor over to that monitor. It then turned off. Move the mouse back to the laptop screen; external monitor turned back on. My first foray into Arch linux ended up with a bug report against Intel's graphics driver.
Luckily, it was fixed very quickly and I'm proud to say it's finally time for Linux on the deskt---- err laptop.
I got some legacy applications of work. One of them needed a new feature for something. Including database update scripts. So it was changed, very carefull because it had to use a database trigger ( ms sql) which i haven't used before.
It was released in demo/test environment, for 1-2 months and there was never an error.
When it got deployed into production, the integrating applications with it went to shit. Rollbacked everything and it was fine again. Made me seriously doubt myselve. I contacted the older devs that touched parts of the database and application, they didn't saw any issues.
Fast forward 2 months, i heard it was deployed again into production without any issues.
1 month afterwards, a colleague found an "issue" with the deployments. In short: if you deploy to production, for some applications it would deploy and older version ( 50% chance since a swap happened).
I wonder why anyone thought that `file` should have hard-coded custom behaviour on that one very specific type of Erlang file, and how something like that ever ended up getting accepted into the general code base. It sounds like either a very personal workaround for a personal problem, or completely the wrong way to solve a possibly more common problem.
Fixing the bug by properly escaping the string that matches the special file still sounds like the wrong solution to me.
Problems like this make us IT folk seem magical. I routinely remove blank spaces from "empty" fields, rename files without slashes, quit and reload applications "doing something weird." The list goes on. Just this morning I changed an exclamation point a "1" to fix an error with a calculation.
Many of these things can and should be programmed to work, despite the user error. But just as it can be hard for users to understand the fault in their ways, it is difficult for the programer to consider many of these possibilities when deploying applications.
Reminds me of a bug in PostSharp.. After making some changes our app would throw a NullReferenceException Mondays. It turned out to be a bug in some optimisation, but it only occurred on Monday because they skipped licence checks unlocking "full functionality" on a Monday (Happy Monday!) which enabled the optimisation.
I had a fun bug once where some functionality involving self sign certificates stopped working on Feb 29th. It came down to us simply adding +10 to the year for the expiration. There is no Feb 29th 10 years into the future, only 4, 8, 12, etc... That was a good lesson on why to always use a date library when adding or subtracting time. We weren't the only ones... Azure went down for the same reason that day.
[+] [-] hazeii|6 years ago|reply
Thing was I'd spotted there was strong sunlight through the window hitting the mouse; guessing it was probably swamping the optosensors I made sure I covered the side of the mouse with my hand when using it. His puzzled looks as the mouse worked for me but not for him were priceless (I did let him in on the secret after a few minutes).
[+] [-] DoubleGlazing|6 years ago|reply
Lot of head scratching ensued about the fault. Nothing really made sense.
Totally by chance we found out what was wrong. One Saturday when the office was empty and with no a/c background noise one of the other admins noticed the PCs in the problem row weren't making any fan noise. A quick investigation revealed that the PSU fans had been blocked with paperclips and bits of paper causing the CPU to overheat.
An older member of staff who was in that row found the PSU fan noise irritating and just decided to take action to stop it. She genuinely didn't realise she was breaking the PCs.
[+] [-] hanche|6 years ago|reply
In the end they called the person in charge of the computer. He came over and closed the curtains, and the printer started up again. He left without a word of explanation.
That explanation emerged later: The early morning sun (the sun rises early in the summer here) was shining in, through the paper in the printer, onto the out-of-paper sensor, making the printer think it had no paper. Closing the curtain fixed it.
[+] [-] Japhy_Ryder|6 years ago|reply
Back in middleschool, when JavaScript's window.open allowed you easily to launch a fullscreen window with no browser chrome, and setting the background-image to a screenshot of the desktop... it was so entertaining watching students and teachers alike try to use the machine and thinking it was frozen!
[+] [-] LinuxBender|6 years ago|reply
[+] [-] froindt|6 years ago|reply
We wired it up tested it, then called the TA over to review. It failed despite no changes and working minutes earlier.
We changed some logic, tested again, and again called the TA over. It failed. We had another team look at our code and see if we were missing something obvious. Nope, it looked the same.
Finally I realized I was standing when we did the testing. I shaded the sensors and kept them from being overloaded with sunlight. We were the only table in direct sunlight, so only we were experiencing the issue.
[+] [-] dunham|6 years ago|reply
[+] [-] frereubu|6 years ago|reply
[+] [-] darekkay|6 years ago|reply
[+] [-] anovikov|6 years ago|reply
[+] [-] ChicagoBoy11|6 years ago|reply
[+] [-] LorenPechtel|6 years ago|reply
Turns out that for some reason there was a little notch cut in one slat of the blinds. (Presumably to fit around something that was no longer there.) That allowed the sunlight to strike the video card, apparently that was just enough heat to push it over the edge. (This was before PCs were full of cooling fans.)
[+] [-] shanecleveland|6 years ago|reply
[+] [-] ducaale|6 years ago|reply
[+] [-] elwell|6 years ago|reply
Savage...
[+] [-] guhcampos|6 years ago|reply
She then sit or her desk and started talking me through what she was doing, then suddenly the screen started to move by itself, stuff getting typed everywhere, applications opening and closing all around.
Turns out she had accidentally turned on speech recognition on her mac, and the laptop was simply trying to parse - in English - everything we were saying - in Portuguese - into valid commands.
Nice little havoc.
[+] [-] tabtab|6 years ago|reply
[+] [-] soared|6 years ago|reply
https://www.kepner-tregoe.com/blog/help-my-car-is-allergic-t...
[+] [-] gnicholas|6 years ago|reply
Of course, MBAs have no moving parts, and there were no rattles when I shook the machine and listened. Apple also could not figure it out. After replacing several parts, they eventually replaced the unit with a newer model (it was 2014 at the time).
Soon after getting my new MBA up and running, it experienced the exact same glitch. I knew it had to be something environmental, since the odds would be astronomical that they would have replaced my unit with one that had the same rare glitch. But I was traveling, which eliminated anything relating to my house, neighborhood, power lines, etc.
Then I looked at my wrist, on which I wore a Seiko Kinetic watch. It was triggering the magnetic lid-closure detector, which is on the sides of the base of the MBA. When I picked up my computer with my left hand (I'm right-handed, so this was less common), it would trip the sensor.
Interestingly, there is a very easy fix for this (and similar issues, mentioned in other comments in this thread), which is to only sleep the machine if both left AND right sensors are triggered. If it seems like the left side of the lid is closed and the right side is not closed, probably it's a false positive!
[+] [-] chasd00|6 years ago|reply
Finally, someone sat up all night to watch what happens and observed a cleaning lady unplugging the machine from power in order to plug in a vacuum. When she was finished, she plugged the computer back in and left.
Another on of my favorites, not bug but more malicious, was someone wrote a program to swing the heads on one of those old giant hard drives back and forth. At the right frequency, the back and forth momentum would cause the drive to walk away from the wall and eventually unplug itself.
[+] [-] variaga|6 years ago|reply
Focused testing easily reproduced the problem. If you power cycled the machine and the off time was less than 30 seconds, it always rebooted correctly. If the off time was greater than 2 minutes, it ALSO always rebooted correctly, but if the off time was around 1 minute, it would reliably hang during the boot process. This behavior was rapidly confirmed on a number of other units taken off the production line.
Needless to say this was very confusing.
The eventual root cause was that during boot, a file-system was created in DRAM, similar to what a modern system would use initramfs for. The file system creation routine had originally been written for non-volatile memory, so it would by default check for a superblock to see if there was already a file system in place at the creation location and if there was, just use that (after unlinking all pre-existing files). If no pre-existing FS was found it would create a new one.
But this was in DRAM, not non-volatile memory so:
- if the off time was less than 30 seconds, the filesystem was STILL IN THE DRAM and the ramfs_create() routine would happily re-use it.
- if the off time was over two minutes, there were enough bit errors in the DRAM that ramfs_create() would fail to recognize the superblock, overwrite it with a new one, and everything STILL worked fine.
- in the critical timing zone, the number of bit errors in the superblock in DRAM would be small enough that the FS creation would recognize that there was a pre-existing filesystem, but large enough to cause the ramfs_create() function to error out. The boot would then hang when the DRAM filesystem was accessed.
Of course there was no error checking on the ramfs_create() return.
The solution was to change the flags to ramfs_create() to overwrite unconditionally. After that, booting was reliable with any amount of off time.
Lesson is - cold boot attacks on DRAM contents are real, and we managed to do it to ourselves by accident.
[+] [-] geek_at|6 years ago|reply
[+] [-] sdrothrock|6 years ago|reply
http://web.mit.edu/jemorris/humor/500-miles
Edit: And the FAQ: https://www.ibiblio.org/harris/500milemail-faq.html
[+] [-] jaclaz|6 years ago|reply
http://catb.org/jargon/html/magic-story.html
[+] [-] numlock86|6 years ago|reply
[+] [-] aidenn0|6 years ago|reply
It turns out the default configuration for systemd-logind is to sandbox it away from networking; it's an NIS setup where I am, but I had a local passwd entry for myself so that my home directory would be local. There was a 3 minute timeout on something NIS related, which would cause an error. Then systemd-logind would restart system-wide, including my local login.
[+] [-] nabla9|6 years ago|reply
[+] [-] the_watcher|6 years ago|reply
[+] [-] im3w1l|6 years ago|reply
EDIT: Well file really had a bug in this case, where they didn't detect what they thought they were, but the point stands.
[+] [-] jakobegger|6 years ago|reply
[+] [-] wazari972|6 years ago|reply
[+] [-] lazyjones|6 years ago|reply
[+] [-] blablabla123|6 years ago|reply
[+] [-] IshKebab|6 years ago|reply
[+] [-] angrygoat|6 years ago|reply
We spent quite a bit of time chasing down various options for it to be a software issue. Someone went and checked the kit and visually saw that we had clean line-of-sight for the link.
It kept happening.
Eventually, a colleague went out while it was down. It turned out that there was a crane on a building site, and when they parked it stationary it blocked line of sight.
[+] [-] notacoward|6 years ago|reply
[+] [-] yrro|6 years ago|reply
I don't remember it being possible to change either code using tools that shipped with the OS. I obtained a tool on one of MacFormat's early cover disks...
[+] [-] wlesieutre|6 years ago|reply
Want to run the Unreal Tournament demo in the school computer lab? ResEdit its creator code to something you were allowed to run, and it'd fire right up.
"RASM" was a favorite, belonging to the remote access status monitor utility. All users automatically had access to run it, and it didn't have any document relationships that were going to be confused by applying it to other applications.
[+] [-] ken|6 years ago|reply
[+] [-] tzs|6 years ago|reply
This meant that if you had a file and did not have the correct app to open it, all you had to do was insert a floppy or CD that contained a Mac volume that had a copy of that app, and then you could open the file.
Most apps would run fine off a CD, so you could keep a CD with all the big apps that you rarely used and just insert it whenever you had to deal with a file using one of those apps.
[+] [-] TheMerovingian|6 years ago|reply
Well, until I moved my mouse cursor over to that monitor. It then turned off. Move the mouse back to the laptop screen; external monitor turned back on. My first foray into Arch linux ended up with a bug report against Intel's graphics driver.
Luckily, it was fixed very quickly and I'm proud to say it's finally time for Linux on the deskt---- err laptop.
[+] [-] widforss|6 years ago|reply
https://unix.stackexchange.com/questions/405783/why-does-man...
[+] [-] darekkay|6 years ago|reply
[1] https://github.com/danluu/debugging-stories
[+] [-] hbbio|6 years ago|reply
[+] [-] NicoJuicy|6 years ago|reply
It was released in demo/test environment, for 1-2 months and there was never an error.
When it got deployed into production, the integrating applications with it went to shit. Rollbacked everything and it was fine again. Made me seriously doubt myselve. I contacted the older devs that touched parts of the database and application, they didn't saw any issues.
Fast forward 2 months, i heard it was deployed again into production without any issues.
1 month afterwards, a colleague found an "issue" with the deployments. In short: if you deploy to production, for some applications it would deploy and older version ( 50% chance since a swap happened).
Urgh
[+] [-] mcv|6 years ago|reply
Fixing the bug by properly escaping the string that matches the special file still sounds like the wrong solution to me.
[+] [-] agateau|6 years ago|reply
I wrote about it here: https://agateau.com/2012/qt-image-decoders-stepping-on-each-...
[+] [-] shanecleveland|6 years ago|reply
Many of these things can and should be programmed to work, despite the user error. But just as it can be hard for users to understand the fault in their ways, it is difficult for the programer to consider many of these possibilities when deploying applications.
[+] [-] d2p|6 years ago|reply
https://plus.google.com/113181962167438638669/posts/QF5pDB4X...
[+] [-] dodo6502|6 years ago|reply