Migrating from macOS to Linux

level:Beginner

Mac users migrating to Linux start from a better place than they realise. macOS is a Unix system underneath its polish, so the terminal, the shell, the file paths, and the command-line tools all feel familiar from day one — the muscle memory transfers. The friction for Mac users is concentrated somewhere different than it is for Windows users: not in the software, but in the hardware. Apple's move to its own silicon changed what "running Linux on a Mac" means, and getting that decision right is the most important thing in this post.

If you have not read the earlier entries, skim what Linux actually is, how distributions differ, and what a desktop environment is first.

The hardware reality: Apple Silicon and Asahi

This is the decision that determines everything else, so handle it first.

Since 2020, Macs run on Apple's own ARM-based chips — the M1, M2, M3 and successors — rather than the Intel x86 processors they used before. That matters enormously for Linux, because almost the entire desktop Linux ecosystem, and certainly the Arch install this series builds toward, is written and distributed for x86_64 machines. You cannot simply install standard Arch on an Apple Silicon Mac.

The project that brings Linux to Apple Silicon at all is Asahi Linux, a remarkable reverse-engineering effort, since Apple publishes no hardware documentation. Its state in 2026:

• M1 and M2 Macs are well supported. All M1 and M2 MacBook, Mac mini, Mac Studio, Mac Pro, and iMac models are supported, including GPU acceleration — Asahi shipped the first conformant OpenGL, OpenCL, and Vulkan drivers for Apple Silicon.
• M3 and newer are early and experimental. M3 support exists but lacked GPU acceleration as of early 2026, and Asahi's own docs class it as not for the average user yet.
• The flagship is Fedora, not Arch. Asahi began life Arch-based but its supported distribution is now Fedora Asahi Remix. There is no standard "install Arch the normal way" path on Apple Silicon.

⚠️ Warning Asahi's supported distribution is Fedora Asahi Remix, not standard Arch, and M3 and newer Macs are still experimental. If you want to follow this series and install Arch the standard way, do it on an x86 machine, not on your Apple Silicon Mac.

So the practical recommendation is blunt: if you want to follow this series and install Arch the standard way, do it on an x86 PC, not on your Apple Silicon Mac. A second-hand or budget x86 laptop or desktop is the cleanest route. You can run Linux on an M1/M2 Mac via Fedora Asahi Remix, and that is a genuinely good experience for the supported models — but it is a different, parallel path from the one these install posts describe.

Intel Macs are the opposite — and easier — story, and an important one, because many owners do not even realise their Mac is Intel-based. It is worth checking, because the timing matters: macOS 26 "Tahoe" is the last release to support Intel Macs, so from the next version on, macOS is Apple-Silicon only. A perfectly capable Intel MacBook or iMac — often only a few years old — then hits the same end-of-support wall Windows 10 users just did. The difference is in its favour: an Intel Mac is an ordinary x86_64 machine, so it runs mainstream Linux directly, no Asahi required, and the Arch install guide this series builds toward applies to it as-is. If you are on an Intel Mac, you are one of the best Linux switch candidates there is.

The what of this decision is which physical machine you install on; the why is that the architecture determines whether standard Arch can even run; the how is a single check you do before anything else — find out which chip your Mac has and follow the matching branch.

os:macos

On macOS: click the Apple menu () → About This Mac. If the "Chip" line reads Apple M1, M2, M3 (or newer), you have Apple Silicon (ARM); if it reads Intel Core i5/i7/i9 or similar, you have an older x86 Mac. That one line decides your path.

flowchart TD
    A["Check About This Mac"] -->|"Intel chip"| B["Ordinary x86 machine"]
    A -->|"Apple M-series chip"| C["Apple Silicon / ARM"]
    B --> D["Install mainstream Linux<br/>the normal x86 way"]
    C -->|"M1 or M2"| E["Asahi works well<br/><i>but Fedora Asahi Remix, not standard Arch</i>"]
    C -->|"M3 or newer"| F["Experimental, no GPU accel<br/><i>not for daily use yet</i>"]
    E --> G["To follow this Arch guide:<br/>use a separate x86 PC"]
    F --> G
    D --> H["Follow the standard-Arch path"]

Which branch your Mac lands on decides whether you follow the guide as written or move to a separate x86 machine.

Why x86 vs ARM matters here

x86 and ARM are different processor architectures — different instruction sets — and software compiled for one does not run on the other. Most desktop Linux distributions ship pre-built x86_64 packages; ARM desktop support exists but is thinner, and Apple's hardware additionally needs Asahi's bespoke drivers to function at all. This is the same architecture split that made Apple's own transition require the Rosetta translation layer. For a first Linux install, an x86 machine removes a whole layer of complication.

Mapping your Mac apps and tools

Once you are on Linux, the day-to-day mapping from macOS is mostly intuitive. The biggest mental shift is the smallest one for a Mac user, because you already use a Unix shell.

Homebrew, pacman, and apt

If you use Homebrew on your Mac, you already understand a package manager — and that is exactly how you install software on Linux, except the system one covers the entire OS, not just extras. Debian/Ubuntu use apt, Fedora uses dnf, and Arch uses pacman. The mental model is identical to brew install: one command, from a trusted catalogue, with dependencies handled for you. The what is the same action you already take; the why it feels native is that you have been doing this on macOS for years; the how is just new verbs. The direct mental map, the commands you already run on macOS mapped to their Arch counterpart:

