ZH version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
46% Positive
Analyzed from 2497 words in the discussion.
Trending Topics
#nix#manager#mise#home#dotfiles#chezmoi#don#problem#stow#files
Discussion (52 Comments)Read Original on HackerNews
It’s for things like dotfiles, apt/brew packages, and LaunchAgents/systemd.
Hopefully can use this alone instead of needing to combine w/ chezmoi / nix to get everything shell and pkg manager agnostic, consistent, and DRY (bash/zsh/fish + macports/pkgsrc/brew).
The "exception" to that are linux package managers like apt-get and dnf which it calls under the hood. I think can't be an actual issue since it's not like you would ever use ubuntu/redhat without their system package manager installed.
Being able to centralize this config is far more attractive than having a separate Ansible or pyinfra process.
Thanks so much for your work on mise! I used to be a heavy asdf user but nowadays I'm an even heavier mise user!
Random question while you're here: mise is undergoing pretty heavy development these days and I recently noticed that 1) my coworkers and I are not always on the same version, so some features/bug fixes are not available to everyone, and 2) package registries often don't have the latest mise version.
So I think we need a meta tool manager here to manage the tool manager version. :) Seriously, though, have you considered having mise manage its own version? I think that'd be pretty neat!
Thinking aloud, I guess one way to do this might be to distribute through package registries only a lightweight bootstrap application, which 1) reads the pinned mise version from mise.toml and downloads it as necessary, and 2) sets up a basic shell hook that the active mise version can then hook into(?) I know, this probably sounds a lot easier than it actually is.
I would make use of min_version. It's not perfect, but will at least help bring laggards along.
That way I don't have to remember to commit+push+pull changes to existing dotfiles (like bashrc or vimrc which I edit often) to sync them to other machines, it happens automatically in almost real time as soon as the file is saved on one of my machines (syncthing uses inotify to detect changes on monitored directories)
I think Chezmoi's templates and file naming conventions don't click for me, but it's nice to see a good variety in this problem space.
One major benefit for me is that I no longer need to have once-in-a-while tools installed, because I can always spin up a temporary shell with `nix-shell -p packageName`. This significantly decreased the amount of software I have in my environment.
This works great with agentic coding. Agent wants to run `ripgrep`, but you don't have it? Tell it to run `nix run nixpkgs#ripgrep` instead.
But the biggest benefit is that now that you know Nix! So you can start using it to create reproducible development environments and uninstall mise, asdf, nvm, pyenv, etc. You can spin up reproducible servers running NixOS and never touch Ansible again. You can even install it in your router.
Or you can do none of that and continue just using it for your dotfiles. It plays nice with other tools.
About 6 weeks ago I installed NixOS on a spare laptop and did 100% of the configuration through Claude Codex. Initially I copied "/etc/nixos" off to my existing workstation, until Claude Code bootstrapped it enough to run on the NixOS machine.
I've been running it as my primary workstation for the last 3-4 weeks, and it's been great! 100% configured by Claude Code or Codex CLI.
Configuring a machine via Nix lang is not that fun. Configuring a machine via English is.
And I've thrown some curveballs at this setup. I asked it for gitbutler-cli, which NixOS doesn't/didn't provide, and it was able to package up and build it. It's running Sway. I have my secrets and configs in SOPS+Home Manager.
I like mise, but at the end of the day some programs are more complex than just pulling a precompiled, dynamically linked binary and hoping it works.
For a System administrator the problem is many orders of magnitude worse
And `home-manager` is maybe the most glaring instance of a tool that is demonstrably ill-posed where the "you're holding it wrong" from the community is a the community problem, not anyone holding anything wrong. From the Zed editor configuration stanza in `home-manager`: https://github.com/nix-community/home-manager/blob/a78606767.... That's not a Zed problem, that's a Nix problem. No one is holding it wrong, XDG config paths get mutated.
Another example and this is the one that really shows the shape of the thing: https://github.com/nixified-ai/flake/blob/bbd3a04fa1ae294096....
There is absolutely nothing "impure" about taking content-addressed bytes from a CAS (Xet in this instance) and surfacing them as a derivation. The "impurity" is called a "coeffect" and the action over the coeffect is called "grade discharge". This is thoroughly studied and works properly, it can cope with all of these cases and it's creates scope for dramatically more reproducible systems that are much easier to reason about (they are possible to reason about). Also, if you can't download shit from HuggingFace in 2026 without a weird hack where the name of the field is a scolding? That's gonna be putting downward pressure on adoption.
And most of the high-friction shit in Nix is like this, ignorance hardened into dogma hardened into theology. To wit:
- FHS vs. zany one-of-a-kind filesystems are nothing to do with purity or hermeticity or reproducibility, it's pure theology and the constant breakage with all the `patchFail` jank is at this point a jobs program, it's totally unnecessary. Namespaces/unshare, we have all the stuff to do this properly (`patchelf` and `unshare --bind-mount` are mathematically dual but only one blows content addressing).
- `drv` hash addressing is a reproducibility war crime. Floating CA is fine it's just broken upstream and in Determinate, it's not a valid ideological debate, it's bugs.
- there is absolutely no reason why the builder where a binary is produced needs to have the same filesystem layout or find libraries in the same place as the resulting artifact runs in any more than an adult needs to live in the same house they grew up in. `patchelf` works.
- having `libcuda.so.1` and friends at `/run/opengl-driver/lib` is dark comedy and source builds of `NCCL` when NVIDIA-certified binaries are in a wheel (zip file) on PyPI is the sequel. this is straight up bad for the planet and we should feel bad we haven't fixed it.
I could go on, but the main point for this thread is to the people who are on the fence about Nix: you're not holding it wrong the `nixpkgs` maintainers are holding it wrong, and more and more of us are getting serious about fixing it. Don't give up on declarative and reproducible systems that you can reason about because Nix is stuck in a weird place as software and as a community. There are reformers on the case.
Ultimately, my workplace setup is what has the most gravity. And the most I can get most workplaces to standardize on is Homebrew for package management of off-the-shelf software. Nix is so far outside of the wheelhouse for most engineers that I can't even propose it. It would be too much of a distraction for too many people for too long that it's just not seen as worth it and it's not worth spending the political capital on the attempt. Employers would literally prefer to run scripts from a whitewashing, barely-auditable Jenkins instance with parameterized jobs than to attempt to figure out how to distribute portable scripts and get everyone's permissions working.
So I need to pick software that will cooperate with other tools in an unstable fashion, rather than software that attempts to fully and exclusively control the environment to provide guarantees. Chezmoi fits. Nix and home-manager do not.
I've been using (and contributing to) chezmoi for ~6 years now. Given that it has first-class integration with secrets managers, I suspect that it does things that Home Manager can't.
I did too. Until I tried configuring it with Claude Code. I'll give you my money back guarantee on it.
Pretty snazzy, watching YouTube in Firefox on a 13 year old laptop with hardware h264 decode and everything tuned exactly to my liking.
I like that when combined with `mise` (https://mise.jdx.dev) I can roll out a new computer in 2-3 commands and have my entire environment configured the way I like, with neovim and all the plugins and language servers.
Chez moi is definitely not without its rough edges but it seems to have gotten the subtle essentials right enough for adhd me to not have abandoned it yet.
`make dotfiles` just creates a bunch of symlinks, takes 5 minutes, all good and happy. Everything is modular, declarative, simple. Never looked back.
I treat my powerful desktop computer as my main machine. Then I have a bunch of laptops.
Then I just rsync my entire home directory out to all the laptops.
From there. The rule is quite simple. Any file created on a laptop are considered ephemeral. If I create data that I have to keep. It gets rsynced back the other direction to the main machine.
This process has served me well for at least 15 years now and is supported by a small handful of shell scripts to automate this process
> This process has served me well for at least 15 years now and is supported by a small handful of shell scripts to automate this process
I feel in a similar way but not with shell scripts. Ruby autogenerates them if I need them too. Ruby is my ultimate glue to hold together everything.
stow is an indispensable tool for me to manage /usr/local for manually installed software. my workflow goes:
now, myapp and all its supporting files are in the right place in /usr/local. if i want to "uninstall", i just runYadm is another alternative, the main thing I don't like about it though is that I'm not a fan of cross OS dotfiles. Having niri files on my work Mac and aerospace dotfiles on Linux annoys me quite a bit.
As powerful as the templating in chezmoi is, I think it should be considered a last resort and only used for simple files. They break your editor features like highlighting.
My configuration lives primarily in .yml files. These are kept super-simple. When need be and another format is required, ruby autogenerates these for me. For instance, all my bash aliases are kept in .yml files which then get turned into bash rc files or any other target format for other shells. Same for most of my other configuration too - not always .yml but usually some text file. I never understood the neet for .foobar directories or files. They just hide a system that is intrinsically ugly and needlessly complicated.
‡: https://github.com/b3nj5m1n/xdg-ninja
;)