DEV Community

Daniel Kim
Daniel Kim

Posted on

Omarchy Turned Arch Linux Into One Command. Apple Silicon Turned That Command Into a Support Thread.

Omarchy

Omarchy picked up more than 2,200 stars in the past week alone, pushing it past 26,800 total and onto GitHub's weekly trending page — the kind of number that usually belongs to a new JavaScript framework or an LLM wrapper, not a Linux desktop config. It's built by David Heinemeier Hansson (DHH), the person who wrote Ruby on Rails and who runs product at Basecamp and HEY, and it does something that sounds almost too small to justify the attention: it turns a fresh Arch Linux install into a fully configured Hyprland desktop with one command.

The pitch is "beautiful, modern & opinionated Linux," and on a supported machine that pitch mostly holds up. But the most instructive thing about Omarchy right now isn't the install script — it's a 150-plus-comment GitHub discussion full of developers trying to run it on the one class of laptop its target audience is most likely to already own: MacBooks. Watching that thread tells you more about what "opinionated" costs than the README does.

What actually happened

Omarchy isn't new — it's been public for over a year — but it's having a trending moment this week, sitting in GitHub's top-15 weekly list alongside things like public-apis and Basecamp's own omakub. The repo currently shows 489 open issues and 558 open pull requests, which for a desktop-config project is an unusually large amount of live surface area — more typical of a mid-size application than a dotfiles repo. It's MIT-licensed, maintained under the Basecamp GitHub org, and it's the direct sibling of an earlier DHH project, Omakub, which does the same "one command, fully configured desktop" trick for Ubuntu instead of Arch. Omakub sits at roughly 8,100 stars — a third of Omarchy's — which is itself a small signal about which base OS developers actually want this kind of product on.

What it actually does

Strip away the branding and Omarchy is a large, opinionated installer, not a distro image you boot from an ISO. You start with a working Arch Linux system, run Omarchy's install script, and it takes over from there: partitioning assumptions, disk encryption, window manager, terminal, editor, and a curated app catalog, all in one pass.

Concretely, a default install includes:

  • Hyprland as the compositor/window manager (Wayland-based, tiling)
  • Alacritty as the terminal and Neovim with a preconfigured setup as the editor, alongside tmux
  • A curated commercial-app layer — 1Password, Basecamp, ChatGPT, Chromium, LibreOffice, and Spotify are all listed as bundled defaults
  • Dedicated categories in the project's manual for AI tools, TUIs and GUIs, PDF handling, gaming, and even Windows VM support for the rare app that needs it
  • Mandatory full-disk encryption via LUKS — this isn't an install-time checkbox, it's baked into the default flow with no documented opt-out
  • A built-in theming system, with manual sections dedicated to both using the bundled themes and authoring your own
  • An update and migration mechanism, plus system snapshot support, so an existing install can be moved forward rather than reinstalled from scratch

That last point is the most structurally interesting part of the project and the part least visible from the marketing copy. The repository ships a top-level migrations/ directory alongside install/, config/, themes/, and applications/. That's a very Rails-flavored idea transplanted onto a desktop OS: instead of "reinstall when something changes," each new Omarchy release can ship an incremental migration that's applied to your existing machine, the same way a Rails app applies a schema migration instead of rebuilding the database. It's a small design choice, but it's the clearest fingerprint of who built this — someone whose entire professional identity is "convention over configuration," now applied to ~/.config instead of app/models.

There's a second, quieter signal sitting at the repository root that's worth pulling out on its own: AGENTS.md, CLAUDE.md, and an agents/skills/ directory. A Linux desktop-configuration project — not an application, not a framework, a dotfiles-and-install-scripts repo — ships its own instructions for AI coding agents and a folder of pre-built agent skills. That's a small thing, but it's a useful data point on how far "write the CLAUDE.md so an agent can safely touch this codebase" has spread as a default engineering practice by mid-2026: it's not just SaaS backends and API wrappers doing it anymore, it's show up-and-configure-your-desktop shell scripts too. The manual itself even carves out a dedicated "AI tools" category among the bundled default software, separate from the general dev-utilities section — Omarchy treats an AI coding assistant as baseline desktop software in the same tier as a terminal emulator, not as an optional extra.

