The Arch Acolyte’s Reckoning: Why This Wong Edan Dared to Nix It All

Alright, you digital denizens and command-line connoisseurs, gather ’round. It’s your favorite ‘Wong Edan’ tech sage here, ready to spill the beans – not just any beans, mind you, but the piping hot, somewhat existential crisis-inducing beans of my recent operating system migration. For what feels like an eternity, but which I can reliably confirm was approximately a decade (source), I’ve been an Arch Linux devotee. A proud, pedal-to-the-metal, ‘I-build-it-myself-and-like-it-that-way’ Arch user. We, the Arch folk, we’re a special breed, aren’t we? We love the control, the minimal base, the feeling of truly understanding every cog in our digital machine. But even the most devout acolytes sometimes hear the whisper of a new god. For me, that whisper became a roar, an irresistible siren song promising reproducibility, atomic upgrades, and a declarative nirvana: NixOS.

Yes, you heard that right. I, a grizzled veteran of the Arch school of thought, decided to embark on the perilous, yet profoundly rewarding, journey of migrating from Arch Linux to NixOS. It wasn’t a snap decision; it was a slow burn, a gradual erosion of my Arch-induced complacency, fueled by an insatiable curiosity and perhaps a touch of digital masochism. This isn’t just a tale of switching desktops; this is a saga of re-learning, re-thinking, and re-configuring my entire digital existence. Strap in, because we’re about to dive deep into the silicon trenches, explore the configuration files, and emerge, hopefully, enlightened – or at least with a system that actually boots.

The Lure of the Declarative Beast – Why Even Consider NixOS?

A decade. Ten glorious years of Arch Linux, building my environments piece by painstaking piece, troubleshooting every pacman hiccup, and perfecting my dotfiles like a digital artisan (source). So, what on earth possessed me, a card-carrying member of the Arch Illuminati, to even glance in the direction of something as radically different as NixOS? The answer, my friends, lies in a single, tantalizing word: declarative. Arch, for all its glory, is fundamentally imperative. You tell it what to do, step-by-step: install this, enable that service, configure this file here. It’s powerful, but it’s also mutable, prone to drift, and recreating an identical environment on another machine or after a disaster can be a painstaking process of memory and meticulous notes.

NixOS, on the other hand, flips the script entirely. It’s not about how you get to a state, but what that state should be. You describe your entire system – kernel modules, services, user environments, desktop setup, installed packages, even your specific SSH security keys – in a single, unified configuration file written in the Nix language. This concept of a system configuration file, tailored precisely to your needs, is the cornerstone of NixOS. It promises reproducibility: spin up a new machine, apply your config, and boom, it’s identical. It offers atomic upgrades and rollbacks: if an update breaks something, you can instantly revert to a previous, working state. This isn’t just a convenience; it’s a paradigm shift, a promise of system stability and consistency that, frankly, an imperative system like Arch, for all its elegance, struggles to match without significant manual effort.

The allure was undeniable. The idea of my entire digital world encapsulated in a version-controlled Git repository, ready to be deployed anywhere, anytime, without fear of “it works on my machine” syndrome, was a potent motivator. It was a leap of faith, certainly, but one that promised a level of control and predictability that began to overshadow my long-standing loyalty to Arch’s bare-bones, roll-your-own philosophy. This wasn’t about dissatisfaction with Arch; it was about the seductive whisper of something *more*.

The Prudent Path – Virtual Machines and the Gentle Introduction

Now, while I might be “Wong Edan,” I’m not entirely reckless. Jumping headfirst into NixOS on my primary desktop without a parachute would be, well, truly ‘edan’. Thankfully, the collective wisdom of the internet, particularly those who have trodden this path before, offered a sanctuary for my impending migration: the virtual machine. This advice resonated deeply: “install nix in a vm, get your nix config file made and tailored to you” (source). It’s the digital equivalent of learning to swim in the shallow end before tackling the open ocean.

I distinctly recall my own hesitation, a battle between my impatient ‘Wong Edan’ spirit and the pragmatic voice of experience. Some, like Haseeb Majid, confess to having skipped this crucial step, later acknowledging they “should’ve done which was try to use NixOS in a VM first” (source). This reinforces the wisdom: a VM is not merely a suggestion; it’s a critical bridge. My own migration involved updating not just one, but two virtual environments – one in VirtualBox and another in VMWare – alongside a third, unmentioned system (source). This dual-VM approach allowed me to experiment with different configurations and test scenarios without risking the stability of my beloved Arch setup.

