# Nixus is a NixOS configuration that wraps binaries instead of managing files

> Nixus is the author's personal NixOS configuration flake, built on a few deliberate refusals: no Home-manager, no flake-parts, no with keyword, and binaries wrapped rather than dropped into a home directory. It reads as a design document with a working system attached.

**sioodmy/nixus** — My NixOS configuration flake that moggs yours in term of eval times

- Repository: https://github.com/sioodmy/nixus
- Website: https://sioodmy.dev
- Stars: 928 · Forks: 28
- Language: Nix
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/sioodmy-nixus

## A personal configuration, not a template for other people

Nixus is described in the repository as the author's reorganized and rewritten NixOS configuration, and the description of the repository says it is a NixOS configuration flake.

The framing matters. This is not a curated set of modules for the community, and the README is explicit about the intent. It says the configuration might not be widely considered correct, and attributes the design to the author's own judgement rather than to consensus. The topics attached to the repository list dotfiles, flake, linux, nixos, nixos-configuration, rice, unix and zsh.

Even the language is personal. The design philosophy is described in blunt terms, and the reasons for rejecting popular modules are given in the first person, with statements like preferring to wrap binaries over using Home-manager and finding the impermanence approach needlessly overcomplicated and unreliable.

That makes the repository interesting to read for a different reason than most dotfile collections. There is a section titled Why I don't use some of the popular NixOS modules?, and the answers are short because the reasoning has already been done. For anyone learning how NixOS configuration works, a single coherent position is often more instructive than a menu of options.

## Four rules: few inputs, wrapped binaries, no copying, no with

The design philosophy is stated as four bullets, and each one is a constraint that rules things out rather than a feature that adds things.

The first is as little inputs as possible. Every extra parameter in a configuration is another thing to understand, so the rule pushes the configuration toward defaults and away from knobs.

The second is wrap binaries instead of putting files in the home directory. This is the load-bearing decision of the whole configuration, and the README returns to it repeatedly. Instead of copying configuration files into a home directory and hoping they do not conflict, a program and its configuration become one wrapped artifact.

The third is do not copy from others. That is a rule about provenance as much as about code, and it tells you how to read the rest of the repository.

The fourth is to try to avoid the with keyword as much as possible. The with keyword pulls a whole attribute set into scope, which makes it easy to write a name that resolves to something you did not intend. Avoiding it keeps name resolution explicit, at the cost of longer attribute paths.

Four rules is a small surface, and the README says the repository has been reorganized and rewritten around them.

## hosts/, modules/, system/ and user/ carry the whole configuration

The repository is a flake, so the root contains the flake entry point and its lock file.

```bash
flake.nix
flake.lock
```

Below that, the top level holds .github/, .gitignore, LICENSE, hosts/, modules/, system/ and user/.

The four directories map onto the Contents section of the README. hosts/ covers the NixOS machines, and the README names two of them: a Lenovo ThinkPad X1 and a MacBook Air M1 running the asahi kernel. That second detail is worth pausing on, because asahi is the Linux kernel for Apple Silicon, so one of the two machines is not running a conventional Linux distribution and the configuration has to accommodate that.

modules/ holds the NixOS modules the author wrote, described as including home directory management, impermanence and some laptop specific things. user/ is where the user level configuration lives, and system/ is the remaining system level configuration.

One thing this layout does not have is a separate directory of shared packages. The README's Contents list puts packages and theme at the same level as hosts and modules, and describes them as mostly unmodified packages from nixpkgs wrapped with the author's configs, themed through a base16 attribute set.

## Home-manager is rejected in favour of wrapping

The Home-manager section is the longest of the rejected-module explanations, and the reasoning is short. The author does not like it and prefers to wrap binaries, describing that as a much better solution. The README adds that people in the Nix community say Home-manager is a mess, which is an appeal to community opinion rather than an argument.

The one thing Home-manager would have provided is $HOME management, and the configuration does include a module for it. The gap is filled by a separate project of the author's, homix, which the README links and describes as handling the things that could not be wrapped with symlinkJoin, with gtk given as the example.

That is the interesting technical detail. symlinkJoin is the mechanism that makes wrapping work, and it composes several directories into one. Whatever symlinkJoin cannot express still has to be managed somewhere, and homix is where that work went.

So the choice is not Home-manager versus nothing. It is a wrapping-first approach with a small, purpose-built escape hatch for the leftovers, which is a different maintenance profile from depending on a large external module.

## flake-parts replaced by one lambda, impermanence called overcomplicated

The other two rejections are shorter.