• brew install <pkg> → pacman -S <pkg> (install a package)
• brew uninstall <pkg> → pacman -R <pkg> (remove a package)
• brew update && brew upgrade → pacman -Syu (refresh and upgrade everything at once)
• brew search <term> → pacman -Ss <term> (search the catalogue)
• brew tap / casks → the AUR (community-built extras) Arch additionally has the community AUR, which fills the role of Homebrew's vast tap ecosystem. And if you want, Homebrew itself runs on Linux and behaves almost identically to the Mac version, so you can even keep using brew for some tooling during the transition. The difference from macOS is that on Linux the package manager is the primary way you get all software, not a power-user supplement to the App Store.

Finder, Spotlight, Preview, and the rest

Reading the table as a map rather than a list helps: nearly every macOS app you reach for has a Linux home, and the few hard gaps cluster in one corner. The orientation analogy that works best here is that you are not learning a new dock so much as re-labelling the one you already have — Finder is still "the place files live," Spotlight is still "type to launch," the names just change.

flowchart LR
    A["Finder"] --> B["Files / Dolphin / Thunar"]
    C["Spotlight"] --> D["App launcher / KRunner / rofi"]
    E["Preview"] --> F["Document Viewer / Okular"]
    G["iMovie"] --> H["Kdenlive / DaVinci Resolve"]
    I["Homebrew"] --> J["pacman / apt / dnf"]
    K["Mail"] --> L["Thunderbird / Evolution"]

Each macOS app on the left has a Linux home on the right; the workflow stays, only the name changes.

The honest gap, as on Windows, is Adobe Creative Cloud and Apple's own ecosystem-locked apps (Final Cut, Logic Pro, the deeper iCloud integrations). GIMP and Krita are strong but not Photoshop; DaVinci Resolve is a credible Final Cut replacement but a different tool. Check your essential pro apps before committing.

Keyboard, trackpad, and gestures

This is where Mac muscle memory fights you for a week or two, so it is worth naming the differences.

The modifier key. macOS uses Command (⌘) for copy, paste, and most shortcuts; Linux (like Windows) uses Control. So copy is Ctrl+C, not Cmd+C. Mac keyboards have the Command key where you expect to reach for the modifier, which feels wrong at first. The fix is straightforward: most desktops let you remap modifier keys, and tools like keyd can make a Mac keyboard's Command key behave like you are used to. Many Mac switchers remap to keep their reflexes intact.

The trackpad and gestures. macOS trackpad gestures are famously good, and this used to be a real loss on Linux. It is much less so now. Linux input is handled by libinput, which provides natural scrolling, tap-to-click, and multi-touch gestures. Under Wayland (now the default desktop session — see the desktop environments post), three-finger swipes for switching workspaces and opening the activities overview work natively in GNOME, and KDE Plasma has its own gesture support. It is not pixel-for-pixel identical to macOS, and the very smooth inertia and precision Apple tunes by hand is still a notch ahead, but the gap is now small rather than yawning. Enable "natural scrolling" in your settings on day one to match the Mac direction.

What a display session is, briefly

When this post says "under Wayland," it means the graphical session type your desktop runs on. Wayland is the modern Linux display protocol that replaced the older X11, and it is where gesture and high-DPI support are best. You do not need to configure it — modern distributions default to it — but knowing the word helps when you read documentation. The desktop environments post covers this layering in full.

Your Unix familiarity is an advantage

Here is the genuinely good news for Mac switchers. macOS is a certified Unix descended from BSD, so its terminal is a real Unix shell, and almost everything you know transfers directly to Linux: the same cd, ls, grep, ssh, and find; the same pipes and redirection; the same idea of dotfiles in your home directory; the same shell scripting. If you have ever used Homebrew, edited a .zshrc, or ssh-ed into a server from your Mac, you have been using the same fundamental tooling Linux uses. SSH in particular is identical — the protocol that underpins remote work on macOS is the same protocol, the same client, the same keys on Linux. Your ~/.ssh/config will work unchanged.

There are small differences. macOS historically shipped the BSD variants of command-line tools (BSD sed, BSD ls) while Linux ships the GNU variants, so a few obscure flags differ — but the core behaviour is the same, and many Mac developers already install the GNU coreutils via Homebrew anyway, which makes the experiences converge. The point stands: a Windows user is learning the command line for the first time, while a Mac user is just changing which Unix they are on. That head start is real, and it makes the deeper, build-it-yourself Linux path far less intimidating.

A short close

For Mac users the migration question splits cleanly in two. The software side is gentle — Homebrew already taught you package management, Spotlight maps to an app launcher, your terminal and SSH config carry over wholesale, and the application equivalents are mostly good. The hardware side is the one to get right: Apple Silicon Macs run Linux only through Asahi Linux (Fedora-based, excellent on M1/M2, experimental on M3+, and not the standard-Arch path), so to follow this series the cleanest move is an x86 machine. Get that decision right and lean on your Unix head start. From here, when you want the deepest hands-on path, the Arch install companion walks you through it end to end, starting with the case for why Arch.