Except it's all just goofy as hell. There's no solid proof that 5G is going to cause a problem.

You know how you can tell? Because if it were ACTUALLY going to cause a problem, they'd "protect" more than just 50 airports. They'd also do it for more than just 6 months. You don't just say, "Hey, let's run an experiment with a bunch of small and medium airports around the country and see if it kills people." The radio waves aren't going to change by July. Physics will be the same.

It's not like this isn't testable. You set up an altimeter and you put it near a 5G transmitter. You see how the instrument reacts. You recreate estimated real-world scenarios. You create freaky-stupid worst-case scenarios of the same type that lead nutritionists to saying you really shouldn't eat 12 crates of bananas in a day.

If you can show that the 5G transmitters are going to break the altimeters, then it's really simple. No one takes the chance, you change the configuration of the new mobile technology. No one wants to crash airplanes. The phone companies are evil, but they fly in planes too.

I haven't read yet where this voodoo BS came from, but that's all it is. It's pseudoscientific crud. And you can tell it is based on how they're actually treating it.

Yes, but if you're trying to copy text out of a context that isn't editable (say, a web page), then you don't have access to the keyboard.

Exactly this. I knew a guy who worked for IBM Global Services and then later got a job with EMC Professional Services. He worked both jobs (poorly) for 3 months until both jobs asked him to be on-site at the same time (in different states), and then he quit the IBM job.

It's unethical as all get out, regardless of whether or not it's legal.

I applaud these guys for their research, but the number of scenarios in which this is relevant is super super small.
For even a semi-experienced person, picking a simple tumbler lock is a 3-10 minute operation. For a really experienced person, it's a good deal faster.
Then there's bump keys.
And lock rake guns.
And going under/over the door.
But sure, with this, you can walk up with 3 potential keys and about 5-20 seconds after stepping up, you're in the door.
You just need a high-quality recording of the key being used in the door. However, the number of times when you can get that recording, but you can't just get a quick photo of the key are pretty few and far between.
Plus you need a 3D printer and the know-how to use it (this is getting more common all the time, of course).
Basically, if someone needs to be ninja-like enough to make use of this method, both from a timing and effort standpoint, then you probably already should have upgraded that lock to something other than a simple pin tumbler setup.

Still, it is super neat.

There are stories from multiple friends of his that he could do something that most of us just _cannot_ do. He could write (type) and carry on a conversation at the same time. In fact, he apparently loved doing it. He'd call friends up on the phone and have hours-long conversations with them, and the entire time be noisily (and rapidly) banging away at his typewriter.
For me (and almost everyone), those two parts of the brain just refuse to fire up and run at the same time. Dr. Asimov was a special sort.

They pay people a hell of a lot more than that to do middle-management work.

To be fair... it does make some sense that these two things would chase each other around in circles.

I just patched an SAP server last week that hadn't been offline since early 2010.

I wasn't patching SAP.

No awareness of timezones whatsoever.

It's going to be 6:30 in California, people!

Sheesh, if you want people to watch your announcement live, you need to schedule it when as many folks as possible are AWAKE.

Thin provisioning doesn't fix this problem. At least not today.

The only way thin provisioning fixes this problem is if you over-commit the thin pool. That's all well and good, but currently, any given storage chunk that is allocated to a server is stuck being allocated to that server. So, if I were a server admin who found out he'd been given thin LUNs in an over-commited pool, I know that if my neighboring admins don't keep track of their storage use, then my server could wind up crashing because they took up all the storage. So instead, I'm going to write a script first thing when I get the storage to write a text file clear across the drive. There. Now my disk is fully provisioned, and my neighbors can use all the pool they want, it won't affect me. 'course, not everyone can do that, or the pool will fill up lickety split.

Now, someday, the servers will be smart enough to tell the storage array when they're done with a chunk of storage. At which point, that part of the pool can be freed up. When that happens (and it will, but it's going to take some time), thin pools will be ideal. Everyone will have all the storage they need almost all of the time.

However, that day isn't here yet. In the mean time, there are interesting performance reasons to use thin provisioning, but not space-related ones.

We did this ages and ages ago. I graduated high school in '94, and we didn't have D grades then, and they still don't have them now in any district I know of.