How it's different from "just install Hyprland yourself"

Hyprland has had a large, active ricing and dotfiles community for a couple of years, and Omarchy is not the first project to wrap an installer around it. JaKooLit/Arch-Hyprland, for example, is a roughly 4,600-star automated installer that layers Hyprland onto an existing Arch (or Arch-derivative) system — but by the maintainer's own description, "this repo does not contain Hyprland dots or configs," it pulls those from a companion repo and leaves package selection editable before you run it.

That's the actual axis Omarchy differentiates on. JaKooLit's project, and most of the Hyprland dotfiles ecosystem generally, treats configuration as something you're expected to inspect and adjust before committing. Omarchy treats configuration as a decision that's already been made for you — theme, terminal, editor, encryption policy, bundled commercial apps and all — and the value proposition is that you don't have to make those decisions yourself. You get a real, coherent, "someone with taste already did this" desktop instead of a scaffold you're expected to finish. It's the same trade Rails made against raw PHP frameworks two decades ago, just applied to a window manager instead of a web stack.

Why this is worth developer attention

Setting up Hyprland well — picking a bar, a launcher, a notification daemon, a lock screen, a consistent GTK/Qt theme, and getting them to actually agree with each other visually — is a multi-day project even for people who enjoy it. Omarchy collapses that into an afternoon, and it does so with genuinely good default taste, which is the part screenshots don't fully convey but the churn of stars this week suggests people are finding out anyway.

The more interesting reason to care isn't the time savings, though — it's what the project says about a specific developer migration pattern that's been building for a while: people leaving macOS for Linux specifically because they want a machine that isn't managed by a vendor's roadmap, and who don't want to spend the first two weeks of that decision fighting a window manager instead of doing the work that made them want to leave in the first place. Omarchy is a bet that a large enough slice of that group would rather adopt somebody else's fully-formed opinion than assemble their own, the same bet Rails made about server-side web frameworks.

Run that through the usual adoption criteria and the picture is mixed in a useful way:

  • Cost: zero — it's MIT-licensed and free, but the bundled commercial apps (1Password, Spotify) still carry their own subscription costs once installed. Omarchy doesn't change your SaaS bill, it just front-loads the decision of which SaaS you'll be using.
  • DX: this is where it actually wins. The gap between "want a tiling Wayland desktop" and "have one that looks intentional" on stock Arch is measured in days of trial and error across GTK themes, bars, launchers, and lock screens. Omarchy collapses that to the length of one install script, and the migrations system means you're not starting that process over on every upgrade.
  • Lock-in: real, but shallow. Because the underlying system is still ordinary Arch and Hyprland config files, nothing stops you from ripping out any single piece — the theme engine, the bundled app list, even the migrations workflow — and running the rest bare. You're locked into a set of starting defaults, not a platform.
  • Security: mandatory LUKS by default is a genuine, unambiguous win over most "quick install" scripts in this space, which tend to treat encryption as an advanced option nobody enables. The tradeoff is control — you can't disable it through the documented flow even when you have a good reason to.
  • Maintainability: this is the open question. A 489-issue, 558-PR backlog on a project moving this fast means "maintainable" currently depends on an active maintainer team staying ahead of a growing, hardware-diverse user base — not yet a settled, boring property of the software the way it is for, say, a five-year-old Ubuntu LTS release.

Practical use cases

The clearest fit is a developer setting up a new machine from scratch — a fresh laptop, a home workstation, a machine being repurposed after years on macOS or Windows — who wants a genuinely usable tiling desktop without spending a weekend on it. Omarchy is also a reasonable choice for standardizing a small team or personal fleet on the same base config: because updates flow through the migrations system rather than requiring a fresh image each time, a solo developer or small shop can keep several Omarchy machines converging on the same defaults without hand-maintaining a dotfiles repo themselves.

