When the west devolves into a low trust society because of things like this and the relentless importing of people from such, it will lose the advantage of being a high trust society. Equality for all!

I'd consider places with no school shootings higher trust than those with 300 school shootings every year :)

Sure, go for the cheap shot (heh) at the Americans - but the news article is from the UK.

I think we can reliably say that the global West's current lack of trust is nothing other than home-grown.

They didn't even get into the actual protection itself. It may well be terrible, but it being xcopy-able is not the protection vendor's fault.

I thought the newer LPDDR5 RAM was notorious for usually being soldered on / non removable? There's the new CAMM thing but adoption has been spotty.

CAMM is adopted by the more expensive business class laptops. I think Thinkpad P1 / X1E adopted them first.

Cards don't really need webhooks (unless you get into 3ds). Other payment types may need webhooks because they are fundamentally async.

3DS is a big deal in Europe, and card payments can be disputed. So I'd argue that credit cards are async, too, at least on some edges that can be expensive to ignore.

Because of PSD2 (regulating card payments in the EU), 3DS, including multi-factor authentication with an application or sms, are mandatory in the EU.

Per app isolation vs single user account.

There isn't that much demand for that on Linux because the apps aren't adversarial. If you install Facebook on your phone, you want it locked in a jail where it can't suck up everything on your device and send it to Meta. If you install the Signal desktop app on Linux, it's open source and doesn't do that. And to the extent that you use the likes of Facebook it's the web version.

Meanwhile per-app isolation is a pain. You download a picture in a browser, crop it in a photo editor and attach it to an email. All three apps need access to the same picture. Your backup app needs access to everything. Your password manager is filling in fields in other apps.

You do want to be able to isolate something questionable, but the usual way to do this for sophisticated users is virtual machines or containers. Maybe that could use a coat of paint to make it easier for unsophisticated users to use it, but maybe unsophisticated users should just stick to the system package manager anyway.

> You download a picture in a browser, crop it in a photo editor and attach it to an email. All three apps need access to the same picture. Your backup app needs access to everything.

On Android, each of those three apps would ask you for file system permissions on first launch. Your choices are "full access to user files", "limited access" (usually one directory and all its sub-directories), "full access, but only this time", and "no access".

Both the "save file as" and the "open file" dialog only show directories the app can access, and have a button at the top that reads something like "change storage scope" or "allow more access".

The system even has options where apps can request access to e.g. all photo/video/media directories - the photo editor would probably request only those to begin with.

Also, apps can pretty much never access each others config/keys/etc files - which they never should. If they need to communicate with each other, they're supposed to use interfaces like the Content Provider, Intents or Bound Services.

I think it's pretty well designed.

> On Android, each of those three apps would ask you for file system permissions on first launch. Your choices are "full access to user files", "limited access" (usually one directory and all its sub-directories), "full access, but only this time", and "no access".

Which isn't completely useless, but in most cases the only thing you really want is "full access" or "I don't actually trust this thing" -- and most users aren't going to comprehend the difference between more fine-grained alternatives anyway -- and then you're basically looking at the distinction between normal trusted apps and something you run in a container.

> Also, apps can pretty much never access each others config/keys/etc files - which they never should.

And that's the problem, because the backup app is supposed to be able to back up everything, a malware scanner can't have potentially malicious apps hiding something from it, etc.

On die ECC for DDR5. Which corrects locally but does not signal the host or deal with data between the die and the CPU.

Presumably this is being marketed indistinguishably from regular ECC RAM?

If so, that's terrible news. It was already difficult enough to find ECC RAM for "workstation" class machines (i.e.: High end, non-server CPUs that support ECC such as AMD Threadripper).

It's not - ECC RAM still means real, between the RAM and CPU ECC. It's literally an extra 8 bits per channels, for an extra 16 bits per dim. 40 bits vs 32.

Thanks, drove me bananas trying to find that again.

All the more reason to avoid the fate of the Native Americans.

You could argue that they are ruining the value of the signal for everyone.

If it was about signal-to-noise, there would be no bullying of bald people, or short people.

Or it could still be, but have other explanation. E.g. you're called out if you ruin the signal to noise ration, but you're also called out if you genuinely give the unfit signal.

(Don't approve doing this or anything, just pointing the blind spot in your dichotomy, interested in the argument on a purely technical manner).

HN never ceases to surprise me with the rationalizations for any kind of behavior.

Nope. I'm using it correctly. You might be in denial, though ;)

...when given a 2 year head start.

> Literally, I have not changed my Google password in ~10 years, and my GMail is still untouched.

The flip side of this is how many people are wrongly locked out of their gmail. I bet there's quite a few of them that failed to satisfy whatever filters Google put in place.