Back in the 2010s, yes, not anymore though afaik, I assume that CDNs/traffic got cheap enough to not go that far. Microsoft actually introduced P2P update sharing with Windows Update for Windows 10, I think it's enabled by default.
Which is more powerful than any game genie by a great amount, with its included debugging tools - really not just useful for games, but in general for all sorts of RE on Windows. Sadly only on Windows, I've always hoped that maybe they would add support for GDB stubs some time - there is a remote mode already, afaik.
It's also surprisingly all written in Pascal(or Free Pascal) which is actually a pretty pleasant language(even if not very popular anymore), if anyone's ever curious: https://github.com/cheat-engine/cheat-engine
A company that cares about eroding trust in third-party repairs shops getting blamed for ripping off their customers when the battery still reports as broken.
It’s not reporting as broken; it’s just reporting as “not our problem if it fails.”
The Right-to-Repair discussion often ignores a key problem companies have: figuring out whether a device is under warranty (i.e. whether they’re obligated to repair the device for free) when it’s submitted for repair.
Some repairs make themselves obvious, and so make the removal of warranty obligation obvious. Other repairs—like third-party battery replacements, done following the Apple process for repair and with Apple OEM components—make the warranty status of the device illegible. If the phone accepted a new Apple OEM battery without saying anything about it, the user might be misled into thinking that the device is still under warranty. But it’s not. It’s been repaired by a non-authorized third-party. It’s no longer Apple’s fault if the device breaks, because that third party may have screwed things up inside the device in any number of ways.
This is, in a sense, a “chain of trust” thing. It’s the same reason Chromebooks have that on-boot warning in development mode. The user needs to be aware that the chain of trust between the OEM and the end-user has been broken; and that, when that happens, anything may potentially have been done to the device.
That’s not to argue against Right-to-Repair. Non-authorized third-party repair shops should have every right to operate as businesses, and end-users should have every right to do business with them. But Apple also should have every right to warn users that the chain of trust has been broken—because it has. The user knowingly broke it themselves! (And, of course, Apple shouldn’t have the right to misconstrue breaking the chain of trust as anything more than that. The battery health is unknown because it’s not an Apple-certified repair, certainly; but that doesn’t mean that the battery is bad, and it would be anti-competitive to claim that.)
"Needs service" is the same as reporting that it is broken. Another thing is that warranty covers manufacturing defects so, for example, it is unreasonable to automatically void warranty for a screen just because the battery was replaced.
> for example, it is unreasonable to automatically void warranty for a screen just because the battery was replaced.
I get where you are coming from but this isn't so cut and dried, as incompetent repairs are certainly capable of damaging or destroying other components. Someone I know once unknowingly messed up an antenna in the process of replacing a phone battery with an after market one, which caused all sorts of odd and intermittent symptoms with communication issues. Why should a manufacturer be expected to deal with that under warranty?
Part of the problem with consumer electronics is that they aren't really particularly designed to be serviceable, let alone user-serviceable. So it's not like a car manufacturer saying they'll refuse to warranty a rear shock because you changed your own oil or whatever.
I'm a strong supporter of right-to-repair, but I'm not convinced that should extend to forcing user serviceable designs where there is an actual design tradeoff. On the other hand this is pretty hard to prove - maybe all you can do is go after user-hostile design changes that serve no other purpose.
I completely agree that manufacturer is not responsible for badly done 3rd party repairs which have broken things. My point is that warranty should be denied only in cases where someone (either manufacturer itself or an independent 3rd party) can prove that a component broke because of a bad repair.
There’s a big gap between this and a one-time alert and/or annotation that can be pulled on the device by a service technician. Cutting off battery status just seems petty
There's a switch version that uses the accelerometer/gyro in the joy cons to emulate a wiimote, it works surprisingly well - definitely worth a shot if you want to replay it!
Nintendo does tend to allow things that let users "code" their own games, as long as it's well-checked and the devs are upfront about it. See SmileBasic(http://smilebasic.com/en/), a commercial BASIC interpreter for 3DS that let's you make simple games, condoned by Nintendo and sold on the eShop. Coincidentally, it led to 2 separate exploit chains that allow for native code execution - Nintendo doesn't want any of that and it's understandable that they want to avoid any possibility of it happening, especially if the groundwork for such an exploit is getting snuck in as a legitimate game without even telling them about it. People will always find their way around sandboxes and limitations, especially on a highly targeted system like the switch.
Everyone needs a hobby - for a lot of people, doing this kind of research and development is just plain fun, especially if it involves working with video games you enjoy or collaborative work with a lot of people that share the same interests. I guess it's a bit like an online hackerspace?
Emulators in particular seem to attract a lot of extremely talented programmers, since they often demand advanced or novel techniques in reverse engineering, compilers, graphics, etc. and I guess serve as a nice "challenge" for those who are good at these things.
