Beyond "It Works": Why I Migrated to NixOS for Embedded Engineering

As engineers, we often stick to tools simply because they work. For a long time, Arch Linux was my daily driver. It was fast, bleeding-edge, and despite its reputation, I never faced significant stability issues.

So, why fix what isn't broken? Why migrate to NixOS, a distribution known for its steep learning curve?

The answer lies in a shift of mindset: Moving from Imperative Management (patching things as they break) to Declarative Management (defining the state of the system). I didn't switch because I wanted a new toy; I switched because I wanted to treat my operating system with the same rigor I treat my embedded codebases.

The Philosophy: Infrastructure as Code (IaC)

In traditional Linux distributions, system administration is procedural. You run sudo pacman -S package, you edit a config file in /etc/, and you hope you remember these steps when you buy a new laptop.

NixOS changes the paradigm. The entire operating system is defined in configuration files. If I want to reinstall my system on a new machine, I don't need to remember what I installed two years ago. I simply clone my configuration repo, run one command, and my environment is replicated bit-for-bit.

This is not just convenience; it is reproducibility—a core tenet of high-quality engineering.

The Architecture: Flakes & Modularity

I decided to adopt Nix Flakes from day one. While I am still researching and refining my approach, using Flakes ensures that my system's dependencies are locked and predictable.

To avoid a monolithic configuration file, I designed a modular directory structure. This separates hardware-specific configs from user-specific dotfiles (managed via Home Manager).

Here is a high-level view of my current system architecture:

bash
dotfiles
├──  flake.nix             # The entry point
├──  hosts                 # Machine-specific configurations
│   └──  wcnrny            # My main workstation
├──  modules               # Reusable modules
│   └──  home-manager      # User-space management
└──  configs               # Application specific configs
    ├──  hypr              # Hyprland Configs
    └──  SystemConfigs     # Hardware & Startup logic

This modularity allows me to manage my Hyprland window manager, Neovim setup, and system services in isolation, making debugging significantly easier.

Here is the link to check my dotfiles.

The Workflow: No More Global Toolchains

For an Electrical & Electronics Engineering student, managing toolchains is a nightmare.

• One project needs Python 3.8, another needs 3.12.

• My Embedded Rust project needs a specific nightly build, but my system Rust is stable.

On Windows or standard Linux, this leads to "Dependency Hell." On NixOS, I use DevShells.

Instead of installing compilers globally, I define a shell.nix or flake.nix inside my project folder. When I work on my Rust projects (like Rustlings or my BMS simulation), I enter a shell where the compiler exists only for that session.

bash
$ nix develop
# Now I have rustc, cargo, and esp-idf available.
# When I exit, they are gone. My system remains clean.

This "Clean Room" approach ensures that my development environment never interferes with my system stability.

The EEE Dilemma: Windows vs. Linux

The biggest friction point for EEE students migrating to Linux is EDA (Electronic Design Automation) software. Industry standards like Altium Designer or Proteus are predominantly Windows-based.

However, the industry is shifting. Many modern startups and hardware companies are adopting KiCad as a standard because of its open-source nature and powerful scripting capabilities.

My Advice to Fellow Students:

1. Embrace KiCad: If you are moving to Linux, you must be comfortable with KiCad. It is a powerful tool that runs natively on Linux.

2. Don't Start with NixOS: If you are coming from Windows, NixOS is a baptism by fire. Start with Ubuntu or Fedora. Get comfortable with the terminal and file hierarchy first. NixOS is for when you want to architect your system, not just use it.

3. Kernel Knowledge is Power: Large automotive and tech companies (like BMW, Tesla) value engineers who understand what happens "under the hood." Using Linux forces you to interact with the Kernel, giving you a massive advantage in Embedded Software interviews.

Conclusion

Migrating to NixOS has increased my efficiency by removing the "fear of breaking things." I know that my config is safe, version-controlled, and reproducible. It forces me to learn how the Linux system is composed, which directly translates to better skills in Embedded Linux development.

It is complex, yes. But for an engineer, complexity managed well is a superpower.