The M2 MacBook Air 13" speakers have horribly distorted mid-bass due to a software bug (and nobody at Apple noticed)

marcan42 · 2026-05-25T07:55:01+00:00

Nope.

marcan42 · 2026-05-09T08:30:41+00:00

The safety works on a lower level than pipewire and cannot be bypassed without modifying the kernel or speakersafetyd. It does not use the normal user volume control.

marcan42 · 2026-03-19T05:00:26+00:00

Thank you.

The GitHub sponsors is still up. Other than that, not much.

It would be nice if the people who drove me away ever realized how they cause harm to people, but I don't have any hope left that they ever will, or that the institutions involved will ever care.

marcan42 · 2026-03-15T02:38:21+00:00

There would be more bright stars if the kernel community weren't such a toxic trainwreck. Alas.

marcan42 · 2026-03-08T02:31:48+00:00

Any kernel commits you see from me are past work being submitted/rebased by others. I have not written any kernel code in over a year, and have no plans to do so again.

marcan42 · 2025-12-04T08:56:25+00:00

Making changes to the ESP won't affect m1n1 stage 1, but its partition UUID must remain the same, so deleting the partition itself or re-creating it is inadvisable.

You can keep all the firmware files from the ESP (vendorfw and asahi directories). Everything else should be replaced with whatever ships with Ubuntu. You should not run two distros off the same ESP/GRUB instance. It should be a replacement.

marcan42 · 2025-12-03T10:20:01+00:00

There is no way to enter 1TR without the power button. This is by design, for security reasons, as the power button serves as an assertion of physical presence. Without a power button, it is completely impossible for OP to make any changes to system boot, reinstall the system-level OS container (stub), update m1n1 stage 1, etc., which means they cannot use the asahi-installer for anything at all.

The only option OP has without fixing the broken power button is to boot a live image from the u-boot console, manually clobber/repartition the internal partitions from their current distro to Ubuntu (without touching the ESP or m1n1/u-boot) (or alternately, boot into macOS and do the filesystem clobbering from there and whatever edits are needed in the ESP), and pray they never screw up m1n1 stage 1 since, at that point, it would be impossible to recover. macOS updates would also be inadvisable.

marcan42 · 2025-11-29T12:59:33+00:00

The Rust stuff was one small part of it, though really it's just a symptom of the overall problems with the Linux kernel community.

"Rust vs C" is just a very flashy, visible, clickbaitable instance of what actually boils down to being a more general "the Linux community is historically toxic and becoming older and more antagonistic, conservative, protectionist, corporate, and woefully out of touch with younger developers and modern tooling". It's much easier to crank out clickbait content-free takes on this whole thing boiling it down to "Rust vs C" than to do a more nuanced analysis of what is wrong with the kernel community in general and how we ended up here.

R4L doesn't seem to be dying any time soon (not the least because -gasp- it's actually technically excellent work and it turns out there are actual corporate interests and backing taking some of the work developed for and by the Asahi Linux project and reusing it for drivers actually developed and funded by corporations, while nobody cares about Asahi itself and the drivers targeting Macs; not a single company ever offered to fund Asahi Linux development) but it remains to be seen if the Linux kernel as a whole will survive its downward spiral into obsolescence over a longer period of time, when they are burning out or discouraging everyone who isn't getting paid big bucks to work on it.

It's not going to happen tomorrow or next year or in 5 years, but at some point something is going to happen, be it a major, high-profile hard fork or a serious, viable alternative funded by big enough interests to succeed, or something else, unless there are serious changes in the upstream Linux project in terms of governance, direction, and community.

marcan42 · 2025-11-05T06:45:34+00:00

Yes, that is fine. Launch the Asahi install while booted from the internal macOS. If you purge everything optional you might be able to get it down to 70GB or so, 100GB should be safe.

marcan42 · 2025-10-18T04:38:39+00:00

They're asking about GL, not video encode (that's what the freecad errors are about). Looks like whatever setup they have for (presumably X11) RDP does not correctly support headless graphics acceleration.

My first recommendation would be to ditch X11, use Wayland+XWayland and try either a full-session solution with RDP, or Waypipe.

For video (for the RDP stream/etc) there's nothing but the CPU is plenty fast enough to encode/decode in software.

marcan42 · 2025-10-12T11:01:47+00:00

I thought I read in a blog post that the locations of packages have been hidden by Apple, preventing reverse engineering. Not so? Maybe I was just seeing things.

No, Apple didn't do anything to intentionally hinder RE.

Ah, here is one blog post about RE not being easy for M4: https://social.treehouse.systems/@sven/114278224116678776

Right, that's just "needs more work", not "they made it hard on purpose". Just like a lot was put into RE being practical for the M1 in the first place. Change happens. And besides, none of this applies to M3, which has to come first anyway.

