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.

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.

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.

Save that a single human putting in actual effort can't turn out several dozen PRs a day, every day. That throttles the PR volume to a manageable level for the maintainers.

The answer is a simple "No.". Don't allow them. The vast majority will fail to meet reasonable criteria for acceptance, which is enough of a reason to reject them. For the rest, even if they're acceptable in terms of quality, the sheer cost of reviewing every pull request in detail and sorting the minority of acceptable requests from the swamp of slop will itself damage the project, diverting maintainer time away from feature work and fixing bugs, badly enough that it's not worth it. I think this sums it up nicely:

Why should I spend my time reading something you didn't care enough about to spend time writing?

Perhaps it's time to apply the same methods here that helped deal with spam back in the day: start threatening the ISPs that don't deal with users infected with proxies with having all netblocks belonging to them blocked unconditionally. That works by shifting the complaints from people the ISP doesn't get paid by (the services being scraped) to people it does (it's users who can't access services). We even have the tech needed already: DNS-based RBLs. Condemn providers who host scrapers who don't provide useful user-agent strings or don't comply with robots.txt to the same fate.

We don't need regulations to do this. The services belong to the people who run them, and they've got pretty much free rein to take actions to protect themselves. Is it severe? Yes. Is it disproportionate? Also yes. But then, to avoid it they just have to do one easy thing: not be assholes. If they can't manage that, are we obligated to shoulder the costs of letting them freely be assholes? IMO, no.

They don't. They think of them as something that happens on their computer, with only them involved. They know, in the abstract, that there's a server somewhere, but the implications of that don't really sink in. The same problems applied to e-mail since forever, but everyone dismissed it as something that didn't matter since they didn't use email. Now, though, we're seeing the result of the third-party doctrine starting to hit home in ways the average person does need to care about thanks to the ubiquity of the cloud. Chatbot logs, search histories, email records, Flock cameras, Ring doorbell cameras, ALPRs, documents stored in cloud services, social media histories, messaging service histories... everything involving records stored long-term in the hands of third parties is starting to affect ordinary people in ways they can't ignore. I suspect at some point the law is going to have to change.

They're still playing the "Try to get IBM to pay us to go away." game. It didn't work the first time around. This one's even more futile because this particular argument was dealt with during the original case and IBM proved that the code they contributed to Linux wasn't code belonging to Project Monterrey at all but completely different code IBM wrote themselves for a different product. But I suppose, given the people behind this, lack of pattern recognition skills is a given.

Didn't Amazon remove the mandatory arbitration clause a while back because too many users were using it, making Amazon have to spend too much money and time on arbitration? Or was that another large Internet vendor?

Inglis has obviously never read a single one of Asimov's robots stories, or he would never have uttered that statement. Every single story was about how the 3 Laws fail to work, often in ways that endanger humans.

Yes, as if nobody could feed some photos into a genAI chatbot and have it generate a video of that face performing those actions on command. Right, nobody could possibly do that, not in our lifetime... wait a minute, I'm getting an update from the studio...

The worst part isn't that now anyone who can get a few pictures of your face off the Internet can log in on your account. The worst part is that you can't recover from it. You can't change your face so once they've got it all you can do is disable this feature completely, and hope Google doesn't re-enable it.

"So, we tried the biggest node we could find but the die came out too small, we had to find a bigger process node to make it big enough we could handle it to fit it in the package and attach it."