TLDR; So far so good! I’m not seeing any dealbreakers yet, and the prospects look good for a permanent solution for me.

I have never been a Mac owner prior to this (but have used them for work numerous times). My (new to me) used Macbook Air M2 arrive in the mail yesterday. After making sure all the hardware was functional in OSX, I used the curl based Asahi Linux installer, choosing Asahi Fedora Remix with KDE.

The install:

Very VERY easy! The installer was probably the best Linux installation experience I’ve ever had. Of the 2TB storage I reserved 500GB for OSX, allocated 1TB for Asahi, and leaving 500GB unallocated (plans for later).

The good:

  • The desktop experience is fast and responsive. - I was worried now that I was in ARM (aarch64) architecture, applications I wanted to use would have issues with compatibility. I have zero issues installing and running from simple “dnf install” commands. So far all have aarch64 native builds.
  • I have a functional external display
  • The macbook hardware is high performing, low weight, and great build quality.
  • Battery life looks decent enough for my needs

The bad:

  • External Display: While I mentioned I have a working display, its via an old DL-165 based USB 2.0 Displaylink adapter. It appears to be very finicky with which DVI to HDMI adapter it will work with. Additionally, on first use it doesn’t appear to set up the display properly for the 1920x1080 resolution (the limit of this adapter) but instead defaults to 1650x1080. I’ve been able to fix this with a kscreen-doctor command on the CLI though. I may have to do more to automate this in the future, though.
  • Power management/hibernation: I learned that Asahi not only doesn’t support S4 hibernation (my ACHI sleep profile of choice), but its not even on the development roadmap. I’ve seen a couple of the developer notes as to the difficulties, and it makes sense with the limited resources, so I agree with their path. However, that leaves me with concerns for the life of the hardware. In the days ahead, I’ll explore what I can do from userland to reduce impact on the hardware and cycles on the battery.
  • USB port behavior: The Macboook air only has 2 USB-C/Thunderbolt ports. I understand Thunderbolt isn’t supported yet, and I’m just fine with that. USB3 is plenty for all of my needs at this point. However, the two ports on the unit don’t seem to behave the same. The USB-C port closer to the charging port works with my USB-C hub, USB2 DisplayLink adaptor, and USB2 100Mb/s NIC, and even my USB2 headset/mic. None of these work on the second USB-C port on the Macbook. I would have written this off as bad hardware, but USB-C charging works fine on this port. I need to do more checks from OSX to validate hardware functionality, and more investigation on /var/log/messages to see if I can find a reason for this difference. I did see a developer note that one USB-C port on the Mac is more functional for development, but I don’t know what that means yet.
  • Community: I haven’t found THE PLACE where Asahi users congregate to talk about issues or solutions. I see there’s a Reddit subreddit which has the most (but I have chosen to not post to Reddit anymore, and avoid it as much as possible). There is a Fedora community with some Asahi posts. Lastly, today I found this Lemmy community with a handful of users. I hope to find THE PLACE to best be able to learn from others and share what I’ve learned.
  • lukecycaEnglish
    2·
    21 days ago

    I’m a month in as my daily driver, and much the same experience as you. I’ll be sticking with it despite a few shortcomings.

    Regarding the sleep power consumption, I’m interested to know what you find. Im plugging it in overnight in the meantime.

    Regarding the USBC ports, does the mismatched functionality reset with a reboot? I’m finding that my HP USB-C dock sometimes brings a port down, particularly if I plug and unplug multiple times while sleeping, and then switching ports (or even just flipping the connector) can fix it. A reboot always fixes it all though. I updated my dock firmware and so far it is much improved so maybe it’s more about my dock.

    • partial_accumen@lemmy.worldOP
      1·
      21 days ago

      Regarding the USBC ports, does the mismatched functionality reset with a reboot?

      Very good question. One of many I’ll need to test out in the days ahead. I did make a tiny bit of progress this evening on it.

      So far, nothing I’ve plugged into this USB-C port registered with the operating system except the USB-C AC adapter, and that show dmesg events for charging beginning (and ending when its unplugged). No other devices up until now have shown any activity in dmesg for plug or unplug events…until now. I have an older small USB-A 2.0 4 port hub. I put a USB-A to USB-C adapter on it, and then plugged it into the port. It shows activity in dmesg! I shows the OS detecting the USB hub and registering it! However, nothing plugged into that hub gets recognized. Also, plugging that USB hub (with its adapter) is showing slightly different activity when plugged into the fully working port. Its late and I haven’t done a diff to figure out what lines are missing/different, but it means I have a place to start with clue to follow.

      Regarding the sleep power consumption, I’m interested to know what you find. Im plugging it in overnight in the meantime.

      I’ve got a couple rough approaches I’ll be exploring in the days ahead.

      -I’ll explore what Apple does with their version of sleep/hiberation. Does it conform to the ACPI S-levels? Does Asahi? If so, which ACPI S level is implemented so far? Is it just S1 or does it get as far as S3? Hiberation (suspend to disk) would be S4, which I know it doesn’t do at this time.

      • a script that can be executed on sleep which turns off various hardware devices (like Bluetooth, wifi adapter and more). The current sleep functions may do some of this already, but I haven’t found documentation yet on exactly what the sleep behavior is yet.
      • a way to capture current running apps and the specific files that are open to a file, that then executes a shutdown instead of sleep, so the unit will be truly powered off. Then a corresponding script which can ingest the prior captured “open files/applications” file, and launch all the apps with perhaps even opening the files again. So a poor-man’s hibernation.

      I see that the developers have a debugging serial console available. I may explore setting that up to capture state to an external machine so that I can get more a granular of what is still awake when the unit is in Asahi’s version of sleep.