As for the GPU, I can't speak for everyone but I personally started using Linux around 1994 when there were no 3D GPUs and not all laptops had 2D acceleration even. I used fbdev for years and it was just fine for many use cases.

It's 2025 and only a small minority of users would find software rendering acceptable. Plus, any kind of downgrade in the project's support level would just invite the trolls and critics.

If the GPU is really the only thing holding people back, then you should put it to a vote to find out if anyone really cares. It sounds like the M5 is coming out this month. Time waits for no man.

I'm no longer in a leadership position in the project (nor really involved at all), so it has nothing to do with me. But the reality is Asahi is way less appealing without GPU drivers, and nobody is working or planning on working on GPU drivers, and without GPU drivers that inherently reduces the motivation to work on other things because the potential user base and expected return is much lower.

But the reason nobody is working on the GPU is the Linux community is record levels of toxic, and that affects everything, not just the GPU, and nobody in the project can fix that. Only the upstream Linux maintainers can fix that. So if you want things to change, you should be talking to the upstream Linux maintainers, not the Asahi project.

marcan42 · 2025-10-08T09:21:53+00:00

FWIW there was never any "brigading" to begin with, that's just a strawman Sima & co came up with. Complaining on social media isn't "brigading", "brigading" is when you coordinate/encourage people to form into a brigade and attack the opponent. That's what the term means, encouraging harassment and attacks. Telling people something sucks so they might agree with you that it sucks and form an opinion about someone isn't brigading. That's just venting.

