Shin is a NixOS desktop configuration built around one flake output

A desktop, chosen rather than assembled

Shin describes itself as a study in structural evolution, an elegant NixOS environment designed to move with the rhythm of your creative core, and the README opens with a screenshot before naming a single component.

The choices are specific and they are the product. The window manager is Niri, described as a scrolleable WM, which is the modern answer to tiling that does not tile but scrolls. The shell is Fish, with Starship for the cross-shell prompt. The terminal is Foot, with the question of whether there is something more minimal written into the bullet. The panel is Noctalia, described as a beautiful and minimalist desktop shell. The file manager is Yazi. The GUI basic IDE is Helix, the Rust editor. The GTK theme is a fork of Colloid by the author, linked as a fork of the colloid theme.

That is the whole pitch: someone has made every decision so that a new user does not have to. The topic list makes the same point in tags, with amdgpu, ghostty, niri, nushell, nvchad, ricing, secureboot, starship, unixporn and wayland, which is a description of a specific desk rather than a generic NixOS configuration.

Two warnings sit at the top of the README and are worth more attention than they get. The first asks readers to respect the credits if they use something from the author's desktop or setup, which is a request rather than a licence. The second is a note about a refactor: this configuration has been refactored to remove Home Manager to reduce evaluation overhead, that projects like hjem and hjem-rum were considered, and that a pure NixOS approach was chosen for simplicity and performance.

That second note is the most important line in the file for an adopter, and it is easy to skim past. It tells you the configuration is no longer a set of home-manager modules laid over your own machine. It is a full system definition.

Installing it means partitioning a disk

The installation guide is not a package install. It starts from a NixOS ISO and a disk you are willing to lose.

The guide asks you to download the 25.05 minimal x86_64 Linux ISO, and gives the command as:

wget -O https://channels.nixos.org/nixos-25.05/latest-nixos-minimal-x86_64-linux.iso

Then you boot into the installer, switch to root with sudo -i, and partition the disk. The guide prefers 1GB on the EFI partition, with the reason given: the generations list may become very long, and to avoid overloading the partition. The partitioning is done with gdisk, creating a new partition table, then a 512M EFI partition of type ef00 and a second partition of type 8300 Linux for the remaining space, and writing the table.

The formatting step uses mkfs.fat for the EFI partition and mkfs.xfs for the Linux one, labelling the latter NIXOS. Mounting follows, with the NIXOS label mounted at /mnt and a /mnt/boot created and the EFI label mounted there.

After that, the configuration itself is fetched. Flakes are enabled with nix-shell -p git, and the repository is cloned shallow:

git clone --depth 1 https://github.com/linuxmobile/shin /tmp/shin

The hardware settings are then generated into the clone, and the guide is emphatic about not forgetting this step:

sudo nixos-generate-config --dir /tmp/shin

# Remove configuration.nix
rm -rf /tmp/shin/configuration.nix

Finally the flake is installed, from the clone directory, with nixos-install --flake .#aesthetic, and the machine is rebooted. The default user and password are both nixos, and the guide tells you to change the password with passwd YourUser after the first boot.

The .#aesthetic output name is a hint about the scope

The install command installs a specific flake output, .#aesthetic, and that detail is worth pausing on.

A NixOS flake can expose several outputs for different machines or configurations, and a name like aesthetic suggests the author has more than one. The repository structure supports that reading. There are hosts, system, home, lib, pkgs and secrets directories, and a flake.nix with a flake.lock at the root, which is the standard layout for a configuration that describes more than one machine or more than one variant of one machine.

The secrets directory is the part an adopter should think about. In a NixOS flake, secrets are usually not committed, because a flake.lock and a configuration are meant to be public and a secret in the tree is a secret in a git history. The presence of the directory means the author handles secrets somehow, but the README does not say how, and that is a gap for anyone who wants to add their own.

The remaining directories are the usual division. system holds the system-level configuration, home the user-level one, hosts the per-machine definitions, lib the library functions, and pkgs the packages. The result is a configuration that describes a complete machine rather than a set of overlays, which is the direct consequence of the Home Manager removal mentioned earlier.

