$200 ARM based Linux Laptop is Here

I would however need to be able to play AoE2:DE on my PC, might have to keep a Win10 partition on the PC if I make the move as, AFAIK, it doesn't work great on Linux (haven't looked into it in a while, maybe outdated).

To your larger question, the problem of why equating "poverty" with being bad is that as human beings we have the tendency of overgeneralizing negative characteristics, sometimes called the Horn Effect. A person is poor, and that's bad, and therefore the person themself is bad.

Using the phrase now in this context can feel jarring. I think taste and sensibilities have changed - lots of old jokes don't land like they used to.

Also, while there is a ways to go, a shocking amount is fully completed: I2C, UART, Power Management, GPIO, Display Controller, USB, Thunderbolt, NVMe storage, the works. Hector says he is just rewriting a few drivers from other folk, going to merge it upstream, and then really only the GPU is remaining.

But he has a friend working on that and less than a year later and despite not being the primary focus, they're nearly at OpenGLES, which has shocked people for how fast the GPU drivers are coming together.

Apple could have just copied-and-pasted the iPhone boot process, and that would have been extremely easy to do because M1 Macs and iPhones and iPads all share the same system for booting (being all Apple Silicon chips), that is, iBoot. Apple could have just thrown in iBoot but with signature enforcement for macOS instead of iOS and called it a day. Nothing but macOS would boot, but would Apple really care?

However, Apple went out of their way to not do this, but extended iBoot with Boot Policies, also referred to as the LocalPolicy. Apple documents this themselves at:

https://support.apple.com/guide/security/boot-modes-sec10869...

https://support.apple.com/guide/security/contents-a-localpol...

Along with the Permissive Security mode at

https://support.apple.com/guide/security/startup-disk-securi...

With the LocalPolicy, every partition and OS install gets their own Security Policy, which is another area where Apple goes above-and-beyond other systems. On Windows computers and Android devices, a device would typically be marked as "Secure Boot Enabled" or "Secure Boot Disabled" (no signature enforcement), on a chip/system-wide level. With this Boot Policy system, every OS can have their own secure boot mode, meaning you could have a fully-secure MacOS install alongside a (unsecured) Linux install, no problem.

You might wonder, if every OS can just have their own secure boot settings, how come a thief couldn't just replace a secure boot MacOS partition with a Linux no-secure-boot partition. Apple managed to prevent this with an extremely complicated "ownership" system that prevents a third-party hacker or a thief from being able to clear those BootPolicies without the owner's permission, as documented at:

https://eclecticlight.co/2021/07/18/last-week-on-my-mac-the-...

Again, if Apple only cared about letting macOS run, copying-and-pasting regular iBoot would have worked fine. Instead, they had to tack on Permissive Mode, code signing from the Secure Enclave (for custom kernels), "ownership," and Boot Policies. A lot of work to just pull out the rug, right?

As if just enabling it with all of these otherwise-unnecessary add-ons wasn't enough, there are other signs of Apple being more... permissive about things. For example, unlike almost every other ARM chip which makes a huge mess of things, Apple has implemented their drivers in a way that means the same driver can handle different chips with the same core designs without almost any rewrites. An example of this is that, imagine the high-performance Firestorm cores on the M1. Marcan can just write a driver for Firestorm, and it will just work on the M1, M1 Pro, and M1 Max without rewrites for each chip that contains it (other than updating the device tree outside the drivers). That's unheard of for other ARM chips and makes future maintenance a breeze.

And, yes, Apple didn't provide and still does not provide much public documentation about their chip, but there is an extra grace: MacOS, apparently, has the ability to run under a lightweight hypervisor with hardware passthrough with no flak or patching necessary on the M1 chip (amazing considering how few ARM chips have virtualization, let alone this well implemented?) This meant that even though the hardware is undocumented, Marcan could write a small hypervisor called m1n1, run MacOS within it, and document all of the hardware calls and commands completely transparently. It didn't need to be that-well implemented. Maybe that's Apple doing a good job, or maybe it's them giving a less-obvious help.