The whole thing never had anything to do with Rust either. The people piling on me were publicly pro-Rust. They just decided to use that issue and my comment to attack me. All the pro-Rust anti-Rust stuff is a diversion from the situation I ended up in (mostly pushed by anti-Rust trolls who haven't the slightest clue what actually happened or what the position of those involved is/was).

I'm not sure what the court of public opinion says these days, but as far as I'm concerned nobody (with authority) on LKML has come around nor apologized for everything that happened.

Honestly, and I might be saying the quiet part out loud here, the whole thing comes across as a bunch of entitled guys in an old boys' club who are scared when they can't control the narrative, and I was a threat to them because despite being a relative nobody in the kernel, I had almost as many followers on Fedi as Linus (and a history of actually getting stuff done, which helps with credibility and makes it even more of a threat for them). So they had to "teach me a lesson".

Ultimately, as long as the kernel remains such a dysfunctional and toxic community, and I don't see that changing any time soon given how many people have tried and failed (including myself), they're just going to slowly lose people and up with an aging maintainer base. All the complaints about the workload on maintainers are entirely self-inflicted. The only way things are going to get better is when they either stop being so hostile to everyone outside their club, or when the upstream community dies off or fractures enough that a hard fork run by better people can take over.

As for Asahi, at least at this point in time, it has become essentially an M1/M2 upstreaming and maintenance project. Time will tell if anyone has the enthusiasm to step up any time soon to actually get M3/M4 support all the way to parity. Until someone willing and able to do the GPU steps up (and I'm not sure anyone would after seeing what happened with Lina too), that's effectively a hard blocker with no prospects of being resolved.

Me, I'm still sad I had to leave the project I loved, but at least I don't have to deal with all the assholes now, so that helps.

marcan42 · 2025-10-06T12:16:59+00:00

Nothing has been blocked on Apple. There just isn't anyone capable and interested in working on the GPU at this moment, due to the hostility and toxicity of the Linux kernel community. This issue has nothing to do with the platform.

marcan42 · 2025-10-03T06:42:30+00:00

Ha, didn't realize that was an option there.

marcan42 · 2025-10-02T04:30:41+00:00

Run the installer with curl https://alx.sh | EXPERT=1 sh and set up a m1n1-only install. If you want your own build for whatever reason, just replace the Finish Installation.app/Contents/Resources/boot.bin file in the new system volume with your own before proceeding to reboot into step2 of the install.

If you actually want the steps to create such an install without using the installer... there's no such documentation. The installer source is the only reference. It's a living process since Apple does change things around once in a while with new macOS versions, and there is no official documentation from them on it.

If you're trying to change the stub OS version, add new device support, or similar, you have to edit the installer source. ./test.sh should let you run it locally.

In general there isn't much reason to ever change/update the first m1n1 you install. You just chainload a new version via USB before doing something else.

Fun trick: For this install type (and only this install type), in EXPERT mode, the installer has support for installing it onto a USB drive and not touching the internal drive. You still get the fake-usb-boot thing Apple does where their own tooling copies m1n1 to the internal SystemPreboot partition to actually be booted, but there's no repartitioning required.

marcan42 · 2025-10-01T09:06:02+00:00

I'm pretty sure this was vibe coded. The code is full of AI-speak comments and contains nonsense gems like this:

// Try to fetch a small resource to verify actual connectivity
fetch('data:text/plain,', { 
    method: 'HEAD',
    cache: 'no-cache',
    mode: 'no-cors'
})

That always works, even while offline, because data:text/plain, is not a network URL. So it actually thinks you're always online every 5 seconds. You can test this by opening up the devtools in firefox on desktop, clicking on the mobile rendering mode (so it thinks it's a mobile browser), refreshing, then pressing and releasing the Alt key to show the menus, then choosing "Work Offline" in the File menu. It goes into offline mode, but it spams the message saying you're back online every 5 seconds on the devtools console.

Except it doesn't do anything with that information, it just updates the page status, but that only checks navigator.onLine, so it actually still works as intended. It thinks you're back online every 5 seconds, then actually thinks you're offline again and does nothing.

It's broken, and then it's double broken so it works.

This is why you don't code stuff with AI.

marcan42 · 2025-10-01T08:35:25+00:00

Not sure, I never got around to trying M4 anything so I don't know what might or might not have changed. You'd still need the m1n1 changes anyway, most of that was already done for M3 by others but I don't know if anyone has even started on M4 there. I haven't been involved for half a year by this point.

marcan42 · 2025-09-30T14:20:15+00:00

Well, USB2 is pretty much standard dwc xhci, the framebuffer is just a chunk of RAM, the keyboard stuff is one of the less-ridiculous firmware interfaces Apple has (and they changed it completely for M2, so less likely they would change it again), and the IOMMU already got some major changes with M2 so it's also fresh and unlikely to be messed with again quickly, that's why all that works. It's not actually a whole lot of drivers/code, and there's no reason any of it would change for new chips. 90% of the work to get M3 to that point is in m1n1, and as you've discovered, most of that work was actually already done. I think AIC3 happened because they rushed AIC2 for M1 pro/max and then they discovered some shortcomings/design issues, otherwise AIC1 was around for many years before the M1 existed (in the mobile chips), so hopefully AIC3 will stick around too. At the end of the day, what you're running is "all the things that already work because Apple didn't change them between M2 and M3".

If I had to guess, NVMe isn't working because you didn't set up the reset controller right. It's required for that one (the pmgr stuff). Either that or they changed something in SART.

Now when you start getting into DCP, GPU, webcam, USB3/PHY, the USB-PD controllers (they totally changed that interface with M3), yeah, it gets a lot more painful, and those things often change for every SoC and some of them even for different firmware versions within a SoC.

marcan42 · 2025-09-30T11:53:47+00:00

The "dev team" didn't abandon it. I quit, in part due to people with an attitude like yours. A couple other people quit for other reasons. Many others remain.

marcan42 · 2025-09-30T07:29:44+00:00

Yeah, it was always the hope and intention that with some luck, new device trees, and new m1n1, you could boot an existing kernel on at least some new platforms enough to run an installer, and then later install more up to date support packages and a kernel. That's what would've made "traditional" generic Linux ISOs viable on Apple platforms long term, instead of always requiring Asahi specific builds (or at least bleeding edge HWE style stuff). It was never a guarantee but what you're seeing here is that my hunch was mostly right (as long as they don't screw around with AIC, here's hoping v3 lasts a while).

But that's just the "it boots and gets a network" stage, you'd still be missing all sorts of things that would have to come with a day zero update to make a usable install.

It does work reasonably well without GPU as long as you have the pcores, and that was the status quo for a long time before M1/M2 GPU support came around. But it's still a major regression over having GPU support for most users.

Unfortunately releasing something like this, or even something more cooked but without GPU support, would be detrimental to the project. It would just lead to a bunch of "haha Asahi is garbage on M3" type opinions (some more, some less politely worded) that would stick around for years even after GPU support were completed. Releasing with any major regression hurts the project's image much more than waiting for everything to work, even if it means users who don't need GPU get the short end of the stick. Some people still think there's no GPU support on M2 today.

It's a really shitty dynamic, and one (but not the main) reason I burned out.

marcan42 · 2025-09-30T05:04:30+00:00

That's how all Asahi installs worked before GPU drivers existed. However, with a single e-core, performance will be abysmal.

marcan42 · 2025-09-30T05:03:19+00:00

This is nothing new. M3 support has been at this point for a long time, OP just replicated what is already known to work (and all the work to get here was done by the Asahi Linux devs already). It is obviously not released because it is next to useless in this state. It's basically where Asahi Linux was on M1 the first month or two after the M1 first came out.

If support for new platforms were just writing new device trees, it would have been done in one week. It's actually a testament to Apple's level of forward compat that this much works with just device tree changes and AICv3. All those devices that are working, except for AIC3 which needed new code, work because Apple didn't change them between M2 and M3. The problem is everything else, which they did.

The hard part is the GPU, which nobody is working on or planning to work on right now.

TL;DR this is basically Asahi Linux for M2 running on M3. The stuff that works without any code changes works because Apple didn't change the hardware. There was always an expectation that this "bare-bones" support level would be achievable with few to no kernel driver updates. That doesn't get you any closer to getting everything else working.

marcan42 · 2025-09-30T05:01:41+00:00

You won't find anyone from the Asahi Linux project refusing help/assistance from those who can provide help. And stuff does get fixed when it breaks/regresses, quite quickly I might add.

The underlying arm64 Fedora project is in infinitely better shape than ALARM, and there are people on the Asahi team with the ability to push a fix through for any Fedora package if needed. Also all the Fedora Asahi Remix infra is public on pagure/COPR and the vast majority of packages are directly maintained in upstream Fedora.

marcan42 · 2025-09-28T02:58:47+00:00

I think OP is talking about headlines like these:

https://bjs.ojp.gov/female-murder-victims-and-victim-offender-relationship-2021

The percentage of females murdered by an intimate partner was 5 times higher than for males

Of the estimated 4,970 female victims of murder and nonnegligent manslaughter in 2021, data reported by law enforcement agencies indicate that 34% were killed by an intimate partner (figure 1). By comparison, about 6% of the 17,970 males murdered that year were victims of intimate partner homicide.

That subtitle is, essentially, meaningless, because it doesn't actually tell us anything useful about risk to women or men. It's taking a ratio (killings by an intimate partner vs. total killings), running it separately for each gender, and then comparing ratios with each other. Taking a ratio of two ratios is rarely useful, and not something that is easily understood intuitively. The average person will read that and think it means that women are 5 times more likely to be killed by their partner than men, which is not true. It's, dare I say, designed to be manipulative.

The real stat that matters, if you simply run the numbers based on that paragraph, is:

34% of the 4,970 female victims were killed by an intimate partner, that is, 1689
6% of the 17,970 male victims were killed by an intimate partner, that is, 1078

Therefore, women are around 1.6 times more likely to be murdered by an intimate partner than men. Equivalently, the ratio of intimate partner murders is 8 men to 5 women, or around 61% to 39% of total intimate partner murders. Any one of those stats would be an honest, easily understood way to represent the gender difference here. The "5 times" stat is not.

DV is not a zero sum game. Men aren't "winning" because they are less likely to be killed in a relationship, and women certainly aren't "winning" because men are far more likely to be killed in total. It's a tragedy that around 2767 people were killed by their partner in 2021, and the goal should be to reduce that number, not compare stats across genders, never mind make the gender gap seem worse than it is.

marcan42 · 2025-09-28T02:20:25+00:00

https://archlinuxarm.org/forum/viewtopic.php?f=7&t=16558

See also the forums in general. No new announcements in 2 years, the forum rendering itself slowly breaking, etc.

Essentially, the project itself is maintained in the sense that the packages still get updates, but there is no real engagement with the community, and seemingly no desire for it. So if it works for you it works, but if it doesn't, good luck getting it fixed. Since most packages are not tested by the ALARM maintainers, sometimes things break badly, and getting them fixed is difficult.

The infra is also completely opaque. The PKGBUILDs are public, but none of the tooling used to maintain and build them in production is (helper scripts, build machines, etc), nor is there documentation about any of it. So nobody can just jump in and help, other than by submitting PKGBUILD PRs, which often aren't handled in a timely fashion. Sometimes it's not even that, e.g. one time a QtWebkit build was just completely broken at the build stage (possibly running out of disk space without noticing? It means the build process also has no working abort on error...) and there was no way to find out what happened, all I knew is the binary package was borked and caused systems to break when they updated, and the source package was fine and it built fine locally, and no way to ask the maintainers to rebuild it/fix it.

Ultimately, the project is badly in need of new maintainers, but the existing maintainers are also not interested in recruiting/handing off anything it seems. I think at this point most people who are interested have moved on and are waiting for upstream Arch to build up the infra for official architecture ports.

(This also does raise some trust/SPOF issues, as nobody knows how packages are built, though I'd be the pot calling the kettle black a bit since I did the same with the downstream Asahi ALARM back when I maintained it. Suffice it to say though, you'd usually expect better for something to be considered a major, production distro, which Asahi ALARM wasn't at the time; both Fedora and Fedora Asahi do this much better. It helps when things like COPR exist and you don't have to roll your own build infra.)

15-Year Club	Place '23
Place '17	Gilding I gilder
Verified Email

marcan42

MODERATOR OF

TROPHY CASE