A lot of Apple hardware is impressive on paper, but I will never buy a Mac that can't run Linux. I simply don't want to live in Apple's walled garden.
Then there is the whole ARM vs x86 issue. Even if a compatible Linux distro were made, I expect to run all kinds of software on my desktop rig including games, and ARM is still a dead end for that. For laptops, it's probably a sensible choice now, but we're still far from truly free and usable ARM desktop.
> A lot of Apple hardware is impressive on paper, but I will never buy a Mac that can't run Linux.
They run Linux actually very well, have you ever tried Parallels or VMware Fusion? Especially Parallels ships with good softwaer drivers for 2d/3d/video acceleration, suspend, and integration into the host OS. If that is not your thing, the new native container solution in Tahoe can run container from dockerhub and co.
> I simply don't want to live in Apple's walled garden.
And what walled garden would that be on macOS? You can install what you want, and there is homebrew at your fingertips with all the open and non-open software you can ask for.
Last I looked... extensive telemetry and a sealed boot volume that makes it impractical to turn off even if theoretically possible. There are other problems of course.
You can disable SIP and even disable immutable kernel text, load arbitrary drivers, enable/disable any feature, remove any system daemon, use any restricted entitlements. The entire security model of macOS can be toggled off (csrutil from recoveryOS).
Stopping/disabling a service should be a command, like it is on Windows or Linux. Not configured on a read-only volume bundled with other security guarantees.
It's pretty simple to keep these two things separate, like everywhere else in the present and history of the industry.
No, I meant to reply to you. I was curious about your practical use case for disabling code signing (which I think is what you refer to by telemetry) and messing with the boot volume.
From what I checked, disabling SIP/AMFI/whatever it is now means I can't run iOS applications on macOS. The fact that there are restrictions on what I can run when doing that makes macOS more restrictive.
Also, what if I want to run eBPF on my laptop on bare metal, to escape the hypercall overhead from VMs or whatever? Ultimately, a VM is not the same as a native experience. I might want to take advantage of acceleration for peripherals that aren't available unless I'm bare metal.
That point is often brought up, but it kind of invalid. Because you can't run iOS on your Linux or Windows installation, too. So saying because of that usecase you are switching the OS, is kind of a spite reaction, not based on reason.
As in: "I can't run iOS on my macOS installation, so I am going to use a different OS where I can't run iOS either".
Well, it's less of a feature argument, and more of a "I philosophically don't support using an OS that prevents me from using parts of it, because I oppose losing control over the software my system runs."
I switched from pixel to iPhone in large part because pixel removed the rear fingerprint reader, headphone jack, and a UI shortcut I used multiple times a day. It’s not like the iPhone had those things but now neither did the pixel.
How does Asahi fare these days? For home use I am fine with my Fedora machine but as a former (Tiger-SL era) Mac user who's never used macOS, I am somewhat curious about this.
Remember Asahi works properly only on M1 and M2. More work is required to make it run well on later chips (its not just a faster ARM chip - it's new graphics card each time, motherboard chipset, every laptop peripheral changes from time to time, BIOS/UEFI, etc, and they all need reverse-engineered drivers for it work).
... or UTM. I have run windows and Linux on my M1 MB Pro with plenty of success.
Windows - because I needed it for a single application.
Linux - has been extremely useful as a compliment to small arm SBCs that I run. eg: Compiling a kernel is much faster there than on (say) a Raspberry Pi. Also, USB device sharing makes working with vfat/ext4 filesystems on small memory cards a breeze.
It sounds like Linux works fairly well on Strix Halo, which basically gives Apple a run for their money and stays in the nice x86 land. The M1 and M2 chips were envy-inducing chips from the heavens or whatever, but now that the mortals have caught up I don’t really see the point in worrying about Linux on ARM. X86 remains the present, RISC-V is the future.
Meanwhile I finally bought into apple after my nth unsuccessful attempt to break into linux.
I just want a linux-like system that is not mainful to use and apple's is the closest thing that worked for me without resorting to last ditch efforts like sacrificing virgin maidens or newborn kittens on top of my Dell machine... and Apple provides one that just works ... reliably
I came to chime in. I have hardware that apple chooses to willfully upsell me on repairing and $1500 for $35 keyboard repair. Apple as a company is still terrible at recycling and manufacturing obseletion. It is also a walled garden with no choice as to what you can do on your machines.
My point was: we don’t need to list all the reasons we won’t buy apple products on any post about apple, even if it has nothing to do with the article.
Then there is the whole ARM vs x86 issue. Even if a compatible Linux distro were made, I expect to run all kinds of software on my desktop rig including games, and ARM is still a dead end for that. For laptops, it's probably a sensible choice now, but we're still far from truly free and usable ARM desktop.