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.
I had a similar story. I set up a home pc for recording tv and hooked it up to the main entertainment system. I built it on a budget so it did it’s job but later on as we switched to more HD content it struggled occasionally.
I went off to college. My mom noticed the fan noise was increasing and found it distracting. She wrapped the pc in a couple of blankets to cut down on the noise. When I came home the thing was in danger of burning down the house and the video card had failed.
I am not sure if the following is true or one of those stories that gets recycled.
While I was working at Best Buy - the Geek squad told us a story of an older Lady who brought in a computer wrapped entirety in plastic saran wrap, to prevent the virus from escaping the computer and infecting people. She thought it was okay as she containing the virus and continued to use the computer before it turned off and didn't turn on again, which is whys she brought it in.
On the Pentium Overdrive! days, a guy came to my father's shop complaining that the computer wouldn't turn on. Turns out that he had installed the process in a different orientation "to see if it would go faster". Spoiler alert: it didn't.
Neither the CPU nor the motherboard failed (nor did the fancy overdrive socket). Once the CPU was installed correctly, it worked again.
My 'best' related Best Buy story (well, Future Shop a decade ago, but it is/was the same company) while working in the ConnectPro department (name for Geek Squad at Future Shop, all the same tools and procedures):
A person who had purchased a laptop a few hours prior came back into the store furious because the device shut off and wouldn't turn back on. I pressed the power button and it flashed indicating the battery was dead. I connected the laptop to power and told her it needed to be charged. She then threw a retail tantrum because the salesman had apparently told her it was wireless.
I think this really says more about a lack of basic science education in high school. People plug 1800W space heaters into $4 power strips and cause fires. I think by the time you graduate you should at least be able to understand that watts of electricity are the same thing as heat.
I had a similar mystery, except it was like every 5th or 6th cube and only happened in the winter. Turned out there were floor mounted heating ducts, and certain cubes were placed just right so that the hot air went directly into the PSU.
Some combo of heat, dust, and static caused gunk to accumulate in the fans, and eventually either the PSU or video card would overheat. The escalation usually came in that the monitor was tinted blue or pink.
I must confess that the eleven year old me didn't realize it would be a problem to put a screwdriver through the PSU grid to stop the fan from making noise and that it may have been preventing that musheen from working properly at some point.
The eleven years old me was doing the contrary: starting a crappy/sticky PSU fan with a screwdriver not realizing there was a "slight" risk of electrocution (never got a chock however, I guess I was somewhat aware of the danger).
I'm guilty of this at 14; this was the only way I could get away with late night BBSing since the fan was loud and other folks would be disrupted into halting my modem joy. Only when our EE neighbor saw my rig and sternly told me not to do that did I realize it meant anything at all. sheesh
I had a failing PSU that would shut down after an hour of intensive load. I booked it for RMA and was already packing the thing, when I noticed that a stray piece of plastic was stuck in the fan grill, blocking it. Worked fine ever since.
I've seen a similar accidental case where some internal cable in the PSU had gotten dislodged and was partially in the path of the fan blades, with the repeated contact making a chainsaw-like noise. Luckily it was discovered before the fan cut through the casing on the wire.
If you'd kept asking the 5 whys you'd have gotten to the real problem: noisy machines in open offices. You should have thanked the lady who put the paperclips on the fans.
That office was brutally loud. 100 people in a low ceiling office. The a/c was bad, but the plotters the engineering guys used were particularly brutal.
We also had dot matrix printers churning out triplicate documents.
They were lucky, us in IT were technically working illegally due to the noise in our part of the building. So many fans in so many server racks. Plus super cold a/c.
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.
The word you are looking for is azimuth. The azimuth of the sun to the earth shifts as the earth wobbles throughout the year, and as we shift our time for daylights savings.
My garage door was affected by this until I created blinders for the trip sensor.. IR from the sun would cause the garage door to stay open. Lately I just watch my new neighbors leave their garage door open because they can’t figure out why
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!
Tape on the bottom of the mouse is another common joke these days.
If the OS you are using has a taskbar, also set it to auto-hide, preferably in a random location.
As always, that kind of elaborate joke is best kept short. I also like replacing someone's shell with `wine cmd`, but nowadays the best protection for myself is that nobody seems to be able to use my computer (sway, full of shortcuts that you have to know in order to do anything). I'm similarly dumbfounded when at my friend's computers. Luckily, this is all fixed by opening a good old POSIX-compliant shell :)
In college, during the time I worked at the campus library in Stack Maintenance, on some days I also worked in the library computer lab. A joke we played on one friend was to take a screenshot of the regular computer desktop and make that the startup screen.
And the background screen.
And then use ResEdit to allow us to hide all the rest of the regular UI elements unless you typed the magic keyboard combination to un-hide them.
But that was a joke we played on a single friend. We knew that our friend could take a joke, and he wouldn't try to take revenge against us, or anything. No way we would do that on the general public.
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.
The best part of this anecdote is that you mentioned Banyan Vines. Spent a handful of years installing/maintaining Banyan Vines network in the early 90's.
Amazing, and exact version of this happened to me in the Israeli Army in the 90's.
Every day at around 13:30 (give and take a few minutes) the network for an entire building went offline, only to come back on line a few minutes later.
... In our version of this 'bug' - one of the NCOs unplugged the electricity to that "big box with lots of blinky LEDs" in order to plugin an electric pot, to prepare his post-meal Turkish coffee, then plug it back in once water boiled...
Many resources were "thrown" at the problem, until, weeks in, someone had the splendid idea of quietly sitting around the network-cabinet around 13:30 and see what's going on.
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.
I had this one as "weird random stuff that no-one else will never get" so pleasing to know others - like you - not only hit the issue but also worked it out.
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.
I have this occasionally from my MacBook Pro to external 4k. My office seems to be conducive to generating static and I'll occasionally shock my MacBook when first sitting down, temporarily fritz-ing the connection to the monitor.
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.
> ...It was in the time when mice still had balls,
Thinking of present times and times forgone: now mice lost not only balls, they lost their tails, and often find themselves devoid of any 3-dimensionality, being reduced to flat touchpads.
Using a mouse always felt to me as having a friedly handshake with the computer, something that touchpads can't emulate.
That's about the right timescale, I guess mice of the era was a bit 'sensitive'. Lucky we were a small office, I wouldn't have wanted to sent out a memo telling people to cover their mouse in the afternoon.
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.
Except the part where it says that it's a "Legend", and the fact that the explanation and problem are reversed in older and newer versions of the legend.
---
It’s interesting to note how the “vapor lock” explanation reversed itself over time. Earlier versions mentioned a flavor of ice cream that required handpacking (while all the others were prepackaged and ready to go); the vapor lock was said to form because it took so much longer to get out of the store with this one flavor. In newer versions, we’re told that vanilla was a popular flavor and was kept in a special case near the door, making purchasing it and getting back out to the car take considerably less time; the car then wouldn’t start because the vapor lock did not have enough time to dissipate.
What is amazing about this and the other comments of similar, human-based issues affecting technology, is just how gosh darn_reliable_ we humans can be in some cases.
Despite all the complexities and exceptions to human behavior, I think it can be argued that we are far more repetitious and our actions more reproducible than we'd like to admit lest we think we are giving up some of what we thought was actual human natures.
However, we also regale to one-another tales of folks in simpler lifestyles that "always do the same thing, every day, for 50 years", lifestyles that don't change much over generations, and so on. So, if we look at this from a wider perspective, rationally, it shouldn't be that shocking.
Still is interesting, nonetheless. :-)
Edit: After seeing the sibling comment point out this was Snoped, I hope my otherwise seemingly insightful point still stands...:-p
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!
My wife had effectively the same issue where her macbook would "die", but only during video calls. We replaced it, then it happened again with the new one. A smart Apple tech eventually had her bring in everything on her desk and make a mockup video call in the store. The glitch happened when the magnetic cover she had curled up to use as a stand on her mini iPad (for her notes for the call) got a little too close to the latch sensor.
I'm proud to say I managed to diagnose a similar issue over the phone. Employee called the Help Desk saying her screen would go black when she tried to sign in. When she finished entering her password and clicked the button on the trackpad the computer screen would suddenly go black. She said she had to start up the computer after each incident. She also noted that it didn't happen consistently, just some days.
During troubleshooting we clarified that the computer was not shutting down; the login window appeared immediately if she pressed the power button gently instead of holding it down. She also allowed that the unexpected sleep was not only at login, but could happen any time if she got past the login window. And she could work around the problem by using a USB keyboard.
The culprit was a magnetic bracelet that she wore only occasionally. First thing in the morning she would try to log in to the laptop, without the USB keyboard, and her wrist got close enough to trigger the sleep-when-lid-closed setting. I heard the bracelet jangle on the phone, and guessed correctly that it might be a magnet.
This was my second encounter with this problem. The first time was when a laptop on my workbench died unexpectedly during troubleshooting and would not start up. It was stacked on top of another of the same model, and the lid of the laptop underneath was triggering sleep-on-closed-lid setting of the laptop on top.
Fast forward to a few weeks ago. I diagnosed a similar problem in 5 seconds while walking through the office. Laptop sleep was being triggered by an employee's new Apple watch.
It might take hours or days to figure out a problem the first time you encounter it. The second time is a memory test. The third time you look like a genius.
Lots of fun with those sensors. Some years ago, I think while I was migrating from an older laptop to a new one, the new one would randomly to to sleep. It took me a while to figure out why: Being really short on available desk space, I had stacked the new machine (lid open) atop the old one (lid closed). Of course that tricked the lid sensors into thinking the lid was down. I could kick myself …
To be pedantic MBAs do have cpu fans so there is one moving part. It's tiny and hard to know it is there, but it definitely is. The now discontinued 12 inch MacBook was truly fanless.
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.
We had a similar one when I worked for a large supermarket chain. We had one store that their In-Store Processor (ISP), which was a big IBM 6F1 RS/6000 box (about the size and looks of a large mini-fridge) was plagued with all kinds of weird and sporadic errors. Code that works fine in the rest of the chain would only sometimes work there, all kinds of disk errors, slowness, etc. We sent technicians to the store multiple times and they could never figure out the issue, we even swapped out most of the hardware.
Eventually, we discovered that the young girl that was responsible for changing all the prices was using the server room as her makeshift office. She would stick all her magnetic clipboards with the upcoming price changes to the side of the server. When she heard the tech was coming she would clear out all her stuff since she knew no one was supposed to be in there. The magnets were wreaking havoc on the disks causing the errors. The store manager got her some proper office space and the errors went away.
Re: " someone wrote a program to swing the heads on one of those old giant hard drives back and forth. At the right frequency...cause the drive to walk away"
On some TRS-80 models I discovered a certain POKE command would make the screen flash, click, and "bounce" the image, similar to a power spike. So in the university lab I wrote up a small BASIC script with a delay timer to repeat "DANGER: Computer Overheating!" as the clicking/flickering increased in rate. I stood back to watch and waited for the timer to kick in. Nearby students would freak out. When the script was done, it deleted itself in case they got the lab assistant to come over. I was a stinker.
That was the port that switched the screen from 64 columns to 32. A different bit in the port also controlled a physical relay that was used to switch the cassette tape recorder on and off. Toggling the pair together quickly did indeed look and sound quite dramatic - and would probably knacker the relay if left for long enough.
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
With the risk of sounding a bit arrogant, am I the only one who immediately thought about a timeout issue on the first description of the problem?
As a fan of online gaming I'm painfully aware that ping (and distance to server) matter. Especially when I was in Japan and tried to play with my friends in Germany, the fact that packets were routed over the US to Europe resulting in ~250ms pings was a constant annoyance.
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?
At university, we once built a networked doorbell system for the offices. Lots of small displays with a button outside the doors, connected on a CAN bus to a controller, that you could configure, and another device in the office to make noise and control the screen.
We had a problem, though: The door display devices would randomly crash and require somebody to go over and reboot them. This was very annoying, and we could never reproduce it. We added monitoring for it, and after a while the problem mostly went away on its own. But half a year later, it was back. It seems the system worked fine in summer, but started crashing in winter.
We finally, after much testing and deliberation, realised it was caused by the devices having a metal front plate which would easily attract static shocks, which would crash the device. And in winter, the dry air and wooly clothing would cause a lot more static discharges.
I have a similar issue with my desktop computer: when I suspend or hibernate it, it sometimes wakes up again when I'm standing, getting up from my chair or leaving the room. This also occasionally happens (when hibernated) after I have physically switched off the power of the computer and switch it on again. The issue occurred first a few years after I bought it, but right now I have just given up debugging it, as I have absolutely no idea what the cause could be. It's mildly annoying sometimes as I have to check that it's really staying put, but I can deal with it.
If you have a nicer mouse with a quality sensor, a pretty slight bump or vibration to the desk can cause it to move and wake the computer. Try disabling wake on mouse so you can only wake with the keyboard.
Yup. I puzzled over this one for a while when it happened to me. My mouse was on a pull-out surface from the desk and thus any vibration was amplified. It was sensitive enough to wake the computer merely from walking up to it.
A very simple version of this: I used to find that my macbook was randomly going to sleep all the time when I was working with it. Eventually realized that it was because I was using my ipad pro right next to it, with its very strong magnets for the smart keyboard---and magnetic sensors are also how the macbook tells the screen is closed. Could probably put one to sleep by just waving a sufficiently strong magnet in front of it...
Depending on how it's configured to wake, my guess is it's your mouse. When you stand you move the desk just enough to cause the mouse to wake it. Happens to me all the time when I bump by desk when getting out of my chair.
Useful tip: carry a metal object (keys, soda can) with you. Grab it with as much surface area as possible (holding the twisting part of the key, or the whole of the can) and use the tip of the key or lid of the can to touch metal. Because you've spread out your contact over a much larger area, you won't feel the shock. You can use this to get some really impressive sparks - I've gotten as much as 5-6 mm long.
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.
it happens to me all the time with a colleague that sits in front of me. every time he stand up, my monitor start glitching.
i found that cause a couple of weeks ago, and now i find it hilarious
> Turns out that some joker pulled out two keys from the keyboard and switched their places. [...] They were both relatively good at typing and didn't look down at the keyboard when typing when sitting. But typing when standing is something they weren't used to and had to look down at the keyboard which made them press the wrong keys.
Once in college, somebody thought they'd be clever and remove all the keytops on the only CRT in one small timesharing computer lab. Didn't bother me, because I was a touch typist - didn't need to see the keys at all.
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.
>Q: I have saved the result table from admensa into .csv format. However I am not able to open in excel. It is said that SYLK: file format is not valid. Do you have any experience on it? Thanks.
>A: This is an Excel 'feature.' I would guess that the first column of your data is entitled "ID". For some reason, Excel interprets any CSV file beginning with "ID" as an SYLK format file (not really sure what that is!). If you edit the file in, say, Notepad and change the name of the first column in the header row, you should find that it will load without a problem.
>This will happen if you save a CSV file from any application with the first characters "ID". So, unfortunately, there's not much we can do about it, other than to recommend that users don't call their first column "ID"!
Excel actually mostly ignores the extension and relies on heuristics to detect the file type on load. Many web applications used to implement "XLS export" by writing out CSV file with .xls extension.
This magic detection of file type has one unfortunate side effect: it is not exactly obvious how to convince Excel to load plain text data that is not CSV with delimiters from the current locale. (which is major PITA with most European locales where Excel uses "Semicolon"-SV and not "Comma"-SV but still calls it CSV)
You’ll have to excuse me because I’m not in front of a windows computer right now, but if you open excel first, there is a data tab on the ribbon and an import data wizard or something like that and you can tell it what the delimiter is. You can also apply types to columns and whatnot before importing. Not the quickest but does help extract the data.
The lack of this feature pushed a lot of scientists to OpenOffice/LibreOffice Calc. At first, just to open the file and "Save as Excel", but of course, then they start using Calc.
(At least that's my experience writing scientific software in Europe. Excel localized not just display, but the input and output. With Calc you could just open a file as "pipe separated UTF-8" and be done with it.)
If you rename your .csv as .txt then you get a wizard where you can choose delimiters, etc. This works in Excel 2000. I don't have an older version to hand.
I'm aware of that. But that is also partly my point, before ribbon there was 'File->Import...' which did essentially the same thing but at least for me (and many users I work with) was more discoverable.
Another thing is that LO Calc will present you with text import dialog when you open anything vaguely text like and also when you paste multiline plain text from clipboard.
Oh yeah, I got bitten by that. Turns out that MS Office files are zip-compressed xml files. Well I didn't know that, and the files were named something like data.csv, so that left me confused until a coworker told me what's up.
Yeah, those idiots! They buy something from Apple, and then find it doesn't work. What did they expect.
This, of course, is passive-aggressive snark. Suffice to say that I disagree with you; why shouldn't people expect software they buy from Apple to work? People buy from Apple because they don't want to have to deal with all this sort of crap; they just want it to work.
Steve Jobs originally wanted to strip out the shell entirely and only support POSIX at the level of the C API. To this day, Apple acts like they've been strong-armed into providing support for the Unix utilities.
I can understand the attitude that 99% of their userbase will never touch the command line, but that last 1% represents the developers that keep the whole ecosystem going.
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?
Presumably OpenOffice could pass along a thing that says "please print this PostScript file" so that the printer software knows which type of file it is printing and doesn't have to guess with "file". OpenOffice knows what type of file it's outputting, after all.
But your point arguably stands: if a user says "print file X", and you want different files printed using different logic (e.g. PDFs and PostScript files should be printed differently than text files), what other option is there other than using something like "file" to try and guess the file type? It would be very annoying for the user to have to specify each time from a massive list of possible optins.
I think the issue here is the question that should be being asked is: "is this a postscript file?". `file` answers a different question, "what is the most likely type for this file?"
In most cases, you can't print plaintext easily to a printer, it needs some format like PS, so your PS file would be converted into a PS script that outputs your PS file.
I'm fairly certain (minus Linefeed Printers of the old days) most modern printers are either Host-rendered (ie, the host renders text and tells the printer what to print) or use something like PCL, which even in the most plaintext mode, still requires some setup to describe and format the page.
You can't just pipe a textfile into printer port and hope your printer spits out anything useful.
I'm not sure if there's a different process involved here, but I vaguely remember that a recent network printer I had came with an ftp server that could be used to print, simply by dropping supported files into it. I never experimented with it, though, so I have no idea if it supported simple text files or required PostScript or some such.
I remember the bad old days of only 10-20 years ago when it wasn't unheard of to send a document to the printer, then walk over to discover a zillion pages of plain text starting with %!PS-Adobe-3.0.
Well, the true UNIX philosophy is that everything is a text file ...
.. but as one of the other comments says, programs which want specific interpretation should consider having their own heuristics, especially including "precedence". In the Excel example, it should be considering XLS and CSV first before trying other things.
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...)
Well one advantage of the "file extension" mechanism is that it is the stupidest thing that will work [0]. It's just like having a type code only it is embedded in the file name so it doesn't require any special features from any filesystem.
[0] Actually, UNIX's "everybody just guess" mechanism is probably the stupidest, but it is so stupid I didn't even consider it.
Yes sure, it can always be attached somehow. But even if used everywhere it has it's limits and ambiguities, e.g. when dealing with .jpg vs. .jpeg, .yml vs. .yaml and so on... It gets even more interesting when Editors create a temporary file by adding a prefix or suffix, or git/a package manager creates an additional file for conflict resolution.
Actually the user was able to solve it because it was in a shell script. If the program had used libfile instead, there would be no easy way to edit it to change the date format other than recompiling it. They would have needed to wait until the maintainers fixed file itself.
using file is a bad idea anyway... you can't rely on a command that performs guesswork (aka "smart"). It's been a cause of security holes in similar contexts (browsers sniffing mime type from file content/extensions)
Duck Tape is the brand name of the original product. "Duct tape" is the generic name that the industry settled on.
("Duck" refers to the water-resistant nature of the tape. Duct doesn't actually mean anything other than sounding like "duck". Ironically, duct tape is the wrong type of tape to use on heating ducts.)
If you're going to be pedantic, then get it right. ;-)
Reading Wikipedia's article has me questioning the information in my above post.
According to Wikipedia, the name comes from it being manufactured from "cotton duck" (not because water rolls off it like a duck). Then a derived product became popular for wrapping air ducts, and the name evolved to duct tape. Then someone trademarked "Duck Tape" and revived the old name.
I'm not sure anymore about the true origins of the terms, but I still maintain that "duck tape" and "duct tape" are both acceptable names (trademark issues aside).
Wow, I always thought it was duct tape because it was originally made for taping ducts. And that duck tape was just a brand name like gorilla glue. Thanks for that.
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.
I once worked with a guy who had been a computer tech early in his career. He told a story of moving a computer on a military base up one floor. After the move, the tape drive stopped working - it would glitch every few seconds. He tried everything he could to diagnose the problem. Then one moment while deep in thought he wandered over to the nearest window, where he saw a radar antenna sweep around. Sure enough, the glitches were occurring when the antenna was pointed his direction. The location on the lower floor didn't have direct line-of-sight to the antenna.
A friend's company routed a microwave link through an open plan office in a taller building. It worked fine until the third party remodelled their office.
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...
ResEdit was the apple program that could change it. Unfortunately, I don't remember off the top of my head if it shipped with the system or only with some of the developer tools. I _think_ early versions had it.
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.
We had a bug that would pop up only when we weren't working (at lunch breaks, meetings etc) but when we were at our desks it never reproduces. It ended up related to the screen saver starting up. It took us too long to find that out but that was a very good laugh.
Monday-only bugs and similar are not unlikely with code dealing with weekday ordinals, when moving between locales with different conventions (is Monday or Sunday the first day of the week?). Or can cause any number of confusions if different bits of code make different assumptions.
I'm not sure why that would affect something like webpack though (unless the problem was specific to a date manipulation library).
Edit: spotted the post that arrived as I typed the above. Looks like an advertising related function that only ran once per week using something not available on all sorted OS builds for that code, so not a locale related problem. Advertising causing unexpected problems yet again!
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.
I used to work as a Network Admin at a big university in Cape Town years back, and one of the urban legends at the time (late '90s) was that one of the long distance wireless (microwave? Line of sight required) network links were reported to drop every day at the exact same time for a a few minutes only. Lots of hours of troubleshooting hardware etc. later, and still no solution. Eventually a site-visit was done at both sides of the link, binoculars entow. The problem? The line of sight was going dangerously close to the top of a hill where a farmer had led his cattle every day at the same time. The cattle blocked the line of sight for 5 minutes every day.
No idea if this is true though.
Windows 3.1 16-bit multi-functional modules app i.e. skeleton app which loaded multiple DLLs one for each type of functionality. When printing on a dot-matrix printer everything would work fine. However when printing on a (then new) Laser printer the entire system would hang randomly. Didn't matter which module was the initiator. Spent 2 weeks poring over the code in our common DLL used for printing and found nothing. Then started checking rest of the code in each module and found it. Each module called into the common "print dll" to print its graphs. On return back it would call a local function to print the "graph legends" and thats where the problem was. The last line of this function called "ReleaseDC" but the parameters "hWnd" and "hDC" were switched by mistake so Windows released some unexpected memory giving rise to the problem. This code was cut and pasted into each module with minor modifications and therefore existed in all the functional modules.
I had an intermittent printer issue recently. As a Mac user I have to submit jobs to the University printers via a web portal. I try to print very little so it’s not something I use a lot, however I end up printing large numbers of midterm scripts every semester.
On occasion I would log into the portal, upload my file and select the printer and it would tell me the file was printed. However when I went to the printer there were no jobs to be seen. IT insisted that my files were somehow corrupt but eventually they sent someone over to see my issue and they too were stumped.
Finally they logged the server side activity of my printer interaction and they noticed that there was a space appended to my username, presumably by iCloud Keychain and the behaviour was possibly changing between OS updates.
The web portal would let me log in, the server managed the files but the printer would ignore the job all because of that space.
The heuristic was _supposed_ to be checking for the full string "Tue Jan 22 14:32:44 MET 1991", but the bug was that the spaces weren't escaped in that string, and only "Tue" was checked for.
The proper heuristic seems odd but reasonable to me.
I love these debug stories. My interesting one was from a job repairing computers in high school.
My older colleague was upgrading a 486, and couldn't get the system to boot on the first try, but if you hit the reset button after it was already on then it would boot just fine. All the hardware tested fine in other systems.
I figured out the problem by listening to the hard drive. I could tell it wasn't spinning at full speed when it was initially booting. The system would get through the POST process before the hard drive could finish spinning up. So the initial boot from power-off would fail.
The solution ended up being to upgrade the hard drive (or downgrade the motherboard).
I once spent quite a long time tracking down a bug that would only occur if the time between 10:00 and 12:59 because of the extra character that occurred in the date formatting, leading to an unexpected line wrap that led to a lookup bug later on during a session.
If I'd known that time of day was the variable causing the behavior change, it would have been fairly easy to resolve—but that wasn't the case. Instead it was only resolved by the large-scale collection of failure and success cases coupled with the careful correlation of bytes sent & received across an entire session.
So the check for Erlang magic numbers ended up being passed before the _existing_ checks for other file types? Nice bit of pushing in, there.
Still, it was accepted by the "file" devs . . . .
Looking at the patch (http://launchpadlibrarian.net/27497360/hardy.diff), the issue was that the string "Tue Jan 22 14:32:44 MET 1991" is matched to check for an Erlang file, which seems weird but reasonable. The bug is that the spaces weren't escaped in the string, so it was only looking for "Tue" instead of the full string.
File should detect all possible file types, there is no reason to detect only the first one... It should not be used as a file type detection anyway if you want a reliable system.
I now suspect he made it up for devious reasons, but I had a professor who told about the time random characters and cursor movements kept appearing during data input from a lady at a remote office at his org.
Phone support couldn't solve the problem after many tries, including asking her to try a different work-station. So they flew in a technician. The technician arrived and sat to observe the lady as she did data entry. The technician eventually realized her rather large breasts were bumping the keyboard from time to time.
I've only had issues with the software for school in the nights before I had to submit work.
For exemple, I recently had to give back a work on matlab.
And at 9 pm it didn't show up in the windows menu.
So I tried to run the installer that was too long, until I found out you had to use a flash drive.
Then it returned a lot of errors saying I didn't have the modules.
And I have the same issue with every damn software.
when i got the computer for the first time , there was mcafee antivirus that came with it, i scanned the PC and found a virus, i was shattered and cheated by the computer seller as i thought it would damage the PC and i wont be able to use it ever again.I'm a software engineer now
If you think the heuristics in "file" are sometimes a bit scary, take a look at how PC hardware used to work back before the PCI bus become dominant. The heuristics there ended up bricking two expensive motherboards for me.
The older ISA bus, which was quite common until at least the end of the '90s, did not have any way standard way for software to identify cards, nor any way for software to specifically talk to the card in a specific slot.
PCI cards have a required Vendor ID assigned by the PCI-SIG, and a Device ID assigned by the vendor, and the PCI bus has a way to address by slot. A driver that supports a particular kind of card can scan the bus by slot, checking Vendor ID and Device ID to find cards it works with.
With ISA cards, all that driver would know is that the card it is looking for has, say, 4 registers that appear at consecutive I/O addresses, and that there are jumpers on the card that can set the base I/O address to 0x200, 0x240, 0x280, or 0x2CO.
The safe way to use a card was to install it in the PC, noting the jumper settings, and then install the driver and tell the driver what jumper settings you used. To know what jumper settings to use, you had to know what other cards were in the system and what I/O addresses they used so you could pick settings that didn't conflict with an existing card.
No one wanted to make someone installing a new operating system on a working system open up the thing, find all the settings on all the cards, and report that to the OS. They wanted to just automatically work with cards that had drivers built-in to the OS.
So what the OS installer would do is go through each built-in card it supported, and use heuristics to figure out if it is installed. For example, take that card I mentioned earlier that can be at 0x200, 0x240, 0x280, or 0x2C0. The OS might now that after reset that card should have 0x1F in register 0, 0x00 in register 1, and random values in registers 2 and 3. So if it doesn't see 0x1F at 0x200, 0x240, 0x280, or 0x2C0, it knows that the card is not present.
But suppose there is 0x1F at 0x200 and 0x00 at 0x201. Then the card might be there. So now the driver would have to write to some of the registers, and see if the card responds the right way. Mostly it would do this be setting various modes, and then reading those mode settings, and see if they are right. If the card is not the right one, hopefully some of those commands don't make any sense to it, and so its responses are different.
Think about this for a moment. Suppose the OS is looking for a network controller, and the card at that address is actually a disk controller that happens to have the same read values in its registers after a reset, so the probe for the network card has to go on to the writing part of the test.
It's then writing network controller commands to a disk controller. If the command for "set status" on the network controller happens to be the same as the command for "write to disk" on the disk controller--you may have just trashed your disk. Oops.
And so the OS vendors had to very carefully construct their device probes. If writing commands for card X to different kind of card Y could trash things on Y, they needed to make sure that they had probed for Y first, and so if any Y were present skip them when probing for X.
Note that this doesn't necessarily work if you have any cards that the OS does not know about. If you card is going to need a third party driver installed after the OS is installed, it was best to take that card out during OS installation if having random junk written to it could cause harm.
One day at work, we bought two very expensive top of the line motherboards. The box said that they required Windows 98 or later. I tried to install Windows 95 on one of them. The install went fine until it got to one of the places where it reboots, and the reboot failed utterly. It did not even show the BIOS messages. The system appeared to be thoroughly bricked.
Figuring one of the motherboards was defective, I tried the other one. Same damn thing. Bricked during Windows 95 install!
We eventually found out what happened. The Windows 95 searching for devices on the ISA bus ended up writing to some registers that on this machine controller the BIOS flashing. It had erased the BIOS. Windows 98 and later knew about the flash controller in the chipset used in this motherboard, and avoiding trashing your BIOS. (Not sure why the motherboards either didn't have a jumper to disable BIOS flashing, or shipped with that jumper set to enabled).
i used to create virus on my school computer labs , a batch file with command to delete a critical windows file like ntldr.dll or somthing and restarts, then i rename it to fifa or GTA and put an icon of the game as well. someone from any other class when using the computer think they got a new game and click on it and it won't boot again. yeah , i was a bad kid
It kinda pisses me off that the second line of the body became a sexist joke phrase title in hacker news.
If you're not clued in on sexism: The stereotype reinforcement that women are dumb with technology is the punchline. It doesn't matter that there was actually an issue with the pipeline from OpenOffice -> Cups, but the hacker news title was cleverly crafted to reinforce a stereotype.
I don't care that this will be downvoted to oblivion, but the seeds of sexism exist everywhere.
In general I agree with you that "unconscious" sexism is common, but TFA is not an example. TFA describes a user who has accurately isolated the conditions that generate errors. That is a capable user.
Arguably, the title would be improved by adding the third sentence as well...
Don't take this the wrong way, but I think you're overthinking this.
I personally read it this morning and honestly it didn't register to me in the way you're describing at all. I did not use the title as a sexist joke as you're saying, nor did I think that his wife is "dumb" because she thought that something is wrong with OpenOffice. The joke (if there's one) is that there's a twist, which is that programmers expect the worst description from non-technical users when explaining bugs, and "something doesn't work on Tuesdays" sounds a little absurd at first (like most interesting bugs). But even if it had occurred to me, omitting it just for the sake of not having the potential negative connotation is even worse imho.
I haven't seen a single comment in this entire thread that addresses the issue as you're suggesting, not even hinting at it. Just because you thought that it could possibly have that implication doesn't mean that it actually does.
A while back I read a little theory that the reason "so easy your mom can use it" is a thing is that older men are less likely to experiment with new stuff in the first place than older women.
I have no evidence for this beyond second-hand anecdotes about who shows up to free computer education classes at their local library.
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).