If removing the battery requires an electrical current, it wouldn't be surprising if, in the future, Apple adds another layer of control, like requiring a digital signature to authorize battery removal
It can also be a good thing: given the EU's 2027 requirement for user-replaceable batteries, this could ensure the battery can only be changed if the phone isn’t stolen.
> Maybe I'm misunderstanding this. Do we have data on changing the battery of a stolen phone having any meaningful impact on people/society?
At least we know one boundary - in London, about 91k phones were stolen in 2022, of which a lot are expected to end up shipped to China [1] to be either parted out or its identifiers reflashed so that they can be re-sold. The true number is likely to be significantly higher, as not everyone is willing to go to the police and deal with the paperwork when someone snatched their older-issue phone on the subway when the police doesn't do shit anyway.
And the latter part is the problem. The UK could impose inspections on outgoing parcels, say to listen for Find My BTLE beacons, and China could impose the same kind of inspections on incoming parcels or shut down the companies buying up clearly stolen property. But UK politics are too busy embroiling themselves in bullshit scandals and China most likely actively wants to contribute to the growing sense of destabilisation in Western societies, so here we are.
Assume an average value of 300 € per stolen phone, and alone London's citizens and visitors experience 30 million € in damage from stolen phones alone. It's utter madness.
Parent was about "EU's 2027 requirement for user-replaceable batteries" and changing batteries on stolen phones. To be it still doesn't make sense.
Sure, stuff are stolen and resold, sometimes as part. I'm not denying it. Not sure how user-replaceable batteries will impact that in any meaningful way, especially if the world already has "Chinese criminal city for stolen phones". Do we really see an important amount of stolen batteries in lawfully owned and maintained phones to the point a DRM on batteries would benefit legit users?
Let's not assume DRM will reduce theft and criminal activities.
> Do we really see an important amount of stolen batteries in lawfully owned and maintained phones to the point a DRM on batteries would benefit legit users?
The stolen batteries have to end up somewhere and official spare part supplies are really expensive (unless you are a certified partner shop of a specific manufacturer of course), so it's most likely they end up distributed into the grey market.
If I were to decide upon a global regulation, I'd say that spare parts have to be made available under FRAND terms (so, no more preferential pricing) and all valuable components have to be reasonably e-marked, that there be a public global registry between device identifiers and associated component identifiers, and that when someone presents a proof-of-purchase plus a police report, all components get denylisted... and when a device recognizes a change in its parts, the component's identifier is checked against the global denylist. If there is a match, the device's user gets a warning, and the owner of the original device who made the theft entry gets a notification, let police do their job then.
I wonder if in the near future we all just share phones like you would a phone booth. Have devices everywhere or the capability on any device or anything electronic since it will be all wireless and connected anyway. You'd sign in via bio-metrics or some way to securely and uniquely identify yourself quickly.
How much data is on your phone? How much sensitive data is on there? Do you really want to wait to download all that crap, and run the risk of picking up a public phone that’s been set up to clone it all somewhere?
Since iOS 18 they added a software lock to parts previously linked to another iCloud Account. Currently you have to authenticate to the previous iCloud or you can "skip" this and the part will show as "third party" but I bet they'll lock usage soon.
Locking only if the part was reported as stolen would be a smart move. Any other reason sounds like a D move to improve business KPIs while hurting legit owners.
it does ask for permission, but a malicious website could ask it for a valid reason and then brick it, yup.
On the other side, a controller should not be brickable via HID commands...
Yes, that's the point! I suggest to try calibration in temporary mode (center calibration has a checkbox in the wizard). See with https://hardwaretester.com/gamepad if the controller is calibrated correctly, in that case redo calibration in permanent mode. That flashes the calibration in the controller.
Few years ago I bought a 12V led strip from aliexpress, it came with a usb charger.
A "12V" USB charger. You can easily guess who put it near other chargers by mistake and then fried a PS4 controller trying to charge it with that :/
The big idea is that usually the `else` will do a nonlocal exit, so we should try to rewrite this in the "flat/early-out style." But then if you're declaring intermediate variables, you end up with duplicate lines:
auto var = op;
if (!var.cond) return my_else;
auto var2 = op2(var);
if (!var2.another_cond) return my_else;
do more stuff;
There's this sort of very regular block in there, of "declare variable, test condition, nonlocal exit".
So the idea was to combine the `if (!var.cond) return my_else` into one expression-level location, so it turns out as
auto var = op? else return my_else;
auto var2 = op2(var)? else return my_else;
<do more stuff>
// Or instead
if (auto var = op?) {
auto var2 = var.op2?;
<do more stuff>
}
Then the question was, what's the best way to get both of those? And it occurred to me what I actually wanted was just a way to branch out of the if entirely, I didn't really care about preserving any values in the alternate case, I just wanted to tear the entire expression/scope down and do something else.
Yep, in an expression language that's how you'd do it. However, we're an imperative language, and the advantage of `else` is that we can use an imperative construct, `if()`, to locate the else case in the code - so we don't need to handle it in the typesystem. That's an inversion from monadic languages, where types contain/emulate statements - in C-likes, statements contain expressions/types! So `breakelse` effectively is glue that lets us turn part of the type into a control flow, which is deliberately not represented in the typesystem. `Optional.case(:else: breakelse).X` and now in X, we're no longer dealing with an `Optional` at all. We're not "inside" the Optional as we would be with `map`; we've effectively everted the entire `Optional` using non-local flow from the `else` case.
It seems so, but the catch being restricted to the else block of this exact if block means it's considerably less expensive than a regular exception. additionally, most of the time when doing operations covered by this, you wouldn't really care about the type of your supposed exception (ie why bother throwing a endoffileexception when you know you're going to catch it right there), so for this use case specifically this gives you a free pass to say "go to error handling, i don't care about naming things because this is all extremely local"
(Author) Yep, it's sort of like throw/catch at the expression level, but through a different mechanism that doesn't allow non-local unrolling. In exchange, it's a lot more performant.
I like I don't have to add names for things and it's perfectly easy to follow, plus I still get things that happen when going out of scope that wouldn't happen if I used a go-to, I found it brilliant! Great work!
Here's a tool that may help your friendly neighborhood 3d artist. Sometimes Maya crashes and the crash handler saves the project for you. Sometimes Maya gets frozen and you have to kill it from the Task Manager while crying because you just lost your work. If that ever happened to you, this tool is what saves your life: CTRL+Click on the frozen Maya and it shows (99% of the times :P) the crash handler, saving your project.
