Rumor is Samsung won't support Google's Linux Terminal (at least for their existing phones) since their Knox conflicts with the Android Virtualization Framework :-(.
Honestly I'd like to see Windows 11 running under this as well, but that seems incredibly unlikely.
It was the Ubuntu 16.04 desktop running in a LXD container. It crashed when the tablet went in out of memory, so I had to be careful with what I was running.
I don't think so. Software is maybe the only "engineering" discipline where it is considered okay to use mainstream tools incorrectly and then blame the tools.
CyanogenMod required a CLA to assign them copyright to Cyanogen Inc, only for them to basically kill the project. They forked it as LineageOS only to still require a CLA.
This is a game; I don't think a debug configuration (with checks for things like this enabled) would run fast enough to be playable on contemporary hardware.
Generally, game console "debug" configurations aren't "true" debug like most people think of -- optimizations are still globally enabled, but the build generally has a number of debug systems enabled that naturally require the use of a devkit. Devkits, especially back then, generally had 2-3x as much memory as retail systems -- so you'd happily sacrifice framerate during feature development to have those systems enabled.
Debugging was (and still is) generally done on optimized builds and, once you know the general area of the problem, you simply disable optimizations for that file or subsystem if you can't pinpoint the issue in an optimized build.
The biggest performance hit, in general, comes from disabling optimizations in the compiler. I say "in general" because there are systems that might be used to find this kind of thing that DO make a game wholly unplayable, such as a stomp allocator. Of course, you wouldn't generally enable a stomp allocator across all your allocations unless you're desperate, so you could still have that enabled to find this kind of bug and end up with a playable game.
The more likely reason here is that no one noticed or cared. GTA:SA is 21 years old and this bug doesn't affect the Xbox or other versions.
You can (and could) easily compile an optimized build with debug symbols to track down sources of issues, but catching a bug like this would likely take a dynamic checker like Valgrind or MSan, which do not allow for any optimizations if you want to avoid false negatives, and add even more overhead on top of that. (Valgrind with its full processor-level virtualization, and MSan with its shadow state on every access. But MSan didn't exist at the time, and Valgrind barely existed.)
At minimum, fine-grained stack randomization might have exposed the issue, but only if it happened to be spotted in playtests on the debug build.
How could a stomp allocator have possibly found this bug? The offending values are stored on the stack, in-bounds when written to, and again in-bounds when read from.
At no point is there an OOB access, just a failure to initialize stack variables. And to catch that, you'd need either MSan-style shadow state that didn't exist, thorough playtesting with fine-grained stack randomization, or some sort of poisoning that I don't think existed.
No you don't, MinGW(-w64) targets windows directly (with MinGW statically linked in). I've built a Windows->Linux cross-compiler that depends solely on DLLs built-in to Windows (kernel32.dll, MSVCRT.dll, and user32.dll).
Granted that was hundreds of hours, some patches (only 8 lines though), and probably a bit of masochism.
I did of course need MSYS2 command line utilities like make and bison to run the GCC configuration/make scripts.
Although we use the mingw32 version of make along with the cross-compiler which also has no other dependencies (it uses cmd.exe as a shell if you don't have a bash.exe in your PATH).
The proliferation of Docker containers seems to go against that. Those really only work well since the kernel has a stable syscall ABI.
So much so that you see Microsoft switching to a stable syscall ABI with Windows 11.
"Decoupling the User/Kernel boundary in Windows is a monumental task and highly non-trivial, however, we have been working hard to stabilize this boundary across all of Windows to provide our customers the flexibility to run down-level containers"
Honestly I'd like to see Windows 11 running under this as well, but that seems incredibly unlikely.