Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating from GNU Stow to Chezmoi

rednafi.com

Post reply on HN
Print view View original

131–140 of 152 posts

Re: Migrating from GNU Stow to Chezmoi

#131

Post by [deleted] »

colordrops wrote: post #122
jolmg wrote: post #111

Earlier quoted context omitted.

> The only way it would recompile everything is if, for example, you modified a particular version of glibc that was imported by most packages. The package dependencies aren't based on whether what's packaged is a linked library, and built packages are linked to the dependencies by the digests. The digest of a package is made from the store derivation which contains the digests of the dependencies. Or does the digest…

I didn't say anything about linked libraries. I was just using glibc as an example. I could have used a man page too.

[deleted]

Re: Migrating from GNU Stow to Chezmoi

#132

Post by [deleted] »

colordrops wrote: post #122
jolmg wrote: post #111

Earlier quoted context omitted.

> The only way it would recompile everything is if, for example, you modified a particular version of glibc that was imported by most packages. The package dependencies aren't based on whether what's packaged is a linked library, and built packages are linked to the dependencies by the digests. The digest of a package is made from the store derivation which contains the digests of the dependencies. Or does the digest…

I didn't say anything about linked libraries. I was just using glibc as an example. I could have used a man page too.

[deleted]

Re: Migrating from GNU Stow to Chezmoi

#133

Post by reinitctxoffset »

arianvanp wrote: post #125
reinitctxoffset wrote: post #100

Earlier quoted context omitted.

I understand in considerable detail what's happening here, having written a conforming implementation of `nix` myself. Silently smuggling environment variables into a builder means the build is not reproducible, nor is it possible to know a-priori whether the build is reproducible. Nix reverts to the same level of guarantee you get from Ubuntu or whatever without the convenience of Ubuntu: Docker is dramatically more…

Euhm what the hell are you on about. This is a fixed output derivation. The output per definition is reproducible. It either returns a value that matches the hash or it fails. The whole point is that it allows introducing controlled side effects as long as the output is reproducible. Bur you're extremely annoying to talk to so I'm not gonna continue engaging. Probably an LLM

