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.
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 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.
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.
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.
Mostly it's around the second line with the lower values. Of course, when under load, PkgWatt can go up to close to 100W (depending on the system tuning), but if the cooling solution can handle that for a sufficiently long time, is this really a problem? After all, this CPU, while somewhat dated, is not actually slow, especially for multi-threaded workloads.
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.
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.
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.
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.
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.
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.
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...
> 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.
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 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 ;-)
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.)
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'.
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. 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.
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?
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.
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:
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.
Oh shite! It turns out it is actually a thing. Asahi is going all in on Fedora. I'm definitely surprised and also now a person who is not at all interested in Asahi Linux anymore. Good luck I guess?????
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?
"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.
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.
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?