One of the DRM circumvention methods for the Xbox 360 involved precision drilling a specific depth into one of the chips on the board. Microsoft was very aware of the nature of physical access while designing this, haha.
I had many Xbox 360s with flashed DVD drive firmware back in the day. But as I never owned a slim console I had no idea the drill/Kamikaze hack was a thing until now.
Xbox One homebrew has effectively always been supported. Anyone can register a development account and boot the system into dev mode. IIRC in a talk about console security, a Microsoft developer noted that this was an intentional deterrent against hacking. An effort to split the community so that pirates and homebrew enthusiasts wouldn't have a reason to collaborate.
They did dumb things like limit memory availability in dev mode, though. Also they require a government ID to enable dev mode (but at least the quit charging $100 for it!). And they made it so you can't enable dev mode on consoles that are banned from Xbox services.
I understand it's still more than most console makers do, having dev mode at all, but it's maddening to me that Microsoft made dev mode so annoying and limited. I'd honestly just rather a hack be available so we have the option of using the entire memory or repurposing banned consoles.
It's closer to the "sealed system volume" model that macOS uses. The core OS filesystem isn't (normally) writable, although you can finagle it to add drivers and such.
> Alternatively, you become "they" by forking the project.
This doesn't make sense for the vast majority of people.
Linux desktop doesn't have the vast majority of the niceties that living in the Apple ecosystem gives you. If I was going to rebuild any one of them for Linux, it would easily become a major project that would suck up all my free time.
> This doesn't make sense for the vast majority of people.
That's fine.
> Linux desktop doesn't have the vast majority of the niceties that living in the Apple ecosystem gives you.
And it never will should nobody actually step up and put in the work to make it a reality. Linux needs users willing to do such things.
The original free software business model is that people would pay programmers to work on the features they needed and the results would go back into the commons in the form of upstream patches. I've actually made some money this way. It was nice.
It's less stress on a frequently used port. I've got an early M1 MacBook Air where the USB-C port I always used for charging is starting to get flaky, presumably because it's been used so much and because of the weight of the cord + dongle hanging off the side of the machine.
Replacement port for M1 Air can be bought for around $10 off Amazon and installation take like 10 minutes for total newbie like me. All you need is right screwdriver.
Those old 2011 machines aren't really getting macOS security updates anymore, and compatible apps are dropping; I wouldn't recommend using anything but Linux on them. And even with a non-15-year-old battery, you'll be lucky to get half the battery life of Apple Silicon with a 2nd gen Core i5 CPU.
Flatpak is basically running an isolated separate distro. A software inside a Flatpak has to communicate with the outside world to do anything useful which is yet another API surface that needs to be maintained and it will be dropped just like gtk2 when people just don't want to maintain it.
I think the way the Linux ecosystem works is fundamentally against maintaining old binaries unless they are a text-only program.
Friendly reminder that GOG ignored and downplayed the GOG Galaxy 0-day privilege escalation bug CVE-2020-24574 [1] for literal years. They tried to brush off the security researcher who reported the issue by rotating keys and claiming it was fixed. Their non-serious stance towards security means Galaxy isn't really software I want running on my system anymore.
reply