It's a weaker fit for anyone who needs a single, shared, long-lived reference machine — a build server, a kiosk, anything where "opinionated and frequently changing" is a liability rather than a feature — and a poor fit today for anyone whose only available hardware is Apple Silicon, for the reasons the MacBook thread makes explicit.

Where the hype runs into hardware

Here's the part that doesn't show up in the pitch: a huge fraction of the developers most likely to want exactly what Omarchy sells — "leave the vendor-managed desktop, keep a coherent, tasteful environment" — are, right now, sitting on Apple Silicon hardware. And Omarchy's relationship with that hardware is close to nonexistent.

GitHub Discussion #155 is a running log of people trying to get Omarchy onto MacBooks via Asahi Linux (the reverse-engineered Apple Silicon Linux project), and it reads like a completely different, much rougher piece of software than the one in the README:

  • The stock install script fails outright on aarch64 because a number of packages Omarchy depends on simply don't have ARM builds
  • Full-disk encryption through archinstall — the mechanism Omarchy leans on by default — doesn't work on Asahi Alarm at all
  • Wi-Fi requires manually installing broadcom-wl firmware by hand
  • GPU acceleration was broken out of the box because the wrong Mesa package got selected for the platform
  • Audio doesn't work
  • The trackpad and keyboard are dead during the LUKS decryption prompt — on a laptop, that's not a cosmetic bug, it's a boot blocker
  • The app launcher (Walker) fails to open via its keybinding on several machines
  • Thunderbolt/USB-C display output doesn't work on Mac minis

The community workarounds are exactly what you'd expect from a project that wasn't built with this hardware in mind: commenting out set -e so the installer limps past failures instead of aborting, manually reinstalling Mesa from the Asahi Alarm repo, setting GSK_RENDERER=ngl as an environment variable to fix the launcher, and eventually a pair of undocumented flags — OMARCHY_ARM=true and OMARCHY_BARE=true — that get you a more reliable, if bare-bones, install. Maintainers engaged in the thread and fixed the Mesa selection issue, and pointed contributors toward upstreaming more of this — but the canonical fix that actually works today is a separate, third-party fork, omarchy-mac, maintained outside the Basecamp org, that only claims solid support for M1/M2 chips; M3 and M4 are explicitly waiting on further Asahi progress.

None of this is a criticism of the maintainers for not solving Apple Silicon support — Asahi Linux itself is still filling in real hardware gaps, and that's arguably not Omarchy's problem to fix. It's a criticism of the framing. "Opinionated" is being sold as a universal virtue — fewer decisions, more taste, no bikeshedding — but what the MacBook thread actually shows is that the opinions were formed against a specific, presumably x86, hardware target, and the parts of "opinionated" that don't survive contact with different silicon (disk encryption flow, GPU driver selection, package availability) are exactly the parts a newcomer has no way to know about until the installer fails midway through.

The tradeoffs the docs don't foreground

A few other constraints are easy to miss reading the manual sections in isolation:

  • No opt-out on full-disk LUKS encryption. That's a reasonable default for a personal laptop and a genuinely bad one for anyone who wants to dual-boot, run this in a VM for testing, or hand a machine to someone who'll forget the passphrase. There's no documented flag to skip it in the default flow.
  • Arch as a foundation is still Arch. Omarchy smooths over the setup pain of Arch, not the maintenance reality of it — it's still a rolling-release distro where a bad upstream package can break your session on an ordinary pacman -Syu. The migration system helps Omarchy-specific config move forward cleanly, but it doesn't insulate you from Arch's own volatility.
  • 489 open issues and 558 open PRs is a lot of unresolved surface for a project whose main promise is "it just works." That volume is a natural side effect of fast growth, but it also means the gap between "the demo" and "your specific hardware" is currently being closed in public, one thread at a time, rather than something you can assume is already solved.
  • The commercial app bundle is a real design choice, not filler. Shipping 1Password, ChatGPT, and Spotify by default is convenient if you already use all three, and dead weight — or a trust question — if you don't. An "opinionated" desktop that bundles proprietary SaaS clients by default is a different kind of opinionated than one that just picks a tiling window manager and a font.

