The thing to look for is how they go about solving a problem. That's the key. Coding is easy. Figuring out what the problem is and how to go about solving it, that's the hard part. Especially given that the problem the user says they need solved is often not the problem they actually have.

"Meanwhile even questioning if the earth is flat will have you downmodded to (-1) Troll."

What you might as well have said.

Grade homework on completion and be done with it. Then schedule in-class quizzes and exams, where students are expected to show their work as well as the results and do it hand-written. That makes it hard to access chatbots, and even if students do the drudgery of transcribing the chatbot's output will discourage them (if they were willing to do that much work, they wouldn't be trying to skip the work using a chatbot). They may skate by on the homework, but the exam scores will show whether they actually learned the material or not.

They really humiliated all the traditional supercar brands out there.

Uh, what?

Sure, go far back enough (and yes, I was on computers at that time) but surely he's not saying, "Man, computers were better when you could only run one process at a time, and the operating system let you do literally anything" etc etc and if so, the answer to that is, you can still do that if you want .. you just can't do it *inside* somebody else's software architecture. You still own the hardware, do whatever you want.

huh? it's trivial to write any code you want and run it on your phone

But with respect to your "dawn of the PC era", unless you wrote the operating system, you couldn't write and run code that could do anything and everything your computer was capable of - only code that could do what the operating system would permit you to do.

That's no different today.

Volume over time. Git is designed to allow offline work, so each working copy has it's own repository you commit to. With a monorepo that's a lot of history that isn't being used by any one agent working in only part of the code. So they uninvented Git, removing the "enable off-line work without a connection to a master repository" requirement. Which put them back at the requirements that spawned Subversion. And proceeded to re-implement Subversion. Badly.

Here's a little sticker for knowing what Firefox is tho. You must be good at computers.

There have been numerous articles about it recently. You have the internet. No need to stop the class just because you're the only lazy ignoramus around here.

I mean, come on. The freezers are on the Internet, no firewalls, fully accessible to anyone with a browser. Their "security" consists of rotating the admin password daily... to the current date. There are guppies out there that could gain access to these. The root cause here is willful negligence by the retailer's IT department.

The way you deal with Flock and their cameras is that you tell them you are terminating your contract with them and will be remitting payment for the remainder of the contract term. They have 30 days to remove the cameras from your property or arrange for removal. If the cameras aren't removed, you will remove them and store them at Flock's expense until Flock comes to pick them up or makes arrangements for pick-up.

Then you send them their money and, if the cameras are still there after 30 days, take 'em down and put them in storage. The cameras may belong to Flock, but it's still your property they're mounted on and Flock no longer has any right to have their stuff on your property. Don't argue with them, don't get into a debate with them, just do as you said you'd do. Sure they could take you to court, but seeing as they've received all the money they'd've been entitled to and their property is sitting there nice and undamaged waiting for them to come get it the court's going to ask why their case shouldn't be dismissed for failure to state a claim.

No, if you read it says that read performance is pretty much equal to uncompressed DRAM so you don't have to take a latency penalty.

you're an old and bitter man, and you've only yourself to blame

and I'm old too and a loooong time c++ professional dev (and still am) and somehow the idea of change or the word 'Rust' doesn't make me shit my pants

I feel bad for you

Those "very special" use cases are actually fairly common. I routinely deal with data structures in software I write that are read-mostly: large data tables that are accessed in the inner loop (so need fast access) but whose data is updated infrequently (anywhere from minutes to days between changes, and often the changes are in batches so many changes can be applied in one operation). Being able to put them in compressed memory would free up a lot of normal memory for things that do actively change, which would speed up the application noticeably.

I don't think CRAM is a solution to the current memory price crunch, but it's certainly an interesting idea. The Redis cache software, for example, would probably benefit highly from higher capacity. And of course the same techniques can be adapted to flash/SSD drives where the memory itself isn't necessarily the speed bottleneck.

Patents, buddy. Developers know things better than you do. Plus other reasons, but I suspect you'll just handwave them all away because you're very very smart. It's definitely not vastly better than JPEG XL.