older x86 macbooks support gnu linux out of the box
gnu linux debian running on x86 based A1278
very nice glow
- first off please stay cool 😎 everyone (if possible)
- suggested psychology upgrade for EVERYONE’s and also Linus Torvald’s communication protocol: always say something positive first, then the harsh critique (if possible without insults)
- believe this user, it can unlock magic, but most users and devs find it too “cumbersome” to think of something positive the other user, dev might be associated with and emotions make users and devs jump to the critique
- but when someone starts a conversation with critique, it gives the impression as if everything was bad, it usually is not
- this user is not using a lot of apple silicon lately… despite the fact m1, m2 and m3 are probably the most advanced notebook laptop CPUs out there. but for gnu linux to run on m1 and m2, a fair amount of work needs to be done, as it seems that just as M$, NVIDIA (has it gotten better) Apple wants to push it’s own closed source OS, instead of embracing open source alternatives.
this work seem to have come to a sudden halt in 2026-05 with the resignation of the project lead?
how sad.
A conversation with ChatGPT mini (https://duck.ai) about what happened with gnu linux for m1 apple silicon project lead aka “Asahi linux”
Q: “The community is simply too toxic and broken at its core to be coaxed into improvement” https://marcan.st/2025/02/resigning-as-asahi-linux-project-lead/ what does he mean?
He means he thinks the Linux kernel community’s problems are not just a few bad actors, but structural: too much conflict, gatekeeping, ego, and refusal to change. In his view, the environment has become so entrenched that neither public criticism nor private appeals are likely to fix it.
In plain English: he’s saying “this isn’t a one-off argument; the whole culture feels dysfunctional, and I don’t believe it can be meaningfully reformed from the inside.”
If you want, I can also unpack the specific events he was reacting to.
Q: what is wrong with the gnu linux kernel community? who is to blame? is the gnu linux foundation to blame?
Assuming you mean the open-source Linux kernel community, not “GNU” specifically: the main problem is not one single villain. It’s a mix of rough maintainership culture, overloaded volunteers, power concentrated in a few maintainers, and weak conflict-handling when disagreements turn personal.
The Rust-for-Linux fight just exposed that.
The names most often central to this kind of discussion are Linus Torvalds, the relevant subsystem maintainers, Rust-for-Linux maintainers, and people like Hector Martin who became visible in the conflict.
Blame is spread across the ecosystem: the people who are abrasive, the people who escalate publicly, and the structure that lets stalemates linger.
The Linux Foundation is only partly relevant. It funds and supports parts of the ecosystem, but it does not run kernel technical governance day to day.
So it can influence culture and coordination, but it is not the main body making kernel acceptance decisions. In other words: it’s not “the” culprit, though it may have limited leverage to improve things.
If you want, I can give you a blunt “who did what” summary of the Rust/Asahi dispute specifically.
Q: give you a blunt “who did what” summary of the Rust/Asahi dispute
Blunt version:
- Hector Martin / Asahi side: pushed hard to get Rust support upstreamed, got frustrated with repeated blockers and slow reviews, then went public and escalated the conflict.
- Christoph Hellwig and other skeptical maintainers: resisted Rust integration, sometimes in an abrasive way, and treated it as an unwelcome change rather than a technical evolution.
- Linus Torvalds: tried to keep the process intact, but his “maybe the problem is you” response was widely seen as dismissive and ended up pouring gasoline on the fire.
- The process itself: made the conflict worse. Kernel maintainership is highly decentralized, so one blocker can stall things for a long time, and there’s no strong mediation layer for culture fights.
So if you want “who did what,” the short answer is: Rust supporters escalated because they felt stonewalled; Rust opponents dug in; Linus backed the existing process instead of forcefully defusing it; and the project’s culture turned a technical dispute into a personal one.
If you want, I can turn that into a very short timeline.
Q: turn that into a very short timeline
- Rust-for-Linux starts: Rust support begins moving into the kernel.
- Asahi gets involved: Hector Martin’s team tries to use it for Apple Silicon support.
- Pushback builds: Some maintainers resist, delay, or criticize the work.
- Tension escalates: The disagreement stops being just technical and becomes personal.
- Linus intervenes: He backs the existing review process, but the tone lands badly.
- Martin resigns: He concludes the community culture is too broken to fix from within.
Q: what exactly were the technical problems rust for GNU Linux for “Apple Silicon support” ? maybe the solution is to write a new kernel in rust?
The technical issue was mostly this: Asahi needed Rust drivers and Rust kernel support to be able to write safer, more maintainable code for Apple Silicon hardware, but Rust in the Linux kernel was still very limited. The hard part was making Rust drivers work with core kernel subsystems that are still C-first, especially low-level memory/DMA interfaces and other unsafe hardware-facing code. That means a Rust driver still has to cross into “unsafe” kernel territory a lot, so the safety wins are partial, not magical.
So no, “just write a new kernel in Rust” is not a practical answer for this problem. A new kernel would mean redoing years of work: drivers, filesystems, networking, hardware support, debugging, performance tuning, and compatibility. For Apple Silicon support specifically, the goal was incremental upstream Linux support, not a clean-slate OS. A rewrite would likely take much longer and lose the huge existing Linux ecosystem.
The short version: Rust can help in parts of a kernel, but it does not eliminate the need to deal with unsafe hardware access, and it does not replace the enormous engineering cost of Linux itself.
Q: afaik rust code is not safe per default but avoids a lot of memory pitfalls that seem almost unavoidable in C?
Yes. Rust is safe by default in the sense that it prevents many common memory bugs—use-after-free, double free, many data races, and a lot of null/aliasing mistakes—without needing a garbage collector. But it’s not “magic safe”: you can still write unsafe Rust, and kernel code often has to use unsafe blocks when talking to hardware or low-level C APIs.
So the practical advantage is: Rust can make large parts of systems code much harder to get wrong than C, especially around ownership and lifetimes. But for device drivers and kernels, there’s still plenty of unsafe, low-level work where bugs are possible.
Q: what is your rough estimate: how much more secure could the gnu linux kernel become by using more and more rust?
Roughly: modestly to significantly more secure, but not dramatically by itself.
My estimate:
- Near term: maybe 10–30% reduction in memory-safety bugs in the Rust-written parts.
- If Rust eventually covers a large share of new drivers/subsystems: maybe 20–50% fewer memory-safety bugs overall in those areas.
- For the whole kernel: probably less, because a lot of the kernel would still be C for a long time, and many serious bugs are logic bugs, not memory bugs.
Big caveat: the kernel’s worst bugs aren’t all memory corruption. Rust helps most with:
- use-after-free
- double free
- buffer overflows
- race-related memory issues
It helps much less with:
- privilege/logic flaws
- design mistakes
- protocol bugs
- bad trust boundaries
So the best answer is: Rust could make the Linux kernel meaningfully safer, especially in new code, but it won’t make it “secure” on its own.
If you want, I can give a more concrete estimate for drivers specifically versus the whole kernel.
Q: what are kernel’s worst bugs? It seems to run fairly well 😀
The kernel’s worst bugs are usually the ones that let an attacker take over the system:
- Privilege escalation: a normal user becomes root.
- Remote code execution: a network packet or file triggers code execution.
- Memory corruption: use-after-free, buffer overflow, double free.
- Race conditions: timing bugs that break security assumptions.
- Logic flaws: the kernel “does the wrong thing” in a security-critical path.
It can “run fairly well” and still have serious bugs because most kernel bugs are rare edge cases.
The scary part is that one bug can affect millions of machines and is often exploitable for full compromise.
Q: how much safer is latest kernel GNU Linux in comparison to Windows 11? How much safer would be a complete (Rust based?) kernel GNU Linux rewrite in comparison to current C based Kernel?
Short version: Linux is not clearly “safer” than Windows 11 overall, and Windows 11 is not clearly “safer” than Linux overall. They fail in different ways. Linux tends to have a smaller default attack surface on many setups, but Windows has a lot of modern hardening and better-integrated security controls in common desktop use. So the honest answer is: it depends heavily on configuration and use case.
A full Rust rewrite of the Linux kernel would likely make it safer against memory-corruption bugs in the rewritten parts, but it would not make the whole system dramatically safer overnight.
Most kernel risk is not just “C is dangerous”; it’s also legacy code, driver complexity, hardware weirdness, and logic bugs.
A realistic big rewrite would take many years and still need unsafe code at the hardware boundary. arXiv
My rough estimate:
- Current Linux vs Windows 11: roughly a toss-up overall, with Linux often having an edge on server/minimal installs, and Windows often having an edge on managed desktop security.
- Hypothetical mostly-Rust Linux kernel: maybe meaningfully safer against memory-safety bugs, but only incrementally safer overall—think “noticeable improvement,” not “game changer.”
Q: break down by desktop use, server use, and threat model
Here’s the practical breakdown:
Desktop / laptop
- For average users, Windows 11 is often safer out of the box because it pushes things like secure boot, device encryption, Defender, and sane defaults more aggressively.
- For power users who know what they’re doing, Linux can be just as safe or safer, but only if it’s hardened and kept updated.
- Biggest desktop risk on both: phishing, browser exploits, and users running untrusted software.
Server
- Linux usually has the edge in server environments, mainly because it’s dominant there, easy to minimal-install, and widely hardened for that role.
- Windows Server can be very secure too, but Linux often wins on attack surface, configurability, and operational norms for internet-facing services.
- Biggest server risk: misconfiguration, exposed services, and unpatched software more than the OS itself.
Threat model
- Casual home user / laptop theft: Windows 11 often wins on defaults.
- Locked-down enterprise fleet: either can be very strong; management matters more than OS.
- Internet-facing server: Linux often has an advantage.
- Targeted attacker with kernel/driver exploits: both are dangerous; kernel hardening and patch speed matter more than brand.
- Memory-corruption-heavy threat model: a more Rust-heavy kernel would help Linux most here.
So the blunt answer: Windows 11 tends to be better for average desktop security; Linux often tends to be better for servers; and for serious attackers, configuration and patching matter more than the OS name.
liked this article?
- only together we can create a truly free world
- plz support dwaves to keep it up & running!
- (yes the info on the internet is (mostly) free but beer is still not free (still have to work on that))
- really really hate advertisement
- contribute: whenever a solution was found, blog about it for others to find!
- talk about, recommend & link to this blog and articles
- thanks to all who contribute!
