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).
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 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.
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.
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.
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.
Yeah, I am sensible to some sound :/.
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.
HR also offered her a free hearing assesment. It was a semi-state co so they actually cared for their staff.
Hmm, doesn't sound like she needed it. Maybe only to figure out if her hearing was better than normal.
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.
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
- screenshot someone's desktop
- set the background to the screenshot
- iconify all the apps
They'll click around in increasing panic on the "apps" on the background, before they realize what happened :)
Not that this ever happened to me, of course. I'd never fall for it again.
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 :)
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.
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.
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.
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.
>Fix: install window shutters.
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.)
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.
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.
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
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!
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.
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.
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.
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.
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.
Edit: And the FAQ: https://www.ibiblio.org/harris/500milemail-faq.html
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.
EDIT: Never mind, answered in the FAQ.
Also, some reddit makes it seem like a Titanium pin in his shoulder was to blame: https://www.reddit.com/r/techsupport/comments/2rsivw/monitor...
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.
The magnet in the lid of the bottom laptop would put the top laptop to sleep.
It never happens anywhere else, so it must be something about the office carpet, and maybe inadaqute earthing of the desks or something.
But every single time I wear those boots to work I will shock myself a dozen or more times that day.
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.
SPOILER: its the gas compression in the shockabsorber causing an EM spike or something like that.
Not as interesting as initially hoped for :D
- "The Case of the 500-mile email" https://www.ibiblio.org/harris/500milemail.html
- Brendan Gregg demonstrates the effect of screaming at hard drives: https://youtu.be/tDacjrSCeq4
EDIT: Well file really had a bug in this case, where they didn't detect what they thought they were, but the point stands.
But who would EVER think of naming the first column of a spreadsheet "ID"?
>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"!
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)
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.)
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.
I particularly relish the way it identifies macOS disk image files as VAX executables. I hope they never change that.
Apple routinely don't update the Unix utilities for a decade...
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.
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.
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.
You can't just pipe a textfile into printer port and hope your printer spits out anything useful.
.. 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.
 Actually, UNIX's "everybody just guess" mechanism is probably the stupidest, but it is so stupid I didn't even consider it.
That's a fascinatingly apt mixed metaphor: duct taping meets duck typing.
("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. ;-)
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).
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 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...
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.
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.
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.
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).
Fixing the bug by properly escaping the string that matches the special file still sounds like the wrong solution to me.
I wrote about it here: https://agateau.com/2012/qt-image-decoders-stepping-on-each-...
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.
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 was somewhat proud of solving this :-)
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.
1. Speech Recognition typing random garbage - user claims to be hacked.
2. Ambient light sensor on laptop turns off screen - user says my computer works at home but not at the office.
3. Set email background and font to white - user says he can't type new emails but can type replies.
The proper heuristic seems odd but reasonable to me.
diff for reference: http://launchpadlibrarian.net/27497360/hardy.diff
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).
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.
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.
Any news since?
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.
What should I do ?
2. Run the program and attach a debugger
3. Set up watchers for the object
4. Watch the world burn for your profiler :)
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).
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.
Arguably, the title would be improved by adding the third sentence as well...
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.
I have no evidence for this beyond second-hand anecdotes about who shows up to free computer education classes at their local library.