REretired·Jun 28, 2026
Apple is still selling Macs with M3 and M4 chips.
Regarding M5 support, seems like a matter of time.
https://github.com/AsahiLinux/m1n1/pull/578
In Librepods: AirPods liberatedAsahiLinux
m1n1
Python2021–2026
AsahiLinux / m1n1
m1n1
A bootloader and experimentation playground for Apple Silicon
9Distinct people
14Mentions
1Explicit recommenders
4.3KGitHub stars
What to know before exploring
What it is
A bootloader and experimentation playground for Apple Silicon
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
I know you said you dont want mac, but I recommend apple only for the hardware. If you want linux, you can use Asahi Linux. Its in the beta stages but it allows your to harness…
havocsupreme used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year14 dated mentions
Observed mentions: 2021-01-15 03:47:03 UTC to 2026-06-28 21:50:22 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
14 sourcesOne of the coolest things (IMO) about the entire Asahi effort, and why I'm not at all surprised that they surpassed Apple, was the dedicated effort to build bespoke developer-friendly Python tooling early in the reverse engineering process.
https://asahilinux.org/2021/08/progress-report-august-2021/
> Since the hypervisor is built on m1n1, it works together with Python code running on a separate host machine. Effectively, the Python host can “puppeteer” the M1 and its guest OS remotely. The hypervisor itself is partially written in Python! This allows us to have a very fast test cycle, and we can even update parts of the hypervisor itself live during guest execution, without a reboot.
> We then started building a Python implementation of this RPC protocol and marshaling system. This implementation serves a triple purpose: it allows us to
Read the rest
parse the DCP logs from the hypervisor to understand what macOS does, it allows us to build a prototype DCP driver entirely in Python, and it will in the future be used to automatically generate marshaling code for the Linux kernel DCP driver.
Code here: https://github.com/AsahiLinux/m1n1/blob/main/proxyclient/m1n...
If you watch any of Asahi Lina's streams from the time before they had their full drivers implemented in Rust, she's able to weave together complex bitflag-manipulating pipelines at the speed of thought with self-documenting code, all in Python running on the host machine, all while joking with viewers via her adorable avatar. I've never seen anything like it before. The whole workflow is a tremendous and unprecedented accomplishment by the entire Asahi team.
There's also basic ANE support for Asahi now:
https://github.com/eiln/ane
https://github.com/eiln/anecc
https://github.com/AsahiLinux/m1n1/pull/296/files
In What we know about the Apple Neural EngineWhat makes you say there isn't community participation? The repo for m1n1, at least, has 42 contributors according to Github[1]. There's plenty more reporting bugs and such, and their IRC channel seems relatively active.
1: https://github.com/AsahiLinux/m1n1
In November 2022 Progress ReportExactly - https://github.com/AsahiLinux/m1n1
In First triangle ever rendered on an M1 Mac with a fully open-source driverI know you said you dont want mac, but I recommend apple only for the hardware. If you want linux, you can use Asahi Linux. Its in the beta stages but it allows your to harness mac’s superior hardware to develop on Linux. Apple is proven to make long lasting products that meet all the requirements you’ve list. Recommend M1 in particular, better than most intel and ARM laptops of its generation.
https://github.com/AsahiLinux/m1n1
In Ask HN: What’s a good laptop for software development at around $2k?The solution isn't to stop using rand(). The solution is to stop using newlib.
If you're doing your own custom memory management like this, you shouldn't even have a malloc implementation at all. Even newlib is too bloated for your use case. At this point, chances are you're using a trivial subset of the C library and it'd be easy to roll your own. You can import bits and pieces from other projects (I personally sometimes copy and paste bits from PDClib for this). In such a tight embedded project, chances are you don't even have threads; why even pull in that reentrancy code?
Freestanding C code with no standard library isn't scary. If you need an example, look at what we do for m1n1:
https://github.com/AsahiLinux/m1n1/tree/main/src
In particular, this is the libc subset we use (we do have malloc here, which is dlmalloc, but still not eno
Read the rest
ugh of libc to be worth depending on a full one):
https://github.com/AsahiLinux/m1n1/tree/main/sysinc
correct, i forgot some context about what i meant "apple developing", apple allowed raw images to be used now, this is what i described being used in the cpu manufacturing process for testing units. this was not always an option. i meant this pseudo-feature being made public, not asahi which has been public and apple has been aware of for over a year
see here:
[1]: https://github.com/AsahiLinux/m1n1/commit/0d4fb00ceb8a14f083...
[2]: https://news.ycombinator.com/item?id=29591578
In Asahi Linux alpha release> as long as they are ARM ISA compatible.
And apparently in Apple's case, they get to be a little bit incompatible (no nVHE mode, crazy custom ISA extensions, ...)
Which is also obvious proof that they're their own designs, because literally nobody else could or would implement the same Apple-proprietary ISA extensions. Here, we use some of the custom instructions in m1n1:
https://github.com/AsahiLinux/m1n1/blob/main/src/gxf_asm.S#L...
That won't work on any non-Apple core.
In Power, frequency, management: how M1 E cores winThe changes are in macOS’s bootloader. Previously, the bootloader was only designed to load a macOS kernel executable, which was stored on disk as a Mach object file with some particular constraints. The Asahi project had to use a rather ugly linker script to generate an executable that “looks like like” a macOS kernel but is actually a first-stage Linux bootloader [1].
In macOS 12.1, Apple engineers changed the format of the kernel image, which broke the Asahi install process. However, they also added a “raw image mode” which allows the bootloader to load things that don’t look like macOS kernels — it’s an officially-supported boot flow for the Asahi project to use going forwards without fear of macOS updates breaking it again. (Plus, it makes that linker script much simpler [2]).
[1]: https://github.com/AsahiLinux/m1n1/blob/84acf60c24b8
Read the rest
They're using zero so far [0], and until they need it for something else it wouldn't make sense not to use it for this. The CPU tunables aren't fuses or anything, the OS configures them (m1n1 in our case)
[0] https://github.com/AsahiLinux/m1n1/blob/main/src/chickens.c
In M1racles: An Apple M1 covert channel vulnerabilityIt's an implementation-defined register, which means it's up to Apple to define it. We have no idea what it does; we haven't observed any visible effects from flipping those bits. Given that it's per-cluster, we can infer that it has something to do with cluster-specific logic. Perhaps memory interface or power control.
There are hundreds of Apple implementation-defined registers; we're documenting them as we learn more about them [0] [1] [2]
[0] https://github.com/AsahiLinux/m1n1/blob/main/tools/apple_reg...
[1] https://github.com/AsahiLinux/docs/wiki/HW%3AARM-System-Regi...
[2] https://github.com/AsahiLinux/docs/wiki/HW%3AARM-System-Regi...
In M1racles: An Apple M1 covert channel vulnerabilityThey have a desktop running on simplefb. That is not a usable desktop (no matter what they say), with zero acceleration and all completely software rendered. There is literally no graphics or display driver. The bootloader gives you a chunk of RAM that is the screen and you write stuff to it. No multidisplay, no resolution switching, no hotplugging, no acceleration. It's like running x86 linux on efifb with no radeon/intel/nvidia drivers at all. Think vesafb for those old enough to remember those days, but even dumber - at least on that one you could pick a resolution.
Our kernel has simplefb support too, literally all you need to do is write 5 lines of devicetree properties to get that to work - zero patches needed to the upstream simplefb driver. Here is the code in our bootloader that takes the Apple framebuffer information and stuffs
Read the rest
it in the DT for Linux to use it:
https://github.com/AsahiLinux/m1n1/blob/main/src/kboot.c#L59
That's literally all you need to get "graphics".
I was actually planning on doing exactly the demo that they did since December, with a simplefb "full Ubuntu desktop" and everything else running off of USB, for the clickbait, because it's flashy even though it's a minimal amount of work, but with a clear disclaimer that it's a tech demo and there is a lot of work left to do. It certainly brings in the news. However, it is not a "fully usable Linux desktop".
FWIW: WiFi is Broadcom FullMAC (existing Linux driver) with some patches. Ethernet is a Broadcom chip over PCIe (once you have PCIe up, the driver is there). USB is DWC3 (existing Linux driver) with just an Apple PHY adaptation layer. Storage is NVMe with Apple hacks and a horrible (definitely not upstreamable) hack Corellium wrote to fake a PCIe bus because the Linux NVMe driver assumes PCIe. Please don't assume they are cranking out bespoke drivers every other day; most of their work is simple drivers and patches to existing ones. There is certainly work involved in figuring out all these Apple oddities, but these aren't new drivers.
I fully intend to support the SEP in our kernel once we get that far, with Touch ID for Linux log-in/unlock and also things like storing and using SSH keys within the SEP (think built-in YubiKey). Lots of reversing to be done, but all of this is in scope for our project. Drop by our IRC if you'd like to help out :)
I see your userland M1 assembly language hello world and raise you a bare-metal M1 kernel assembly language hello world :-)
https://github.com/AsahiLinux/m1n1/blob/main/src/start.S
The first few lines of that will print 'm1n1' to the serial port as it initializes other things and eventually jumps to C code.
In Apple M1 Assembly Language Hello World