For flake-parts, the README says the author was able to fully replace it with a single lambda. flake-parts is a system for composing Nix flakes from modules, and the trade-off here is direct: one function that composes the outputs, against a framework that lets you split that composition across files. The lambda approach is easier to trace because there is one place to read, but it does not scale the same way and it does not give you the module system's structure.

For impermanence, the README says the author found it needlessly overcomplicated and unreliable. Impermanence is the technique of running a system from a memory-backed filesystem so that state disappears on reboot, with tmpfs mounts and a mechanism for deciding what to persist. The configuration includes an impermanence module of its own, so the technique is used, but the specific tooling is not.

For nix-colors, the dismissal is that it is just a glorified attribute set. The replacement is the theme entry in the Contents list, which outputs the current base16 theme as an attribute set, and the packages, which are themed through that base16 attribute set.

Taken together these rejections describe a configuration that prefers small, readable mechanisms over established abstractions, and accepts writing the glue code itself.

## Packages are unmodified nixpkgs builds, themed through base16

The Packages entry in the Contents list says most of them are unmodified packages from nixpkgs, wrapped with the author's configs, themed via a base16 attribute set. The Theme entry says it outputs the current base16 theme as an attribute set.

Two observations follow. First, the base16 approach is the mechanism behind the visual consistency of the setup: one attribute set of colours that programs are themed from, rather than per-program configuration of every colour. Second, and this is the part that connects to the wrapping rule, the packages themselves are not forked or patched. A package from nixpkgs is taken as it is and wrapped, so the upstream code stays upstream code and the configuration sits on top.

The Dev shell entry describes a shell containing the author's entire terminal workflow, with a fully configured neovim among other things. Putting the editor and the rest of the command line environment into one shell entry point is the same wrapping philosophy applied to a development environment rather than to a single program.

A note on scope: the README mentions an awesomerice release tag dated 2022-09-15, which is an aesthetic configuration rather than a release of this configuration itself. The repository has no other releases, which is what you would expect from a configuration that is versioned by its git history.

## The last push was on 2026-07-02 and the licence is GPL-3.0

The repository is not archived and the last push was on 2026-07-02, which puts it within the six month window from today. It is a configuration that is still being revised.

The licence field on the repository says GPL-3.0, and the LICENSE file is at the root. For a personal configuration this matters less than it would for a library, but it does determine what you may do with the code if you fork it, and GPL-3.0 is a copyleft licence, so a distributed derivative carries source obligations. Nothing in the README discusses licensing intent, so anyone repurposing this configuration should read the LICENSE file rather than infer from the topics.

The README also carries a donation section, with a ko-fi link and an Ethereum compatible address. That is the author's personal arrangement and says nothing about the configuration's status.

For a reader trying to reuse any of this, the practical path is the git history and the flake files, not the README. The README tells you the philosophy and the contents in outline, and the philosophy is the part worth taking: fewer inputs, wrapped binaries, explicit names, and no copying.

## Conclusion

Nixus suits a reader who wants to understand one opinionated NixOS configuration end to end, and who is comfortable reading a flake rather than a tutorial. It does not suit someone looking for a starter configuration to copy, since the author explicitly says not to copy from others, and it does not suit a workflow built on Home-manager modules, because those are rejected here by design. Before borrowing anything from it, check that your hardware is covered, since the two hosts named are a specific laptop and a MacBook Air M1 running the asahi kernel, and read the flake.nix and flake.lock in the repository root to see how the pieces are wired.

## FAQ

### Does Nixus use Home-manager?

No. The README lists Home-manager among the popular modules the author does not use and says they prefer to wrap binaries instead. Home directory management is handled by the author's own module homix, for things that could not be wrapped with symlinkJoin.

### What is the base16 attribute set in Nixus used for?

The Contents section describes a theme entry that outputs the current base16 theme as an attribute set, and packages that are mostly unmodified nixpkgs packages wrapped with the author's configs and themed through that base16 attribute set.

### Which machines does the Nixus configuration target?

The README names two NixOS hosts, a Lenovo ThinkPad X1 and a MacBook Air M1 running the asahi kernel, along with modules covering home directory management, impermanence and laptop specific things.

## Sources

- [License: GPL-3.0](https://github.com/sioodmy/nixus/blob/main/LICENSE)
- [Project website](https://sioodmy.dev)
- [README](https://github.com/sioodmy/nixus/blob/main/README.md)
- [Releases](https://github.com/sioodmy/nixus/releases)
- [sioodmy/nixus on GitHub](https://github.com/sioodmy/nixus)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sioodmy-nixus