The last piece of the workflow is the daily-use tool, and the README recommends a third-party helper for it. If you are using this NixOS configuration flake locally, you can simplify switching and managing your system with nh, a CLI helper for Nix Flakes, and switch configurations with:

NH_FLAKE=/tmp/shin/ nh os switch -- --extra-experimental-features 'nix-command flakes'

The point of that command is that it avoids typing out the full nixos-rebuild command manually and gives a cleaner workflow when iterating on your setup, with the caveat that nh has to be installed in your system environment or user profile already.

What this configuration is not

The honest framing is that Shin is a personal desktop published for others to install, and that has consequences an adopter should accept up front.

The credit request at the top of the README is the clearest signal. A configuration built around a specific fork of a GTK theme, a specific set of keybindings and a specific reading of what a desk should look like is, in substance, the author's design decisions, and the request is that they be credited when reused. That is a reasonable ask and it is also an admission that the project is not trying to be a general-purpose base.

The topic list reinforces it. unixporn and ricing are the vocabulary of the desktop customisation community, and a project that tags itself that way is making a statement about its audience: people who care about the visual result and about the window manager choice, rather than teams who need a stable server image or a managed fleet baseline.

The security topic in the list is worth a note, and so is the absence of a security policy. There is a SECURITY POLICY heading at the bottom of the README, but the content under it is a link back to the top of the document, and the contributing section reads WIP. In other words, the project has headings for the things a serious project needs and the content behind some of them is not written. That is a signal about the current state of the project rather than a criticism of it, but a team evaluating it should notice.

The licence is another such gap. The repository carries no recognised licence identifier in its metadata, and the README does not state one, so there is no clear answer to whether you may modify and redistribute this configuration. For a personal desktop that most people will not publish, that may not matter. For anything else, it is a question to ask the author rather than assume.

The branch name and the state of the tree

The default branch for the repository is hjem, and that name is a small piece of history. The README notes that projects like hjem and hjem-rum were considered before the pure NixOS approach was chosen, and the branch name carries that earlier shape forward even though Home Manager was removed from the configuration.

It is a small inconsistency, and it is the kind of thing that makes the repository harder to read as a reference. A reader looking for the home-manager modules named in the branch will not find them, and the README explains why in a note rather than in the structure of the tree.

The maintenance facts are thinner than the topic list suggests. The repository is not archived, but the last push was on 2026-04-21, roughly six months before the present date, and there are no GitHub releases. A configuration that installs an operating system and depends on a channel of packages is sensitive to that kind of gap in a way that an ordinary library is not, because the packages it pulls keep moving while the configuration does not.

The README also carries a TODO LIST heading with nothing under it, and an acknowledgements table naming eight people and projects as inspiration, including owl4ce, Ilham25, Siduck, NvChad, Rxyhn, HeinzDev, fufexan and AmitGolden. That table is a better guide to the ecosystem this configuration comes from than the feature list is, because it tells you which parts of the setup are borrowed.

For an adopter, the sensible reading is that this is a working, opinionated configuration published for people who like it, with the packaging around it still being filled in. Anyone adopting it for daily use should expect to maintain it themselves once the upstream drift starts, which for a NixOS setup means tracking the channel and re-running the install or the switch.

Editorial conclusion

Shin suits a person moving to NixOS who wants a complete, opinionated desktop with a scrollable window manager and a specific application set already decided for them, and who is comfortable following an install guide that repartitions a disk. It is the wrong thing to adopt as a starting point for a managed fleet, because it is a single user's desktop with a personal keybinding scheme and an unknown licence, and it is the wrong thing for a machine that must not be reinstalled. Before you use it, read the credits warning at the top of the README, check the licence field in the repository yourself, and note that the configuration dropped Home Manager in favour of a pure NixOS approach, so what you install is closer to a frozen system image than a set of overlays on your own.

Frequently asked questions

Official sources

1. Issues
2. linuxmobile/shin on GitHub
3. Project website
4. README