The outcome isn't even reproducible if GitHub is down, so like multiple times a week now. And FODs routinely break because of the dozens of leakage modes in the evaluation cache (if flakes are involved), the dozens of races (mostly TOCTOU or adjacent) on the `sqlite` interface and other store-adjacent bugs (`ssh-ng` is especially broken, that's actually the biggest blocker to floating CA at the moment), and so it is very easy to change the declared hash of a fixed-output derivation (for example, you're iterating on the upstream artifact) and have an old one stuck in cache/store because the `Aterm` driving the NAR calculation doesn't trip a fetcher invoke.

This stuff doesn't work, and mixing in ambient environment state is the cross product of the current amount of broken with now it's not even the same on my laptop and desktop.

If you know of an LLM that understands this stuff in this kind of detail, I would be in your debt for a referral, because I sure as hell wish I didn't have to know all this stuff.

And if it's annoying to make vague claims without supporting evidence and have them refuted by concrete arguments with specific details cited than HN may not be the place for you. Being right matters here. I haven't been rude, or made it personal (vis-a-vis "you're extremely annoying" which I don't appreciate).

I don't get the personal attack on this. I'm talking facts about technology.

Re: Migrating from GNU Stow to Chezmoi

#134

Post by reinitctxoffset »

zaik wrote: post #130
charcircuit wrote: post #73

Earlier quoted context omitted.

These things really do not have an actual reason. Take for example the Nic people who go to every project with a bash script that uses #!/bin/bash and tells them to use #!/usr/bin/env bash. There is no justification for trying to fix every bash script in existence over the operating system being able to resolve what the "current" bash version should be (/usr/bin/env already has to pick a version). This is pointless O…

If you decide to create a package for the project in nixpkgs, patch-shebangs.sh should do it for you, no?

Getting a patch into `nixpkgs` is not a reasonable bar for running some program you want to try. This is an (admittedly polite) way of saying more or less "you're holding it wrong". I respectfully disagree.

For expert users, creating a flake and/or standalone derivation is a little more reasonable of an ask. It is an unreasonable ask of people who are considering adopting Nix, and the friction is artificial, it serves no practical benefit (you'll notice that things like `nix-ld` are in `nix-community` now, long-time community contributors like Mic92 said a long time ago, we need to stop the bleeding on this).

And once you get out of the merely alienating to anyone used to being treated well, and into actually complex software builds, "possible once you learn the incantations" goes to "never happens, you will never run this without Docker on NixOS".

I won't settle for that, so I fix things:

``` b7r6 on ultraviolence ~ nix run github:sensenet-ai/nvidia-sdk#python Python 3.12.12 (main, Oct 9 2025, 11:07:00) [GCC 15.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import tensorrt_llm W0619 15:07:35.110000 14798 /nix/store/xgk8wcis2avy1vsv66viw150jv78v6qs-ngc-python-packages-ngc-25.12-rootfs/lib/python3.12/site-packages/torch/utils/cpp_extension.py:2422] TORCH_CUDA_ARCH_LIST is not set, all archs for visible cards are included for compilation. W0619 15:07:35.110000 14798 /nix/store/xgk8wcis2avy1vsv66viw150jv78v6qs-ngc-python-packages-ngc-25.12-rootfs/lib/python3.12/site-packages/torch/utils/cpp_extension.py:2422] If this is not desired, please set os.environ['TORCH_CUDA_ARCH_LIST'] to specific architectures. [TensorRT-LLM] TensorRT LLM version: 1.1.0 >>> import torch >>> torch.cuda.is_available() True >>> ```

Re: Migrating from GNU Stow to Chezmoi

#135

Post by theshrike79 »

kstrauser wrote: post #72
bkummel wrote: post #21

Earlier quoted context omitted.

I didn't even know that managing dotfiles was a "problem space".

It's dead simple to manage files in git or such. What Chezmoi adds over that are niceties like: * Permission management, so that ssh wouldn't refuse to log you in because ~/.ssh/authorized_keys is 0755 instead of 0644. * Templating, because ~/.ssh/config has slightly different options on Mac and Linux, so you can't use the exact same file contents as-is on both systems. I can run `chezmoi apply` and get all the files…

Also encryption with `age`.

My ssh config has actual domain names of servers I don't want to publish to the whole internet so that file is encrypted on my public github dotfiles repo.

Chezmoi automatically decrypts it on `chezmoi update` and I don't need to think about it much unless I'm editing it.

Re: Migrating from GNU Stow to Chezmoi

#136

Post by theshrike79 »

ceving wrote: post #127

I don't understand why anyone would bother doing something like Stow. I keep my home directory directly in a Git repository that ignores all files by default, and for systems with specific configurations, I simply create a branch.

But if you have 6-10 machines you use and they're all a bit different, doesn't the branching get a bit tedious when you want to edit something that's common for all?

Vs. the chezmoi way of keeping everything common except using templates for diverging files.

Re: Migrating from GNU Stow to Chezmoi

#137

Post by trallnag »

spudlyo wrote: post #7

It's great to manage your dotfiles, but I took it a step farther. I rebuilt the minimal Linux desktop environment of my dreams (startx, xinit, i3, i3status etc) with Ansible. It begins from a vanilla Ubuntu server 24.04.4 install. I bootstrapped it using a KVM + spice setup (using a spare physical SSD rather than a virtual one) and iterating over and over again until I finally got everything mostly working. I then bo…

I did that too across three devices and it turned out to be a huge time sink similar to tinkering with a personal server

Re: Migrating from GNU Stow to Chezmoi

#138

Post by kstrauser »

theshrike79 wrote: post #135
kstrauser wrote: post #72

Earlier quoted context omitted.

It's dead simple to manage files in git or such. What Chezmoi adds over that are niceties like: * Permission management, so that ssh wouldn't refuse to log you in because ~/.ssh/authorized_keys is 0755 instead of 0644. * Templating, because ~/.ssh/config has slightly different options on Mac and Linux, so you can't use the exact same file contents as-is on both systems. I can run `chezmoi apply` and get all the files…

Also encryption with `age`. My ssh config has actual domain names of servers I don't want to publish to the whole internet so that file is encrypted on my public github dotfiles repo. Chezmoi automatically decrypts it on `chezmoi update` and I don't need to think about it much unless I'm editing it.

Oh, that's slick. I haven't needed to do that yet and I keep my stuff in a private repo, but see the benefits to it.

Re: Migrating from GNU Stow to Chezmoi

#139

Post by theshrike79 »

darkteflon wrote: post #79

Ok, I came into this thread intending to say “I’ve been using stow for years and am perfectly happy with it”, started RTFA and the comments, realised that I was actually not happy with it, started considering chezmoi then remembered that I had had a pretty great experience building a Nix VM recently. Now I want to use Nix* to manage my multi-machine MacOS and Linux setup (with lots of dotfile config overlap, of cours…

The saying used to be "every application extends until it can read email"

Now it should be "every app adds features until it manages dotfiles" :D

Dunno why I'd use atuin for dotfile management, but some people seem to like it. It's very good at syncing and managing shell history though.

Re: Migrating from GNU Stow to Chezmoi

#140

Post by theshrike79 »

globular-toast wrote: post #123

The only thing currently annoying me with my Stow setup is handling machine-specific changes. I have a "work" branch in my repo that I have to keep rebased on my master branch. Weird things happen if that rebase causes conflicts in the git config! It's also just annoying. Does Chezmoi have a better solution for that? Or is there a better way using Stow?

With chezmoi you'd create templates from the config files, which would apply/ignore specific bits depending on whatever selector you want (machine name, OS etc)
Post reply on HN