How it stacks up

Omarchy Omakub JaKooLit/Arch-Hyprland Hand-rolled dotfiles
Base OS Arch Linux Ubuntu Arch / Arch derivatives Whatever you already run
Stars (approx.) 26.8k 8.1k 4.6k N/A
Window manager Hyprland (Wayland) GNOME-based desktop Hyprland (Wayland) Your choice
Apple Silicon support Unofficial, community fork only N/A (x86-oriented) Not a primary target Depends entirely on you
Disk encryption Mandatory LUKS, no opt-out Not enforced Optional, user-configured Your call
Bundled commercial apps Yes (1Password, Spotify, ChatGPT, etc.) Curated dev tools, lighter on SaaS No — installer only, no app curation None by default
Config philosophy Fully opinionated, minimal choices Fully opinionated, minimal choices Opinionated installer, editable package list Fully yours
Update model Versioned migrations + snapshots Versioned migrations Re-run script / manual Manual

The honest way to read that table: Omarchy and Omakub are the same philosophy applied to two different base distros by the same author, JaKooLit is a lighter-weight, more editable version of the same underlying idea, and hand-rolled dotfiles are what all of these exist to save you from doing yourself.

An independent read

Omarchy is good software with a marketing claim that's slightly bigger than the product. The engineering is real — the migrations system, the snapshot support, the sheer coherence of the default theme and app choices are not trivial to get right, and the star trajectory reflects a genuine, well-executed idea, not hype for hype's sake. But "opinionated" is doing a lot of quiet work in the pitch. It reads as "we made the good decisions so you don't have to," and for the hardware and workflow it was actually built and tested against, that's probably true. For Apple Silicon owners — arguably the single largest pool of developers curious enough about a DHH project to try it this week — "opinionated" currently means "decisions were made without you in the room," and the MacBook thread is the receipt.

That's not a reason to skip it. It's a reason to know, before you run the installer, which category of user you are.

It's also worth naming what Omarchy gets right that's easy to undervalue precisely because it's boring: shipping working full-disk encryption by default, on a project whose whole premise is "make Linux desktop setup fast," is the kind of decision that's very easy to skip under time pressure and this project didn't skip it. Most "one command, full desktop" scripts in the Hyprland ecosystem treat security as an advanced-user afterthought you opt into later, if you remember to. Omarchy inverted that — encryption is the default and speed is what you have to work for around it — and that ordering says something honest about the project's priorities that the trending-repo star count alone doesn't capture.

Who should actually try this

Try it now if you already run x86 hardware (or a well-supported laptop line — Framework and System76 machines show up favorably in the community discussions around this ecosystem), you're comfortable with Arch's rolling-release model, and you want a tiling Wayland desktop with genuinely good taste applied by default instead of assembled by you over a weekend.

Wait if you're on Apple Silicon and want this as your daily driver — the officially supported path doesn't exist yet, and you'd be running a third-party fork with an M-series ceiling for now, plus the encryption and driver issues documented in the MacBook thread.

Skip it if you need a Linux desktop that's boring in the way enterprise IT wants boring — Arch's rolling-release nature and a 489-issue backlog on a fast-moving opinionated layer are not what "stable" usually means, regardless of how polished the default theme looks.

What's the actual ceiling for "opinionated by default" software once it has to serve a genuinely diverse hardware base — is convention-over-configuration a strategy that only works when the target platform is as narrow as the original decisions that shaped it?

Sources:

Top comments (0)