It's similarly bogus here. Early Asahi development tried to upstream as much as possible but ultimately still maintained a gigantic pile of downsteam patches, which wasn't a sustainable model.
Most of current development is focused on reducing that pile to zero to get things into a tractable state again. So things continue to be active, but the progress has become much less visible.
M2 to M3 was a complete architectural change that will require a lot of reverse engineering. As far as I know no one is working on this. The M1/M2 work was a labor of love of largely one dev that has since moved on.
The project is still active and working to upstream the work of these devs. But as far as I know, no NEW reverse engineering is being done. Ergo, it’s a dead end.
People are already getting worked up about being prompted to opt into a new feature on update (even if that prompt is hidden behind an icon that doesn't do anything until the user clicks it), so it's not inconceivable that the kill switch just disables those opt-in prompts for AI-related features.
Just in case anyone's tempted to buy one of these now: Support is alright after heroic (and continuing) efforts to improve platform support, but it's flaky. M1/M2 devices offer better performance and the state of Asahi drivers is much better, particularly around audio.
Sadly compile times of LLVM-based recompilers make it impractical for competitive x86 emulation. We're not just talking a few single-frame stutters here and there, but considerable startup delays and pauses in-game.
LLVM's optimization passes also are less useful than you might think, since the vast majority of them is motivated by source->binary translation (like clang). They don't have much effect when recompiling an already optimized binary to another architecture.
I feel your pain on this one despite being fairly comfortable with nix by now. This is 100% an issue either the documentation or the nix CLI should do a better job at.
The wiki rightfully points towards "roots", i.e. references produced by nix-build or similar. Additionally, there are other places that will keep references and hence block garbage collection though:
1. Your nix profile (`nix profile list` / `nix profile remove`) and its old generations (`nix profile (wipe-)history`)
2. Your NixOS configuration (configuration.nix) and its old generations (`nixos-rebuild list-generations`)
It doesn't help that there's no discoverable way to tell why a particular nix store path is not being garbage collected either.
SUID by itself is not a security liability. Typically, programs using SUID quickly drop their additional privileges during startup to avoid the scenario you're describing. So the vulnerability in firejail would have to be early during startup before any of that.
Still, it can happen of course, particularly with memory-unsafe languages. Conversely without root privileges you have to sacrifice strength of your sandbox, widening the vulnerability window in the app you were trying to constrain to begin with.
Meanwhile bubblewrap relies on user namespaces, which come with their own set of security problems. They are disabled by default in many distributions for that reason.
Most of current development is focused on reducing that pile to zero to get things into a tractable state again. So things continue to be active, but the progress has become much less visible.
reply