jrgd

Adding to compatibility notes, it does seem that with the 2015 A1502’s there won’t be anything major in poor compatibility, beside the webcam not working out of the box. Found someone who documented their experience heavily tuning their Fedora install on their 2015 A1502. The author kitted out their Mac with a new SSD and better Wi-Fi card, which is worth mentioning. Some of the information is straight up helpful for even a standard A1502. Common stuff like installing the RPMFusion libva driver, EasyEffects equalizer presets, TLP are generally good ideas.

Mbpfan is also a good idea, but it looks like the package got dropped on 44 from a missing maintainer. May be recommended to install 43 for now if going with Fedora. I pulled the package source and built it on my computer, and it seems to work. Unfortunately I don’t have an actual Macbook to test it on. I’ll see about getting a COPR repo for it available soon, so that the package can be easily tested.

I have a Copr repo available (jrgd/mbpfan) for unofficial packages on Fedora 44.

Some stuff, like disabling mitigations, throttled, and installing the FacetimeHD drivers are not stuff I’d really recommend. You can still go with any of these noting the caveats listed for each tweak. The FacetimeHD drivers are required for getting the webcam to work, so going through the hassle of getting those drivers to behave or just not having a built-in webcam is a choice to make.

Probably your best bet for something similar in vein to MacOS would be any distro that ships with GNOME. Ubuntu, Fedora, Debian, OpenSUSE Tumbleweed all either ship explicitly with GNOME or have them as options within their live installers.

If you know which model and spec your Macbook is, I could give better compatibility insights. In short, the Broadcom chips used for Wi-Fi, Bluetooth in the 2014-2015 Macbooks used to be quite problematic for many Linux distros, but I do believe the in-tree bcm43xx driver in the kernel should handle them well enough nowadays. Depending on exact year and spec, your Macbook may come with an NVidia GPU, which will require additional post-installation steps to install the proprietary drivers on many distros. As it isn’t the primary display device on those models, there shouldn’t be too many issues in getting the cards to function and render offloading to work.

You can absolutely swap the primary boot entry in the BIOS by hand, but as mentioned, GRUB can be made to show an entry for Windows 10 upon normal boot. You can select that entry rather than swap the primary target in the BIOS, which will be a time saver when switching OS. Some configuration to get GRUB to pick it up will likely need to be done however.

For that to work, one needs to uncomment a line in /etc/default/grub (#GRUB_DISABLE_OS_PROBER=false becomes GRUB_DISABLE_OS_PROBER=false). If the line simply isn’t present in /etc/default/grub, just add it at the bottom.

Finally, for systems like Linux Mint, run update-grub with sudo to rebuild the bootloader entries. With os-prober enabled in /etc/default/gruband the Windows EFI partition mounted if relevant, update-grub should show a warning about os-prober being enabled and among other entries, an entry for Windows 10 should be present. As long as the Windows drive continues to be installed in the system, a boot entry should be available next to your Linux Mint and bios entry options in GRUB going forward.

Generally, if they are fully on separate drives, things should be fine. When going to install Windows for the dual boot, physically unplug or uninstall the Linux drive. After Windows is installed and can boot, you can then reinstall the Linux drive.

On the Linux side, you may need to trigger a rebuild for GRUB or your preferred bootloader to get the appropriate Windows 10 entry to show in the boot menu. Some distros may need extra configuration to get this to work. Don’t attempt to automount any partitions from the Windows 10 side and don’t generally try to mount them unless necessary. The only exception to this is if using EFI partitions, then that partition will need to be mounted for GRUB to see it.

Also highly recommended to block Windows 10 from connecting to any network if possible, as it is end of life (unless using ESU releases).

EDIT: Somewhat incorrect information in regard to EFI partitions, missing GRUB configuration related to distro

Originally when I started the move to Linux in 2015, I did it because Windows 10 was wholly incompatible with my ISP. I lived through dial-up, HEO satellite, HSPA, LTE, fixed wireless, and currently fiber. During the period with dealing with HEO satellite, every provider at the time in the US (WildBlue/Exede/Viasat, Hughesnet) had alright speeds at best paired with a very aggressive soft monthly data cap (10 GB, eventually 26GB in like 2018), that would revert the speed capabilities back to 32-96kbps. Upgrading from Windows 7 to Windows 10 was largely a mistake for many reasons, but one of them was the sheer frequency, size, and aggressive nature of how Windows 10 tried to download and apply updates automatically. Windows 10’s frequent auto updates would easily eat several gigabytes each month of the tiny data cap. The rest of the amount of idle networking Windows 10 did also didn’t help during throttled periods, eating up most of the bandwidth available from just one workstation. Knowing that Windows 10 wouldn’t be another Windows 8 and that Microsoft would go forward with 10, I decided to seriously look into alternatives.

Eleven years later, I have virtually no restrictions in hardware nor networking. Despite that, I still use Linux exclusively. Nowadays, there is little to no compromise in using a Linux-based system for many general tasks. Certain niches vary in usability on Linux, especially if the niche is cemented in certain proprietary software. Modern Linux-based systems (both distro and desktop environment) are just more polished than the experience to be had on Windows 10 or Windows 11. Many common frustrations when using Windows (device driver installation, printers, drawing tablets, HDR, system updates, software updates, system maintenance, lack of dark patterns, error message clarity, etc.) are things that a modern Linux system deals with a lot less, to a lesser extent, or just not at all. After spending many years learning both Windows and Linux, Linux systems are just more functional and easier to use.

Using the AUR largely expects users to understand the basics of shell/BASH scripts, which is what a PKGBUILD is. The most obvious source to check is what URL(s) the PKGBUILD is pulling in for a package’s source(s). Are these URLs sourced from official or otherwise trusted sources for the application or component (such as from the app author’s download site or their git forge)? Does the PKGBUILD make any claims of what is being downloaded and does the target URL’s contents match that? If either of these checks fail, it’s best to avoid that package.

Additionally, does the PKGBUILD attempt to do things like obfuscate data such as URLs or tokens for downloading? Does it attempt to recklessly delete or modify files/directories (rm -rf, other recursive functions)? Does the PKGBUILD make use of any arbitrary execution statements such as exec or spawning subshells? If any of these check true, the package should seriously be revised before attempting to install it. System-level software installs on Linux systems should never be complicated enough to need fancy execution techniques nor reckless file management.

If Google kills AOSP, a lot more than just GrapheneOS will stop being able to exist lest some entity maintains a fork that diverges from Google’s path. Vendors that aren’t shipping in line with Play Services and the rest of the ecosystem as well as LineageOS and other custom ROM development teams will suffer as well.

This kind of decision would essentially kill adoption of Android in a good number of countries within a few years as well as be the end of Android adoption for anyone that cares about security and/or privacy. Yes, It would either kill or put a large burden upon GrapheneOS as a project, but that is also true for so many other projects in the ecosystem. If the developers shutter their AOSP usage due to upstream abandonment, the users will likely follow in the same pattern.