The beauty of the VM approach lies in its safety net. The Nix language, its module system, and the sheer breadth of its configurable options are vast. Learning to effectively “tailor” your Nix configuration file is a journey in itself. In the VM, every configuration change, every attempt to integrate a new service or desktop environment, is a low-stakes learning opportunity. You can rebuild, rollback, and re-experiment with impunity. This iterative process of building and refining the configuration.nix, understanding the nuances of how NixOS manages packages, services, and user environments, is absolutely essential. It’s where you truly grasp the declarative paradigm, translating your Arch-centric knowledge into Nix-speak. It allows you to make mistakes, learn from them, and develop a robust, working configuration that you can then confidently apply to your bare metal system. Without this period of virtual incubation, the leap would be far more jarring, far more likely to end in frustration rather than enlightenment.

The Arch Habits Die Hard – Configuration Files and Dotfile Dilemmas

One of the first questions that plagues any seasoned Arch user contemplating a move to NixOS is fundamentally ingrained in our Arch-DNA: “Can I just bring my existing configuration files?” The thought process, often articulated in forums, goes something like this: “I know Nix has its own way of configuring things but I wonder if its possible to initially take my existing config files in Arch, and then…” (source). It’s a natural inclination. After years of meticulously crafting .bashrc, i3/config, nginx.conf, and a myriad of other dotfiles and system configurations, the idea of simply porting them over seems efficient, logical even.

