Fedora Asahi Remix first impressions(jasoneckert.github.io)
jasoneckert.github.io
Fedora Asahi Remix first impressions
https://jasoneckert.github.io/myblog/fedora-asahi-remix/
137 comments
I think so, X13s can become extremely hot and are slower.
Only things still lacking for single machine use is speakers, microphone and webcam: https://github.com/AsahiLinux/docs/wiki/Feature-Support
Only things still lacking for single machine use is speakers, microphone and webcam: https://github.com/AsahiLinux/docs/wiki/Feature-Support
[deleted]
Interestingly, for some modern Intel laptops, webcams/microphones aren't supported either, as they use the custom IPU6 protocol.
I think it depends. For me, fanless is super appealing. However, I have a Dell XPS 13 7390 with a i7-10710U where the fan is at 0 RPM most of the time I use it, and that is super satisfying to me. However, during a big compile, the fan does come on, sometimes it comes on at a high speed. But then, within about 30s to 1 minute, it goes back down to 0 RPM. I'm pretty happy with this, even though I love even more the idea of a computer that didn't even need a fan.
It's also worth pointing out that you can change the power governor in Linux whenever you want, so if you don't mind the compilation taking longer you can manually just throttle your PC to keep it silent at the cost of performance.
I believe so, but I would stick to the M1 models currently as they have a larger set of supported features complete at this time: https://github.com/AsahiLinux/docs/wiki/Feature-Support
Yes. X13s is less-powerful, has worse battery life, and I think even costs more…
> seems the other ARM option is the ThinkPad X13s
Seems there is a bunch of Windows laptops from Dell, Lenovo and Samsung besides the X13
https://www.qualcomm.com/products/mobile/snapdragon/pcs-and-...
Seems there is a bunch of Windows laptops from Dell, Lenovo and Samsung besides the X13
https://www.qualcomm.com/products/mobile/snapdragon/pcs-and-...
they all have lower specs than M series, the Samsung and Thinkpad ones are the only two that have 16G of RAM. I think Macbooks are objectively superial in this ARM race, for now
If you don't mind skimping on speaker quality or, depending on model, screen resolution, I will again recommend lg gram laptops. I never heard the fan on my first, and my second only comes on if it is charging a low battery while on a video call, and even that is quiet compared to the helicopter noise of the last MacBook pro I had through my last employer.
> even that is quiet compared to the helicopter noise of the last MacBook pro I had through my last employer.
It's worth noting that this MBP was almost certainly an Intel model. The new ARM-based Apple laptops rarely have audible fans. This isn't to discount your recommendation, however.
It's worth noting that this MBP was almost certainly an Intel model. The new ARM-based Apple laptops rarely have audible fans. This isn't to discount your recommendation, however.
It did leave me confused why people recommend Mac's, after I had to use them again for work in 2017, replaced with an even worse 2019 edition. The hardware was down the toilet in terms of keyboard quality and heating to uncomfortable temperatures.
I completely understand where you're coming from, I hated my 2019 also. It was quite warm even on idle. If a external display was connected the GPU had a bug where even at idle it used a lot of power and the whole machine was hot hot hot. Any work what so ever would make the fans unpleasantly audible.
M1/M2 Macs are in a completely different league. I'm on a 16" M1 Max and it is just a dream from a noise / temperature point of view. The fans _never_ come on during normal web dev work. And the laptop is cold to the touch. I only hear the fans come on during gaming and heavy compiling.
M1/M2 Macs are in a completely different league. I'm on a 16" M1 Max and it is just a dream from a noise / temperature point of view. The fans _never_ come on during normal web dev work. And the laptop is cold to the touch. I only hear the fans come on during gaming and heavy compiling.
To speak to this: I’ve triggered my 14” M1 Max MacBook Pro fan in two scenarios: Stable Diffusion, and Minecraft. At no point have I heard it run when I’ve been doing Actual Work.
There are also the Windows Qualcomm snapdragon laptops and ARM chromebooks
Does it have to be a laptop? For desktop systems, there are many more options.
Haha, classic
I'm not aware of many fanless desktops outside of specialty systems.
Most are DIY, anything that is low wattage can be turned fanless if you buy some parts and build it yourself. But OP was daft with his answer. As someone who doesn't like the Apple ecosystem and only uses PC, I can only admit defeat when it comes to power efficiency. There is no way you could make a true fanless system run as well as Apple's efficient SOCs. PC parts that are as powerful generate a lot more heat and even with the best fanless cases and radiators there is only so much you can do to dissipate heat.
Is it really that bad?
When semi-idle (just typing in a browser), turbostat on a i9-10900T system shows values that fluctuate around these values:
When semi-idle (just typing in a browser), turbostat on a i9-10900T system shows values that fluctuate around these values:
PkgWatt CorWatt GFXWatt RAMWatt
4.86 3.89 0.15 1.57
2.21 1.40 0.02 1.41
Maybe industrial applications for dust-heavy environments or avoiding movable parts in a general make up most of the fanless niche, but some manufacturers offer desktop-like system as well. Desktop-like because extensibility is limited: these systems are typically built around mini-ITX boards, and the passive cooling solution may have limited options for cooling SSDs. Sustained CPU performance can be quite good, particularly with the Intel T series or the AMD equivalent.
DIY is a bit hit-or-miss because if you want a truly silent system, you need select components for absence of coil whine, and I haven't found a good way to do that yet.
DIY is a bit hit-or-miss because if you want a truly silent system, you need select components for absence of coil whine, and I haven't found a good way to do that yet.
[deleted]
I highly recommend a NUC with a fanless case from Akasa.
Fedora has been really doing an incredible job at creating a great distro for everyday use.
I kinda regret going back and forth between debian and ubuntu when ubuntu started getting shitty, should have moved to fedora eons ago.
I kinda regret going back and forth between debian and ubuntu when ubuntu started getting shitty, should have moved to fedora eons ago.
Fedora is definitely a great distro that I've used a lot in the past. However, there are two main caveats from my POV:
1. The release of a version every six months. (I would prefer at least a yearly release for being sure that things are gonna be matured enough)
2. The fact that Red Hat is behind. (At this point, having seen the CentOS debacle, I don't trust them long term that much)
1. The release of a version every six months. (I would prefer at least a yearly release for being sure that things are gonna be matured enough)
2. The fact that Red Hat is behind. (At this point, having seen the CentOS debacle, I don't trust them long term that much)
Re point #1; ``dnf system-upgrade'' just works.
Also, if you're concerned about stability you can just follow one release behind. That is, upgrade to Fedora 38 after Fedora 39 comes out - after it has gotten 6 months of polish.
Sure, use unsupported OS. You can always install Windows XP for maximum stability.
I have never used Fedora, I use Arch on my desktop and really enjoyed it on my macbook. It's kind of sad the Arch developers didn't want to put more effort into supporting alarm.
If Arch is totally dropped by Asahi team it's unlikely I'll continue using linux on my macbook at all. I just have better things to do than manage multiple distros.
If Arch is totally dropped by Asahi team it's unlikely I'll continue using linux on my macbook at all. I just have better things to do than manage multiple distros.
Having used Arch heavily in the past, “better things to do” is heavily at odds with “using arch”
Doesn't match my experience at all. I love that packages are always up to date. Also, in my experience, having a rolling release cycle leads to significantly fewer issues than having to upgrade everything at once. Using Arch has been a net time saver for me compared to something like Ubuntu where I've wasted a lot of time fighting package upgrade issues and trying to get newer package versions than the distro provides.
In my limited experience, how Arch works out depends on how you're using Linux. If it's your daily driver and you stay on top of updates it's probably going to be fine, but on the other hand if it's a secondary OS on a multiboot system or a VM or something that only gets updated occasionally, chances of things breaking are much higher and something like Fedora might make more sense.
There would definitely be issues with the keyring being outdated which you have to know/search how to work around. And from time to time Arch also requires some manual interventions in the package update process (that are posted on archlinux.org) – you'd have to deal with those all at once if Arch wouldn't have been updated for a very long time. But, other than that, I can't think of other reasons why having a less often used Arch installation would give you trouble.
Then again, I haven't used Arch in such a manner, so you might as well be right.
Then again, I haven't used Arch in such a manner, so you might as well be right.
I use arch and update sporadically and this hasn't really failed me:
- when Arch moved plymouth to their main repos
- when switching from a 1070 to a 4070 I needed to recompile my nvidia drivers
sudo pacman -Sy archlinux-keyring && sudo pacman -Syu
- when Arch moved plymouth to their main repos
- when switching from a 1070 to a 4070 I needed to recompile my nvidia drivers
I dug some old computers out of the attic recently. The one that had not been updated since 2021 only took around half an hour to get up to speed, and that was with a metric ton of packages installed.
The other one seemed to have been updated last time in 2015. It didn't even have updated certificates for https, so it couldn't sync the keyring. After trying for a while I just gave up and reinstalled Arch from a USB stick.
The other one seemed to have been updated last time in 2015. It didn't even have updated certificates for https, so it couldn't sync the keyring. After trying for a while I just gave up and reinstalled Arch from a USB stick.
> old computers
> not updated since 2021
> not updated since 2021
The computer itself was from 2011, and it was last used in 2021.
These two are not the only two options: the nix model is clearly superior and is not as error prone as each.
I use Nix on an ARM single-board computer to host a personal Matrix homeserver (and a bunch of bridges), and I absolutely love it. It's invaluable to have a reproducible specification of the whole system, including custom software to build, in a single place.
That being said, for day to day stuff Arch (and Nix standalone) works well enough for me, to be weary of switching my daily driver PC to Nix, out of the fear of dealing with unforeseen issues and maybe encountering less well maintained packages (there's always something broken on Nix unstable, but maybe it's not an issue for more popular stuff). So I'm sticking to Arch for non-servers for now.
That being said, for day to day stuff Arch (and Nix standalone) works well enough for me, to be weary of switching my daily driver PC to Nix, out of the fear of dealing with unforeseen issues and maybe encountering less well maintained packages (there's always something broken on Nix unstable, but maybe it's not an issue for more popular stuff). So I'm sticking to Arch for non-servers for now.
nix is so clearly superior and yet nobody uses it. curious!
Sometimes the better solution takes time to reach the masses.
Here we talk about a tiny percent of the tiny 3% of desktop users.
Here we talk about a tiny percent of the tiny 3% of desktop users.
> nix is so clearly superior and yet nobody uses it. curious!
If you're going to be snide, you should at least be correct - or are the 6300 users in the main matrix chat room just hanging out for fun?
(sent from my nixos daily driver)
If you're going to be snide, you should at least be correct - or are the 6300 users in the main matrix chat room just hanging out for fun?
(sent from my nixos daily driver)
It's not like 6300 is anything but statistical noise compared to the number of Linux users out there.
The number of Arch Linux users is nothing but statistical noise compared to the number of Windows users; would you say that nobody uses Arch?
In that context, if, that is, the comparison involved Windows user share, then yes.
Hell, even in a Linux-only context too. I mean, an exchange like:
- We're shipping this enterprise software in packages compatible with RHEL and Ubuntu, would it be worth our while to also devote resources to specifically support Arch too?
- Nah, nobody uses Arch
While not accurate to the maximum possible precision (something like say 5% of Linux users is not the same as 0%), it would still be quite understandable...
Hell, even in a Linux-only context too. I mean, an exchange like:
- We're shipping this enterprise software in packages compatible with RHEL and Ubuntu, would it be worth our while to also devote resources to specifically support Arch too?
- Nah, nobody uses Arch
While not accurate to the maximum possible precision (something like say 5% of Linux users is not the same as 0%), it would still be quite understandable...
Fedora is better at keeping packages up to date than Arch.
In particular, Fedora is much quicker to adopt the latest compiler toolchain releases.
> something like Ubuntu where I've wasted a lot of time fighting package upgrade issues
The irony. You’re aware Arch its policy is to release packages in a broken state and just put it in the release log? They even very publicly state that.
If you want an actually stable rolling release, stick with OpenSUSE.
The irony. You’re aware Arch its policy is to release packages in a broken state and just put it in the release log? They even very publicly state that.
If you want an actually stable rolling release, stick with OpenSUSE.
> You’re aware Arch its policy is to release packages in a broken state and just put it in the release log? They even very publicly state that.
Can you please provide some sources/examples?
Can you please provide some sources/examples?
I’ve done a lot of distro hopping in the last couple of years, and I always seemed to spend a lot longer managing the environment rather than doing the work (which was an issue when I was freelancing…). Indeed Arch is the only one that ended up with a massive folder in a notion notebook for guides and how tos.
good on you (or anyone) having a clean and efficient process on Arch - but really, this is not the same YMMV for everyone with all software stacks. can someone whose entire worklife came to a halt gradually over weeks on Arch, please add here?
As far as I'm concerned, "better things to do" is heavily at odds with "using Linux".
Seriously, I spend more time when using Linux trying to get the computer to work instead of actually doing anything constructive with it.
Seriously, I spend more time when using Linux trying to get the computer to work instead of actually doing anything constructive with it.
I think this depends on what you’re doing. Working in software dev and using a lot of containers, anything other than Linux would be a PITA
As I mentioned in my blog post, I also really like Arch. And I definitely understand the benefits to sticking to a single distro on multiple systems.
But as a long term Fedora user who used Arch as a daily driver for a year and a half because of Asahi, and now just switched back to Fedora because of Asahi, I have a solid appreciation for the benefits that Fedora provides over Arch.
In short, I like Fedora more than Arch (and I really like Arch). Of course, everyone is different, but if you start using Fedora Asahi Remix, there's a good chance you'll put Fedora on everything after a few weeks... just like me, Linus Torvalds, and everyone else who joined the dark side ;-)
But as a long term Fedora user who used Arch as a daily driver for a year and a half because of Asahi, and now just switched back to Fedora because of Asahi, I have a solid appreciation for the benefits that Fedora provides over Arch.
In short, I like Fedora more than Arch (and I really like Arch). Of course, everyone is different, but if you start using Fedora Asahi Remix, there's a good chance you'll put Fedora on everything after a few weeks... just like me, Linus Torvalds, and everyone else who joined the dark side ;-)
Just curious, is there something similar to AUR on Fedora? It's a big selling point for me.
Fedora has "Cool Other Package Repositories" or COPR. They're a place for community members to build and publish arbitrary RPM packages. Some are well curated and high quality, others less so.
Thanks for mentioning this! I heard of COPR a while back but never really explored it until this morning after I saw your mention. It definitely could be considered an alternative to AUR/PKGBUILD for Fedora (and it has >24,000 packages already hosted on https://copr.fedorainfracloud.org/).
Do I understand it correctly that it also builds the user provided packages? I guess that's similar to [0] but having something (semi?) official is pretty nice.
[0] https://wiki.archlinux.org/title/Unofficial_user_repositorie...
[0] https://wiki.archlinux.org/title/Unofficial_user_repositorie...
vast majority of stuff in the aur has no arm version, how about COPR?
The AUR and PKGBUILDs are pretty much just an Arch thing.
But on a distro like Fedora, where the default repo is fairly complete and well-groomed (with the odd package hosted in a 3rd party repo), having something like the AUR is a moot point IMO.
I love Arch, don't even know how many years I used it. But Fedora really is more polished, if only because it's the distribution with more paid contributors, by far. I suggest you give it a go. Also, in practical terms, Fedora has better ARM support.
I used Fedora on my last laptop, really enjoyed it, it does adopt the bleeding edge quickly though. E.g., the default files filesystem was Btrfs, and no X just Wayland.
But it was really stable, I think I only hit one issue that was fixed within a week or so. Guess it's a benefit of Red Hat's "patch upstream first" philosophy.
But it was really stable, I think I only hit one issue that was fixed within a week or so. Guess it's a benefit of Red Hat's "patch upstream first" philosophy.
Shouldn’t this distro require little management?
AFAIK, the main Arch Linux project isn't very interested in supporting the ARM architecture at all. This decision probably has more to do with that than anything else.
Arch is unusual in that it's x86-64 only, so going from 1 to 2 is probably a lot harder than other distros just adding the nth new architecture.
The world is moving away from the AMD64 architecture fast, and Apple Silicon M-series chips are the high end of the current state of the art in ARM chips. If Arch Linux is ever to adopt ARM, working with Asahi would have been a smart move.
[deleted]
Why would you have to "manage" them? Install it, then use it.
I put it on my M1 MBP for all of 15 minutes before giving up - I did not have high expectations as I am aware it's cutting edge stuff but it wasn't even remotely usable for me as a daily driver - the touchpad was wonky, konsole kept crashing and also anything drawing on the screen was annoyingly slow. Maybe the desktops work better?
Good on them for trying and I don't mean this as a discouragement but realistically I just don't believe there will be a day anytime soon where it works even as good as standard Linux distro on a x86 laptop now a days. After all not even recent Intel Mac Laptops worked well with Linux.
Good on them for trying and I don't mean this as a discouragement but realistically I just don't believe there will be a day anytime soon where it works even as good as standard Linux distro on a x86 laptop now a days. After all not even recent Intel Mac Laptops worked well with Linux.
Konsole keeps crashing everywhere, though. Don't use KDE.
Hmm I have used KDE on all my other desktops for quite some time now and maybe it has crashed couple times and always when using some obscure feature, not open and crash like here.
Unrelated with the main topic, but I had years without seeing a website with its own personality. I liked it :)
I have been playing with Asahi since the day it became available but it does take much away from the hardware purchase not having internal audio support. Work in progress as expected and perhaps one day I can daily drive it.
Asahi works well on desktops, but isn't ready for laptops IMO.
Sleep isn't stable yet, for example.
Sleep isn't stable yet, for example.
What's the status of sleep mode/battery life/trackpad feel on Asahi at this point? Last time I tried it those were the biggest blockers.
You can find all that information here: https://github.com/AsahiLinux/docs/wiki/Feature-Support
I will say the the battery life on my Mac Studio sucks - as soon as I unplug it from power, it turns off.
I will say the the battery life on my Mac Studio sucks - as soon as I unplug it from power, it turns off.
It doesn't really say if the trackpad works properly there and I didn't see anything about battery life.
Frankly I find this statement from the blog post extremely hard to believe:
> All the hardware works
Really? The webcam? Touchpad gestures? Fingerprint reader? Bluetooth? Thunderbolt?
Frankly I find this statement from the blog post extremely hard to believe:
> All the hardware works
Really? The webcam? Touchpad gestures? Fingerprint reader? Bluetooth? Thunderbolt?
I'm using a Mac Studio... and yes, all the hardware works (10G Ethernet, Bluetooth, WiFi, HDMI, USB, sound, etc.)
Battery life on the Mac Studio sucks though ;-)
Battery life on the Mac Studio sucks though ;-)
Does the Mac Studio have an internal battery?
To quote Hamlet, Act 3, Scene 3, Line 87: “No.”
A coin cell, presumably for the clock and not much else: https://youtu.be/TYF527DqnwY?t=139
[deleted]
What does "container" mean in this context? It is used often and it seems to mean partition, but perhaps not exactly. Is this new overloaded APFS terminology?
> seems to mean partition
> Is this new overloaded APFS terminology?
Yes and yes. It's like a PV in LVM, or a partition in ZFS or BTRFS. What Apple calls an APFS volume is like a logical volume in LVM, or a BTRFS subvolume.
Edit: Had this backwards, at first.
> Is this new overloaded APFS terminology?
Yes and yes. It's like a PV in LVM, or a partition in ZFS or BTRFS. What Apple calls an APFS volume is like a logical volume in LVM, or a BTRFS subvolume.
Edit: Had this backwards, at first.
Here's an explanation with graphics: https://bombich.com/kb/ccc5/working-apfs-volume-groups
However, if you've used ZFS, APFS containers are essentially identical to the concept of a ZFS dataset.
However, if you've used ZFS, APFS containers are essentially identical to the concept of a ZFS dataset.
No, this is inside-out. APFS containers are the partitions, and the APFS volumes live within them. ZFS datasets don't live on the partition table but within a ZFS filesystem.
Your link makes this clear as well.
(When I tried to go from memory I wrote it out backwards at first, too.)
Your link makes this clear as well.
(When I tried to go from memory I wrote it out backwards at first, too.)
It's not inside out - a ZFS filesystem lives within each ZFS dataset (including the root one), and the root ZFS dataset can be comprised of other ZFS datasets, each with their own ZFS filesystem and properties (yet have access to all the space available in the root ZFS dataset).
For example, if you create a 'data' ZFS dataset that uses some storage device (which will be mounted to /data and contain a ZFS filesystem), then 'data' is the root ZFS dataset for that associated storage.
And if you then create a 'data/stuff' ZFS dataset, then the /data/stuff directory is a separate ZFS filesystem that shares the same underlying storage as the 'data' ZFS dataset.
This is also why the root ZFS dataset (e.g., 'data') is always displayed separately in the output of the 'zfs list' command (which displays all datasets on the system).
An APFS container is like the root ZFS dataset (e.g., 'data'), and the APFS volumes within this APFS container are like the ZFS datasets within the root ZFS dataset (e.g., 'data/stuff'). However, unlike ZFS (which can create a single dataset from virtually any number of devices/partitions/files), APFS containers are normally just created from a single big partition (slice) on the Apple SSD. And because APFS containers aren't just partitions, you can't just delete the container using 'diskutil erasevolume' - you must instead use 'diskutil apfs deleteContainer'.
For example, if you create a 'data' ZFS dataset that uses some storage device (which will be mounted to /data and contain a ZFS filesystem), then 'data' is the root ZFS dataset for that associated storage.
And if you then create a 'data/stuff' ZFS dataset, then the /data/stuff directory is a separate ZFS filesystem that shares the same underlying storage as the 'data' ZFS dataset.
This is also why the root ZFS dataset (e.g., 'data') is always displayed separately in the output of the 'zfs list' command (which displays all datasets on the system).
An APFS container is like the root ZFS dataset (e.g., 'data'), and the APFS volumes within this APFS container are like the ZFS datasets within the root ZFS dataset (e.g., 'data/stuff'). However, unlike ZFS (which can create a single dataset from virtually any number of devices/partitions/files), APFS containers are normally just created from a single big partition (slice) on the Apple SSD. And because APFS containers aren't just partitions, you can't just delete the container using 'diskutil erasevolume' - you must instead use 'diskutil apfs deleteContainer'.
Ah, I see what you mean now and this makes sense! I was overlooking the root dataset and probably slightly misusing the term 'filesystem' in a way that your usage made clear. What I was calling a 'filesystem' I should have called 'the root dataset'. So both APFS containers and APFS volumes are like ZFS datasets.
Thanks very much for the detailed reply!
Thanks very much for the detailed reply!
Thanks. As far as I can tell, a "container" is simply a GPT partition and APFS allows logical volumes to be created within. Not unlike LVM, ZFS, BTRFS, etc.
Is anyone aware of plans to port Asahi changes to make other linux distros, i.e. Ubuntu, and others, to be able to run without additional setup on M1 Macs?
Asahi changes are being done in such a way as to be upstreamable, at which point any kernel derived off of mainline will pick up their fixes, so eventually detault Ubuntu will run on Apple Silicon. Expect a custom kernel that can be setup with a bit of work before then though.
An Ubuntu port already exists
Nice post.
Wondering if/when dependence on macOS will be eliminated? I don’t mind a small recovery partition on disk for… what, firmware updates? But otherwise would prefer macOS get completely out of the way.
Is that a thing that is possible, or will we always be reliant on an “activated” macOS?
Wondering if/when dependence on macOS will be eliminated? I don’t mind a small recovery partition on disk for… what, firmware updates? But otherwise would prefer macOS get completely out of the way.
Is that a thing that is possible, or will we always be reliant on an “activated” macOS?
If I understand it correctly, that partition is not loading macOS, and is necessary for loading any OS — Asahi Remix, macOS, etc.
https://github.com/AsahiLinux/docs/wiki/M1-vs.-PC-Boot
https://github.com/AsahiLinux/docs/wiki/M1-vs.-PC-Boot
It is technically possible to remove macOS after installing Fedora Asahi Remix, leaving Linux as the sole OS, but this is not recommended to ensure that you can always update the firmware and recover the system.
To install Fedora Asahi Remix, however, you must have macOS to run the installer script and prepare the system for use.
So, the best solution is to shrink macOS to the minimum possible size during installation and use the remaining space for Fedora Asahi Remix should you wish to forget about macOS altogether.
To install Fedora Asahi Remix, however, you must have macOS to run the installer script and prepare the system for use.
So, the best solution is to shrink macOS to the minimum possible size during installation and use the remaining space for Fedora Asahi Remix should you wish to forget about macOS altogether.
Thanks. How does Apple bootstrap the system in the first place when inserting a blank SSD? Or perhaps you bought a replacement part?
I don't see how that could be done if it is true—that the system is bricked/unrecoverable if the macos partition is lost. Surely it can boot from USB or something?
Perhaps not, this wiki page linked above implies the iboot can't handle usb or external storage:
https://github.com/AsahiLinux/docs/wiki/M1-vs.-PC-Boot
I don't see how that could be done if it is true—that the system is bricked/unrecoverable if the macos partition is lost. Surely it can boot from USB or something?
Perhaps not, this wiki page linked above implies the iboot can't handle usb or external storage:
https://github.com/AsahiLinux/docs/wiki/M1-vs.-PC-Boot
Read further down. DFU prevents bricking.
Yes, just got to that part, thanks.
Investigating DFU, apparently it needs a second laptop to bootstrap it, like a mobile device. I don't like the idea, but it won't happen often, hmm.
Investigating DFU, apparently it needs a second laptop to bootstrap it, like a mobile device. I don't like the idea, but it won't happen often, hmm.
Only happened once to me, when i wanted to get out of beta builds.
You’ll need it for firmware updates.
Can you not do that from recovery on external media, just like installing the OS?
Nope. iBoot doesn't support USB at all (including for OS installation), presumably to reduce the vulnerability surface area. While annoying, this makes sense, as the USB stack is quite complex.
Apple Silicon Macs can boot from USB, kind of, depending on your definition of "boot"--they have to first boot an OS from the internal hard drive and then boot the OS on the USB.
Apple Silicon Macs can boot from USB, kind of, depending on your definition of "boot"--they have to first boot an OS from the internal hard drive and then boot the OS on the USB.
>my peripheral devices work
I would live a little more detail on this.
I would live a little more detail on this.
I use a Lenovo TrackPoint II Bluetooth keyboard and Logitech MX Master 3 Bluetooth mouse, as well as a massive Bose sound system.
Also which year of Mac Studio are we talking about here.
The answer you seek is in the output of neofetch in the screenshot ;-)
You should go to jail for using that font haha
That font is difficult, had to force it to change in the browser
Page completely unreadable in dark mode. Very Web 1.0 website, in the worst sense.
Why help Red Hat at all when they are becoming more like IBM each day?
Because I'm evil ( •̀ᴗ•́ )و
Just kidding - I understand the recent hate directed at Red Hat and IBM, but there are always two sides to every story: https://www.lpi.org/blog/2023/07/30/ibm-red-hat-and-free-sof...
Fedora is an excellent distribution, my second favourite F-word, and a sage choice for providing a polished long-term experience on Apple Silicon.
Just kidding - I understand the recent hate directed at Red Hat and IBM, but there are always two sides to every story: https://www.lpi.org/blog/2023/07/30/ibm-red-hat-and-free-sof...
Fedora is an excellent distribution, my second favourite F-word, and a sage choice for providing a polished long-term experience on Apple Silicon.
Fedora contributors are the ones maintaining the packages and they might have more work now if something breaks on the M1. This only "helps" Red Hat in that they can get more testing on ARM.
Exactly. And users help them by testing and submitting bug reports, posting on forums/lists, etc. So my question stands, why help IBM at all in any way when you know what that is feeding into?
From TFA
"But the main reason is that there have been many issues surrounding the maintenance of ARM packages for Arch Linux, and that the Fedora team is both capable and willing to provide provide the support needed to provide a truly polished Linux experience on modern Macs (the main goal of the Asahi Linux project). By moving to Fedora, the Asahi team can focus on reverse engineering Apple hardware while the Fedora team can focus on maintaining the distribution itself on the Apple Silicon platform. This combination of Fedora with the Asahi boot components and drivers for Apple Silicon is called Fedora Asahi Remix."
This is a bidirectional relationship, the Asahi linux developers also benefit from the people and infrastructure in Fedora.
"But the main reason is that there have been many issues surrounding the maintenance of ARM packages for Arch Linux, and that the Fedora team is both capable and willing to provide provide the support needed to provide a truly polished Linux experience on modern Macs (the main goal of the Asahi Linux project). By moving to Fedora, the Asahi team can focus on reverse engineering Apple hardware while the Fedora team can focus on maintaining the distribution itself on the Apple Silicon platform. This combination of Fedora with the Asahi boot components and drivers for Apple Silicon is called Fedora Asahi Remix."
This is a bidirectional relationship, the Asahi linux developers also benefit from the people and infrastructure in Fedora.
I'd rather help Debian and not see my work help IBM sell RHEL based on Fedora in the future.
Do you help Debian then?
I'm guessing not, unless they consider using it and possibly complaining "helping".
Guessing based on what, the assumption that people who complain never do anything useful? I won't speak for others, but I've submitted bug reports and patches to other distros and also avoid RH projects.
based on the person using a throwaway account to make the statement, coupled with the tendency for people to complain about things online but never actually file bug reports.
While Red Hat may have started Fedora, and does draw from it when building RHEL, it is a community-led distribution through and through. At this point boycotting Fedora because you don't want to support Red Hat is about as sensible as boycotting Debian because you don't want to support Canonical.
Is using Asahi helping Redhat? Or is Redhat helping you use Asahi?
RIP stability for Asahi
It seems the other ARM option is the ThinkPad X13s, which presumably has lower performance.
Anyone have experience running linux on these machines and can compare the experience and hardware compatibility?