> Is there anything that doesn’t work?
> To quote Hamlet, Act 3, Scene 3, Line 87: “No.”
> Everything works… and works perfectly.
That is impressive and really hard to believe! I guess I'll have to find an M1 mac Mini to try myself!
> To quote Hamlet, Act 3, Scene 3, Line 87: “No.”
> Everything works… and works perfectly.
That is impressive and really hard to believe! I guess I'll have to find an M1 mac Mini to try myself!
Builtin speaker support is still a work in progress. It works if you know what you are doing and are not afraid to damage your speakers if you make a mistake. There's been progress on this though, so I expect this to be resolved sooner than later.
There's no builtin speakers in the author's mac studio though, so I'll give them a pass for this one.
Bluetooth and wifi both work, but their drivers are still buggy. I see a lot of errors in dmseg from these drivers and occasionally things stop working and require a reboot to fix.
GPU acceleration works, but there is still a lot of work to do on that driver.
External displays over the thunderbolt ports don't work yet.
Other things that don't work on the laptops: webcam, touch-id / Secure Enclave, some miscellaneous software.
Don't get me wrong, I've been able to daily drive linux only on my m2 air since August. I love the hardware and the current state of Asahi meets my needs. And its been steadily improving over the course of time. But its far from "work[ing] perfectly" yet.
curl https://alx.sh | sh
to install asahi linux Dual boot on m1 or m2 MacBook apple silicon
It sounds like if you're developing services hosted in a cloud, Asahi Linux is a great fit for a desktop Mac.
Some of their more powerful routers have a bunch of ARM cores (no video out, though) and I think I've seen people using OpenWRT there.
For a while they were using Annapurna Labs CPUs, and I've seen that in some high end Netgear wireless routers from 2017, and I see people selling those with OpenWRT on eBay. I don't know their performance, but I'd like to try that instead for a mini server instead of an expensive and virtually inexistent RPi.
There goes a list of routers with Annapurna Labs processors, I'll see tomorrow if I find around some OpenWRT builds for them.
https://www.semianalysis.com/p/amazon-graviton-3-uses-chiple...
Considering modern AWS hardware relies heavily on Nitro, their dedicated chips offloading networking and storage, it's unlikely Graviton CPUs would easily work outside of AWS' environment.
Don't all Macs come with a built-in speaker? I.e. the one that plays the start-up chime, and plays "system sounds" like emptying the trash.
On Mac notebooks and AIOs, this is one-and-the-same as the obvious external speaker array used as the default output device; but on desktop Macs (like the Mac Mini — don't know about the Mac Studio), it's a separate little speaker hidden somewhere inside the chassis. (It's like the old concept of a "PC speaker", but this one is hooked up to a DAC and routable as a regular audio device, rather than only being able to play tones from a PIT.)
Many of the penetration testing tools are not mainstream and they include pre-build x86_64 binaries, or are configured just to not compile with ARM, for reason unknown. And there is no time to figure out what is wrong.
I know this might be a niche scenario, but still...
I used QEMU through Podman machine in the end, but the performance is terrible. Even on MacOS side QEMU does not support Rosetta 2. Docker for Desktop supports and gives significant boost, but I don’t want to use it.
Is Rosetta 2 that much faster than QEMU's own translation? Why?
Oh yes. Based on the benchmarks I've seen it's a good 30-40% faster on compute workloads. I assume that the pre-transpilation of the binaries is advantageous relative to having to virtualize the CPU.
† actually not measured, but compared to the order of magnitude on the other side it's about that, eyeballed against the same code on aarch64.
Among other things, Rosetta 2 is able to use the CPU's special TSO memory ordering mode, which I think QEMU's TCG cannot use so has to use barrier instructions instead (MTTCG), or run all the virtualised CPU threads on a single host core (obviously slower for parallel workloads).
I love the battery life and the keyboard is much better than the old one. It feels snappy running native code but I just know it's going to cause me more issues than it's worth.
Wasn’t the M2 Pro released like a month ago?
Am I that old that a few weeks now counts as once upon a time?
But yeah, it was like week after the release I took that laptop to CTF.
I'm just saying.
Not having to deal with an entire custom laptop (i.e. getting a lot of standard peripherals for "free" after only getting USB to work) also helps a whole lot, and note the article specifically talks about a desktop mac.
It's not like PC world of mix and match everything.
I do wish apple did a native apple port, but the community is making good progress on that front.
You mean in reverse engineering hardware?
Marcan, Asahi Lina, and related folks have been working on improving 3d accelerations. It's good enough for desktop use and some gaming so far, games like tuxracer, video playback, minecraft, etc. First the driver was in user space in python, then in the kernel with rust, and recent improvements have increased parallelism (from Lina) and removing Mailboxes (from Marcan).
OpenGL and Vulkan compliance has been increasing. Last I heard OpenGL was at 99-100% (almost all tests passing) and Vulkan wasn't as good, but improving. I believe Alyssa Rosen is doing much of that work.
Last published update I've seen is: https://asahilinux.org/2022/12/gpu-drivers-now-in-asahi-linu...
There are some posts on Twitter and/or Mastodon, and regular updates on YouTube from "Asahi Lina" and Marcan, often by Live stream and Patreon.
Oh, and Neal Gompa is working on getting the GPU working with Fedora. One problem is most ARM linux distros default to 4k pages. But the GPU (which shares memory with the CPU) requires 16k pages. Seems like a performance win (less TLB thrashing), with a marginal increase in memory use.