However, this is where the fundamental philosophical chasm between Arch and NixOS becomes glaringly apparent. In Arch, you manage configuration files directly. You edit /etc/fstab, modify /etc/systemd/system/*.service, and place user-specific settings in your home directory. In NixOS, these files are largely generated from your central configuration.nix. You don’t directly edit /etc/fstab; instead, you declare your file systems in Nix expressions. You don’t directly write systemd service files; you enable and configure services through Nix modules. This means that a direct “lift and shift” of your existing Arch configuration files is largely impractical, if not impossible.

The NixOS way requires a complete translation of your system’s desired state into the Nix language. For simple dotfiles like shell aliases or editor configurations, you might still symlink them from a Git repository. But for anything system-wide, like network configurations, services, user groups, or even specific kernel modules, you’re essentially rewriting them in Nix. This can be a significant hurdle, especially for users with complex or extensive Arch setups. As one Reddit user subtly put it, the ease of migration depends on “unless you don’t have much to…” (source), implying that a minimal Arch configuration will naturally lead to a less daunting NixOS configuration task.

The “Arch habits die hard” idiom truly applies here. The muscle memory of directly editing files, restarting services, and using tools like systemctl or journalctl to debug often needs to be unlearned or at least adapted. Instead of directly troubleshooting a config file, you’re debugging your Nix expression. It’s a different way of thinking, a declarative mindset that replaces imperative actions. This transformation from directly manipulating files to declaring desired states is perhaps the most profound mental shift required when migrating from Arch Linux to NixOS, and it’s where much of the learning curve resides.

Diving into the Deep End – Flakes, Modules, and the Nix Language

Having navigated the initial conceptual hurdles and successfully experimented within the safe confines of a virtual environment, the next phase of my migration journey involved a deeper immersion into the very core of NixOS: the Nix language, its module system, and the increasingly prevalent concept of flakes. This is where the Arch user’s traditional understanding of package management and system configuration gets a complete overhaul. Forget pacman -S and manually editing /etc/rc.conf (for those of us old enough to remember!). In NixOS, everything, and I mean everything, is an expression in the Nix language.

The Nix language itself is a functional, lazy, and purely declarative language designed specifically for package management and system configuration. It’s not Bash, it’s not Python, and it’s certainly not XML or YAML. It has its own syntax, its own idioms, and its own way of defining packages, services, and modules. For an Arch veteran accustomed to configuration files resembling glorified shell scripts or INI-style directives, learning the Nix language is akin to learning an entirely new programming paradigm just to run your operating system. It requires time, patience, and a willingness to embrace a truly unique approach.

At the heart of NixOS is the module system. This system allows you to declare desired configurations for various parts of your system – from enabling a specific service like Nginx or PostgreSQL, to configuring your desktop environment (I certainly switched my desktop computer environment over), to defining users and their permissions. Each option is part of a vast, interconnected graph of declarations, all culminating in your final system configuration. This granular control, expressed declaratively, is immensely powerful but also demands a new mental model for system administration.

More recently, the Nix ecosystem has been undergoing an evolution with the introduction of flakes. Flakes represent a modern, standardized way of defining Nix projects, providing reproducible inputs and outputs. They encapsulate your entire system configuration, development environments, and even custom packages in a self-contained, version-controlled unit. Tools like flake-parts further simplify the management of complex flake-based configurations, covering functionality previously handled by tools like flake-utils (source). Migrating to a flake-based setup adds another layer of complexity but also brings increased predictability and composability to your system. Understanding how to structure your flake, manage its inputs, and expose its outputs is a critical step in becoming proficient with modern NixOS. It’s not just about installing packages anymore; it’s about defining an entire, reproducible computational graph.

This phase is not for the faint of heart. It involves considerable reading, experimentation, and often, the frustration of an error message that points to a line in your Nix configuration that, to your Arch-trained eyes, looks perfectly fine. But with perseverance, the reward is a system that is not only robust but also perfectly transparent in its configuration, defined in a way that no Arch system ever truly could be.

Post-Migration Puzzles – The Devil in the Declarative Details

Even after successfully migrating my desktop computer environment and dedicating about a month to using NixOS, the journey wasn’t entirely devoid of unexpected detours and peculiar puzzles. The declarative nature of NixOS, while offering immense power and reproducibility, also means that troubleshooting often requires a completely different approach than what an Arch Linux user is accustomed to. The common Arch wisdom of “check the logs, edit the config file, restart the service” often doesn’t directly apply in the same way. Instead, you’re usually debugging your Nix expression or understanding how a particular module interacts with others.

A prime example of these post-migration quirks emerged shortly after my switch: problems with SSH Security Keys (Yubikey) with GPG-Agent. “I recently migrated from Arch Linux to NixOS, but I have a problem since my migration I can’t use my Yubikey with ssh” (source). This wasn’t a matter of forgetting to install a package; it was about ensuring that GPG-Agent was properly configured, enabled, and integrated into the user environment and SSH daemon via NixOS modules. In Arch, I would have ensured the relevant packages were installed, edited ~/.gnupg/gpg-agent.conf, and perhaps tweaked my shell’s startup scripts. In NixOS, this required diving into the NixOS options, understanding how to enable programs.gnupg.enable, configure services.gpg-agent, and ensure the correct sockets and environment variables were propagated.

This specific issue highlights a broader challenge: even seemingly small, deeply integrated components of a system need to be explicitly declared and configured within the NixOS framework. Features that might “just work” or require minimal configuration on Arch Linux often demand a more explicit, often verbose, declaration in NixOS. This isn’t a flaw; it’s a feature. Every component’s state is known, defined, and reproducible. But for a user accustomed to the more implicit or convention-over-configuration style of Arch, it can feel like a constant game of “find the right NixOS option.”

Furthermore, the troubleshooting mindset shifts. Instead of searching for solutions for a specific package’s configuration file, you’re looking for how to achieve a desired outcome using NixOS options and modules. This often involves consulting the extensive NixOS manual, the source code of Nixpkgs, or the NixOS Discourse forum (source). The infamous “RTFM” (Read The F***ing Manual) takes on a new, more profound meaning in the NixOS world, as the documentation is often the most direct path to understanding how to correctly declare your system’s state. These post-migration puzzles, while initially frustrating, ultimately serve to deepen one’s understanding of the NixOS paradigm and solidify the benefits of its declarative approach.

The Wong Edan Verdict – Was it Worth the Nix-Stalgia?

So, after a decade of Arch Linux mastery, a daring leap into the declarative unknown, and a month of living with my new NixOS reality (source), what’s the verdict from this ‘Wong Edan’ tech blogger? Was the journey from the DIY ethos of Arch to the deterministic wonderland of NixOS worth the effort? Absolutely, wholeheartedly, and with a resounding YES!

The migration from Arch to NixOS isn’t a trivial undertaking. It demands a significant investment in learning a new language, a new module system, and a fundamentally different way of thinking about system administration. The initial thought of simply porting existing configuration files is quickly dispelled by the reality of NixOS’s unique approach (source). It requires patience, especially when diving into advanced topics like flakes and flake-parts, and a willingness to embrace the “Nix way” for everything from desktop environments to SSH security keys. However, the benefits, once realized, are transformative.

The promise of reproducibility is not just theoretical; it’s a tangible reality. My entire system, from my window manager to my specific development toolchains, is now defined in a single, version-controlled file. Spinning up a new machine, or even just rolling back to a previous working configuration, is no longer a harrowing, hours-long endeavor but a simple command execution. The ability to experiment with new software or system changes without fear of irrevocably breaking my system, thanks to NixOS’s atomic updates and rollbacks, has unleashed a new level of digital freedom.

For those considering the leap, my expert conclusion, echoing the advice of many who have gone before (source), is this: start with a VM. Don’t rush it. Embrace the learning curve; it’s steep but incredibly rewarding. Prepare to rethink how you configure and manage your system. And most importantly, enjoy the process of building a truly declarative, reproducible, and robust operating system. Was it worth leaving the familiar comfort of Arch Linux? For this ‘Wong Edan’ techie, the answer is a resounding yes. The future, my friends, is declarative, and it’s looking mighty fine.