After leaving Pop 22.04 because it was getting long in the tooth, I spent the last year on CachyOS. Don’t get me wrong - CachyOS is fast and well-optimized, but the rolling release nature eventually caught up with me. When you need your daily driver to just work every day, those occasional breakages from bleeding-edge updates get old fast.
The Rolling Release Rollercoaster
CachyOS delivers impressive performance. The optimized packages and custom kernel configurations genuinely make a difference - everything feels snappier. But that speed comes at a cost when you’re trying to maintain a stable daily driver.
The problem wasn’t CachyOS itself. The distribution is well-maintained and the community is helpful. The issue is inherent to any bleeding-edge rolling release: you’re constantly riding the wave of upstream changes. Most of the time, updates go smoothly. But “most of the time” isn’t good enough when you’re in the middle of work and suddenly your system needs attention.
I found myself checking the forums before updating, reading through changelogs, and occasionally holding back packages. That’s fine for enthusiasts who enjoy tinkering. But after decades in tech, I’ve reached the point where my computer should fade into the background and just work.
The AUR Dependency Trap
Then there’s the Arch User Repository. The AUR is simultaneously one of Arch’s greatest strengths and a source of constant friction. Need some niche software? It’s probably in the AUR. Want the latest version of something? AUR has it. But that convenience comes with baggage.
AUR packages are maintained by users, not the distribution. Quality varies wildly. Some packages are meticulously maintained and build flawlessly. Others break with every minor system update, requiring manual intervention to fix build scripts or dependency conflicts. You never quite know which category a package falls into until you’re already committed to using it.
The dependency chains can get complex fast. Install one AUR package, and it might pull in three other AUR packages as build dependencies, each with their own potential issues. When something breaks - and eventually, something always breaks - you’re left playing detective, figuring out which package in the chain is the culprit.
And then came the DDoS attacks. The AUR getting hit offline repeatedly over the past months highlighted just how fragile this dependency really is. I learned this the hard way when I was rebuilding my system and the AUR was down. What should have been a straightforward reinstall turned into a day-long ordeal, waiting for the service to come back up so I could get the packages I needed. Your system doesn’t break, but you’re dead in the water if you need anything that isn’t in the official repos.
On Pop!_OS with standard Debian/Ubuntu repos, things just work. The packages might not be bleeding-edge, but they’re reliable, well-tested, and the infrastructure is robust enough that I never wonder if the repos will be available when I need them.
The AUR is brilliant for enthusiasts and tinkerers. But when you need your system to be a reliable tool rather than a hobby, the traditional repository model starts looking pretty attractive again.
The Hyprland Dilemma
On CachyOS, I found myself constantly switching between GNOME and Hyprland, never quite satisfied with either choice. Each had what the other lacked, and I couldn’t commit to one or the other.
GNOME felt polished and complete. The workflow is intuitive, applications integrate beautifully, and everything just works together cohesively. But I kept running into the same frustration that’s plagued GNOME for years: extension breakage.
Every time GNOME updated - and on a rolling release, that’s frequently - there was a coin flip on whether my extensions would survive. The extensions I relied on for basic functionality would suddenly stop working, leaving me scrambling to find updated versions or alternatives. Want tiling? That’s an extension. Custom hotkeys? Extension. Better workspace management? Extension. And each GNOME update meant potentially losing any of these.
The GNOME extension ecosystem is simultaneously one of the desktop’s greatest strengths and biggest weaknesses. Yes, you can customize GNOME extensively through extensions. But that customization is built on a foundation that shifts with every update. Extension developers are volunteers racing to keep up with API changes, and users are caught in the middle.
I’d spend time configuring my desktop exactly how I wanted it, getting my workflow dialed in, and then an update would land. Suddenly I’m back to vanilla GNOME, hunting through extension websites, checking compatibility, hoping the features I depend on haven’t been abandoned by their developers.
So I’d switch to Hyprland, attracted by its powerful tiling capabilities and the promise of a configuration that wouldn’t break with updates. Hyprland is genuinely impressive - the tiling behavior is exactly what I want, and the configuration file approach means my setup is portable and version-controlled.
But Hyprland requires tinkering. You’re building your desktop environment from the ground up, choosing each component, writing configuration files, scripting behaviors. For some people, that’s the appeal. For me, after spending a day writing code, the last thing I want to do is debug my desktop environment.
I kept bouncing between the two: GNOME when I wanted things to just work (until the next update broke my extensions), Hyprland when I wanted proper tiling (until I needed to fix some configuration issue). It was exhausting.
Why Cosmic Changes Everything
Pop!_OS 24.04 with Cosmic DE is exactly what I’ve been waiting for: a GNOME-like experience with built-in tiling behavior, written in Rust (which I’m currently learning - bonus!), built on an LTS base that won’t break on me mid-workday.
Cosmic DE solves the extension problem by building the features directly into the desktop environment. Tiling isn’t an extension that might break - it’s a core feature. Workspace management isn’t bolted on - it’s fundamental to how Cosmic works. The features I was relying on extensions to provide are now first-class citizens of the desktop.
The Rust foundation is more than just a technical curiosity for me. As someone actively learning Rust, having my desktop environment written in it means I can potentially contribute or at least understand what’s happening under the hood. The memory safety guarantees and modern architecture give me confidence in the platform’s long-term stability and security.
And crucially, it’s built on Ubuntu LTS. After a year of rolling releases, the idea of a stable base that I can count on for years is incredibly appealing. I can focus on my work instead of managing my operating system.
I’m running the Cosmic beta as my daily driver now, and honestly? It’s been surprisingly solid. Sure, I hit the Mangohud issue for gaming - the overlay wasn’t working initially - but that was literally my last real problem. Everything else has just worked. The tiling behavior is intuitive, the workflow feels natural, and I haven’t had to touch a configuration file or hunt for extensions.
The Verdict (So Far)
Is Cosmic perfect in beta? No. But it’s stable enough for daily use, and it finally gives me the workflow I want without compromise. The LTS foundation means I can actually focus on work instead of troubleshooting updates. The built-in tiling means I’m not dependent on extensions that might break. The polish means I’m not constantly tweaking configuration files. And the reliable, traditional package repositories mean I’m not wondering if I’ll be able to install software when I need it.
After years of bouncing between different distributions and desktop environments, I think I’ve finally found the balance I was looking for. CachyOS served me well and taught me a lot, but I’m happy to be back home on Pop!_OS.
If you’ve been on the fence about trying Cosmic - especially if you’re a tiling WM fan who misses GNOME’s polish, or a GNOME user tired of extension roulette - it’s worth the jump.
