I’ve just put Omarchy Quattro on this laptop, and I’ve spent long enough poking at its bar widgets, its keybindings, and its frankly enormous plugin ecosystem that I think it deserves a proper write-up. Not a “top 10 tips” listicle — a proper look at where it came from, why it’s built the way it is, and why the keyboard-first approach feels so alien for about three days and then completely inevitable.
A Brief History of Omarchy
Let’s start with the obvious question: why does a web framework author end up building a Linux distribution?
The creator of Omarchy is David Heinemeier Hansson — universally known by his initials, DHH. If you’ve touched web development in the last twenty years, you’ve almost certainly used something he built: he’s the creator of Ruby on Rails, released in 2004 and still one of the most influential web frameworks ever shipped. He’s also a partner and CTO at 37signals, the company behind Basecamp and HEY, and a prolific writer — co-author of Getting Real, Rework, Remote, and It Doesn’t Have to Be Crazy at Work. Outside of code, he’s also a competitive endurance racer, having driven at the 24 Hours of Le Mans multiple times.
Omarchy itself is the second act of a pattern DHH started with Omakub, a similarly opinionated setup script for Ubuntu. Omarchy takes the same “omakase” philosophy — the chef decides, you don’t customise a hundred knobs before you can start working — and applies it to Arch Linux with the Hyprland compositor on top. The project went public in mid-2025, and by the time the “Quattro” release (version 4.0) landed, it had accumulated tens of thousands of GitHub stars and thousands of commits, a genuinely startling growth curve for something that started as one developer’s personal dotfiles.
The Omacom Foundation and the $8 Million Question
Here’s the bit that turned Omarchy from “a cool personal project” into “a project with a runway”: the launch of the Omacom Foundation, a nonprofit set up to hold Omarchy’s trademarks and fund its infrastructure. It launched seeded with $8 million, contributed by eight patrons at roughly a million dollars each.
The patron list reads like a greatest-hits of tech founders, which is worth expanding properly rather than just listing:
| Patron | Why it matters |
|---|---|
| Tobi Lütke (Shopify) | Runs one of the largest Ruby on Rails deployments on the planet — a direct beneficiary of DHH’s earlier work, now backing his OS. |
| Patrick Collison (Stripe) | Payments infrastructure that most of the internet quietly depends on; a signal that serious platform-builders see something in Omarchy beyond hobbyist appeal. |
| Michael Dell (Dell) | Hardware royalty backing a distro that has to run on real, physical, occasionally awkward laptops — not just VMs. |
| Jack Dorsey (Block, ex-Twitter) | Known for his own minimalist, terminal-heavy personal setups; a natural philosophical fit for a keyboard-first OS. |
| Matthew Prince (Cloudflare) | Runs infrastructure for a huge chunk of the web; funding the “edge” of the desktop stack, if you like puns. |
| Brendan Iribe (Oculus co-founder) | Brings a hardware/VR pedigree, relevant given Omarchy’s growing hardware-compatibility ambitions. |
| Jason Fried (37signals) | DHH’s long-time business partner; the “we built this together” money. |
| DHH himself | Put his own million in alongside the others, rather than just accepting funding — a statement about skin in the game. |
Why does this matter for a blog post about a Linux desktop? Because a distribution that lives or dies on one developer’s spare time and taste is a hobby project, however good it is. A distribution backed by a foundation that owns its own trademarks and has multi-million-dollar runway is a project that can survive its founder having a busy month. It’s also, frankly, a bet: DHH’s own stated goal is nothing less than making “The Year of Linux on the Desktop” finally, actually true. Bold. We’ll see.
Installing It: Why It’s Genuinely Fast
I want to be precise here rather than just say “it’s quick,” because the why is more interesting than the that.
A standard from-scratch Arch install is famously an evening’s work: partitioning, base package selection, bootloader configuration, network setup, picking and configuring a display server, picking and configuring a compositor or full desktop environment, then hours more making it look and feel coherent. Omarchy collapses essentially all of that into a single scripted pipeline, and real-world install times reported by reviewers running the full ISO-to-desktop flow land anywhere from under two minutes on fast hardware to around eight or nine minutes on more modest machines — a dramatic difference from a manual build.
Here’s the mechanism behind that speed, broken down properly:
| Stage | What actually happens |
|---|---|
Bootstrap (boot.sh) | A single curl | bash one-liner sets the correct package mirror (stable/rc/edge depending on channel), installs git, and clones the Omarchy repository straight into ~/.local/share/omarchy. No manual partitioning dialogue to fumble through at this stage — it’s scripted end to end. |
| Preflight validation | Before touching your disk, the installer checks you’re actually on Arch, on x86_64, not already mid-install, and not running as root. This front-loads the failure cases instead of discovering them halfway through a package install. |
| Packaging stage | Rather than you individually pacman -S-ing forty packages one at a time and resolving dependency questions as they come up, Omarchy ships a curated, pre-resolved package manifest — base system, fonts, editors, terminal UIs, web-app registrations — installed in one coordinated batch via its own omarchy-pkg-add helper. |
| Configuration stage | Theming, Git defaults, GPG, timezone sync, PAM hardening, keyboard layout detection, Docker setup — all of this is templated and copied into place from ~/.local/share/omarchy/default/, rather than hand-edited. You get a fully-themed, fully-configured system, not a blank slate you then have to decorate. |
| Hardware detection | The installer actively probes for known hardware quirks — Apple T2 security chips, Framework laptops, ASUS/ROG machines, NVIDIA GPUs — and applies the relevant driver packages and kernel parameters automatically, rather than you discovering your trackpad doesn’t work three days in. |
| Login & bootloader | Sets up Plymouth splash screens, hooks Btrfs/Snapper snapshots into the Limine bootloader for safe rollback, and configures autologin-friendly PAM settings — all the “nice to have but nobody bothers” polish. |
The genuinely clever bit is that none of this is exotic engineering — it’s just that somebody sat down and made all four hundred small decisions once, wrote them into idempotent scripts, and now you inherit the result in minutes instead of making the same four hundred decisions yourself over a weekend. It’s the same trick Rails pulled on web frameworks: convention over configuration, just applied to /etc instead of /app.
Hyprland: What It Actually Is, and Why It’s Not Just “A Theme”
This is where people coming from Windows or a standard Linux desktop tend to get confused, so let’s be precise about the architecture.
GNOME and KDE Plasma are full desktop environments: a bundled compositor (Mutter for GNOME, KWin for KDE), a settings framework, a panel/taskbar, a file manager, a notification daemon, a session manager, and a huge pile of first-party applications, all developed together and expected to be used together. You install “GNOME” and you get an entire coherent stack, most of it configurable through GUI settings panels.
Hyprland is not that. It’s a standalone Wayland compositor — the single component responsible for drawing windows on screen, handling input, and managing workspaces. It ships with none of the rest: no panel, no launcher, no file manager, no notification daemon, no settings app. Omarchy’s job — and it’s a substantial job — is bolting all of that infrastructure onto Hyprland itself: a Quickshell-based bar and widget system, walker as the app launcher backend, mako for notifications, grim/slurp for screenshots. What you get in Omarchy isn’t “Hyprland” in isolation, it’s Hyprland plus a curated stack of small, focused Unix tools wired together into something that feels like a desktop environment without actually being one monolithic codebase.
The practical differences that actually matter day to day:
| Aspect | GNOME / KDE | Hyprland (via Omarchy) |
|---|---|---|
| Window management model | Floating by default — windows overlap, you drag and resize them, and moving between them means visually hunting and clicking. | Tiling by default — windows automatically arrange to fill the screen with no overlap, and you navigate between them with keyboard commands rather than mouse hunting. |
| Configuration surface | GUI settings panels, System Settings/dconf, mostly point-and-click. | Plain-text config files (Lua, in Omarchy’s case) — every setting is a line of code you can read, version-control, and copy to another machine instantly. |
| Animation philosophy | Deliberately smooth, often several hundred milliseconds of transition on window/workspace switches, prioritising visual polish. | Near-instant by default — workspace and window switches are effectively immediate, prioritising the perception of a snappy, responsive machine over eye candy. |
| Resource footprint | Heavier — a full DE stack with many background services running whether you use them or not. | Considerably lighter — you’re running roughly what you’ve configured and not much else, which is part of why Omarchy runs comfortably on older hardware. |
| Customisation approach | Extensions/widgets bolted onto a stable core, often fighting the DE’s own opinions. | The whole stack (bar, launcher, theme, keybindings) is yours to edit directly as config, with Omarchy providing sane, swappable defaults rather than a locked-down shell. |
None of this makes Hyprland “better” in some abstract sense — it makes it a different tool for a different way of working, which brings us to the actual crux of the adjustment.
Why Keyboard-First, and Why the Adjustment Is Real
“Keyboard-first” gets thrown around a lot, so let’s define it properly rather than leave it as a vibe.
In a keyboard-first workflow, every action that changes your window layout, switches your focus, or launches an application has a keyboard shortcut that’s faster than reaching for the mouse — and, crucially, the system is designed on the assumption that you’ll actually use those shortcuts as your primary interaction method, not as a rarely-touched accessibility feature bolted onto a mouse-driven system. Windows and macOS both have keyboard shortcuts, obviously, but they’re a secondary layer over a fundamentally pointer-driven interaction model — window resizing, precise placement, and most app-switching still assume a mouse is involved somewhere.
Hyprland (and Omarchy’s configuration of it) inverts that assumption entirely. Windows tile automatically, so there’s no dragging edges to resize. Workspaces are a first-class navigation primitive, not an afterthought, so switching your entire screen’s context is one keypress rather than a mouse trip to a taskbar. Launching an application means a keypress and typing a few characters of its name, not moving the pointer to a dock and clicking an icon.
Why does this matter enough to be worth the friction of relearning? Two genuinely measurable reasons:
- Latency. A keyboard shortcut executes in milliseconds and requires no visual search — your hands never leave the home row and your eyes never have to hunt for a target. A mouse action requires visually locating a target, moving a limb across a physical distance proportional to how far away that target is on screen, and then precisely landing on it. That’s not a trivial difference when you’re doing it hundreds of times a day; it compounds into a genuinely different rhythm of work.
- No animation tax. Because there’s no need to visually orient yourself after a mouse-driven jump, Omarchy’s Hyprland config keeps transitions near-instant. Compare that to the roughly half-second animation delay that’s become standard on macOS when switching Spaces — deliberately smooth, but a real, repeated tax on every context switch across a working day.
The adjustment is genuinely real, though, and I won’t pretend otherwise. The first few days involve a lot of “how do I close this window again” and “where did my mouse cursor’s usual job go.” Muscle memory built over years of dragging, dropping, and clicking doesn’t evaporate in an afternoon. Most people who stick with it report it clicking into place somewhere around the one-to-three week mark — the point where your fingers start reaching for Super+something before your hand has consciously decided to reach for the mouse. It is a genuine skill you build, not a preference you toggle.
Core Keybindings, With Actual Explanations
Every binding in Omarchy centres on the Super key (the Windows/Command key) as the main modifier — this keeps it clear of application-level shortcuts that use Ctrl and Alt, so there’s no clash with, say, your editor’s own keybindings.
| Binding | What it does, in detail |
|---|---|
Super + Return | Opens a new terminal window. This is deliberately the single most-used binding in the whole system — Omarchy is built by and for people who live in a terminal, so instant terminal access gets the “easiest to press” slot on the home row. |
Super + W | Closes the currently focused window. No confirmation dialogue, no hunting for a small “x” in a corner that’s a different position on every application — one consistent keystroke, from anywhere, always in the same place. |
Super + Space | Opens the Omarchy menu — a searchable command palette for launching apps, switching themes, adjusting the background, and reaching most system functions without ever touching a mouse. Think of it as a Spotlight/Alfred equivalent, but native to the compositor itself rather than a bolted-on third-party app. |
Super + F | Toggles the focused window to full screen. Because windows tile by default rather than floating loosely, “full screen” here is a genuinely useful, frequently reached-for state rather than a rare edge case — it’s how you temporarily give one task your entire display. |
Super + [1–9] | Switches directly to workspace 1 through 9. Combined with Super + Shift + [number] to move the focused window to a given workspace instead, this is the core of how you organise your work: editor on one workspace, browser on another, chat on a third, and jumping between them is a single keystroke rather than Alt-Tab roulette through a pile of overlapping windows. |
Plugins: Where Omarchy Stops Being “A Distro” and Starts Being “A Platform”
This is genuinely one of the more surprising parts of the ecosystem, and it’s grown fast enough to warrant its own community registry at omarchyplugins.com — a searchable, browsable directory where you can inspect a plugin’s source before installing it, copy the install command, and see what’s trending by stars, views, or recent activity. It’s a proper little package ecosystem, not just a folder of gists.
Plugins hook into the Quickshell-based bar and shell layer (bar widgets, overlays, background services), and separately, Hyprland itself has its own plugin system (hyprpm) for things that need to reach deeper into the compositor. I’ve installed a fair pile of both kinds. Here’s an honest look at six of the most interesting ones currently running on this machine:
| Plugin | What it actually does |
|---|---|
GloView (Hyprland compositor plugin, via hyprpm) | A genuinely polished macOS Mission Control-style overview: hold a modifier and tap Tab to see live, real-time previews of every window across your workspaces, laid out in balanced rows or a grid, then release to jump straight there. It’s not a static screenshot grid — the previews are live compositor output, so a video call or a build log is still visibly updating while you’re picking where to go. It also exposes an “all workspaces” expo view and full keyboard navigation once open. |
Workspace Switcher (io.github.woogy7.workspaces) | A dedicated alt-tab for workspaces specifically, rather than windows — hold a modifier, tap Tab to cycle through live previews of each workspace, and release to commit to one. It deliberately mirrors the muscle memory of classic Alt-Tab, just one level up the hierarchy, which turns out to be a surprisingly natural mapping once you’re used to workspaces being your primary unit of organisation. |
| Better Displays | Per-monitor control over resolution, scale, position, and screen transform, plus per-terminal font size adjustment, all driven straight from the bar rather than requiring a trip into a settings app or manual hyprctl commands. Genuinely useful the moment you plug into an external monitor with a different DPI to your laptop panel. |
| App Launcher (Tyrsolution) | A centred, icon-grid application launcher — closer to a traditional app-drawer experience than the default text-driven Omarchy menu. It tracks installs and removals live and orders results by frecency (a blend of frequency and recency of use), so the apps you actually reach for daily bubble to the front automatically. |
| Caffeine | Does exactly one thing and does it well: a coffee-cup icon in the bar that toggles idle-lock and screensaver suppression on and off. The kind of plugin that exists because someone got mildly annoyed once during a presentation and fixed it properly instead of just disabling idle system-wide. |
| Advanced Audio Control | A genuinely deep PipeWire/WirePlumber mixer that goes far beyond a simple volume slider: per-device and Bluetooth codec management, microphone privacy controls, savable “audio scenes,” persistent routing rules between devices, and built-in diagnostics for when your audio graph inevitably does something inexplicable. This is the plugin that most reminds me a full DE’s control centre has more depth to it than people give it credit for — it’s just usually locked behind a dozen tabs, and this surfaces it from the bar instead. |
The thing that strikes me most about the plugin ecosystem isn’t any single plugin — it’s how easy the whole loop is: browse the registry, inspect the source, run one omarchy plugin add <url> --enable command, and you’re done. Compare that to the GNOME Extensions experience of hunting through a website, checking Shell version compatibility, and hoping the extension hasn’t been abandoned for two major releases. Omarchy’s plugin system feels much closer to installing an npm package than fiddling with a desktop extension — which, again, tracks: it’s built by web developers, for people who think about tooling the way web developers do.
So, Who Is Omarchy Actually For?
Let’s be honest about this rather than pretend it’s for everyone, because it very clearly isn’t.
Omarchy is for developers who are comfortable in a terminal and want their entire machine to work the way their terminal does — fast, text-configurable, scriptable, and unapologetically opinionated rather than infinitely flexible. If you’ve ever found yourself irritated by how long it takes to get a new machine set up “the way you like it,” or you’ve rebuilt the same dotfiles from scratch on three different laptops, Omarchy is explicitly solving your exact problem: it’s the “somebody already made all four hundred small decisions for you” distribution.
It’s particularly well-suited to a few overlapping groups, worth calling out specifically:
- Web and application developers who live in a terminal and an editor most of the day. The entire system is tuned around fast terminal access, fast app-switching, and minimal visual ceremony getting in the way of actually writing code — which makes sense, given it comes out of 37signals, a company that ships production software daily.
- People coming from macOS who liked its polish but got tired of its constraints. Omarchy is explicitly designed to feel beautiful out of the box — proper theming, cohesive fonts, sensible defaults — while giving you the kind of low-level configurability macOS has never allowed. It’s aimed squarely at the “I want it to look this considered, but I want to actually own my configuration” crowd.
- Tinkerers who want Arch’s power without Arch’s onboarding tax. Arch has always rewarded people willing to read the wiki and build everything by hand, and plenty of that community will (fairly) point out that Omarchy users haven’t “earned” their setup the traditional way. Omarchy’s answer to that is blunt and, frankly, correct: the whole point is that you no longer have to spend a weekend proving it to use it well.
- Anyone who’s decided keyboard-driven tiling is genuinely faster and wants an easy, well-supported on-ramp. Tiling window managers (i3, bspwm, dwm, Sway) have existed for years and have always demanded you build your own surrounding ecosystem from scratch — bar, launcher, notifications, screenshots, the lot. Omarchy is the version of that idea where someone else has already built and polished the surrounding ecosystem, so you get the tiling philosophy without the usual bootstrapping tax.
Who it’s emphatically not for: anyone who wants a desktop that behaves identically to what they already know, anyone allergic to occasionally editing a config file, and anyone who needs a specific piece of Windows-only or heavily Mac-only professional software with no Linux equivalent (though the web has quietly closed a lot of that gap in recent years). It’s also worth being honest that it’s still Arch under the opinionated coat of paint — updates move faster than Ubuntu LTS, and the odd rough edge from bleeding-edge packages is part of the deal, even with Omarchy’s own staged stable/RC/edge mirror channels softening that blow.
Closing Thought
What I find genuinely interesting about Omarchy isn’t the Hyprland config or the theming, both of which are very good — it’s the underlying bet the funding represents: that a meaningful chunk of the developer world is willing to hand over root-level opinion about their entire operating system to a project, in exchange for never having to make four hundred small configuration decisions themselves ever again. Rails did that for web frameworks two decades ago. Whether Omarchy manages the same for the Linux desktop is very much still an open question — but with eight million dollars and a foundation behind it now, it’s got a real runway to find out.