nixpkgs VS Home Manager using Nix

The source code is retrieved from the official source of the package, and checked against a hash that is stored in the package definitions. All the package definitions are stored in a large github repository, and they are "code reviewed".

For example, you can see where the xz sources get pulled from in the src section here:

https://github.com/NixOS/nixpkgs/blob/nixos-25.05/pkgs/tools...

As usual, wherever you get your software, if someone at the source sneaks in something malicious and no one notices it it gets in there. NixOs has no special mitigations against that (AFAIK).

But you can be reasonably sure that the binary you have matches the official source of the software, with maybe some reviewed patches to get it to work in Nix's environment.

The binaries are cached, so you don't have to build everything yourself. There is a command to rebuild the software from source yourself. Most packages are reproducible, about 95% of the distributed gnome version:

Noticed it wasn't on Nixpkgs, so... https://github.com/NixOS/nixpkgs/pull/399843

https://github.com/nixos-bsd/nixbsd This is a very cool project that I hope will get upstreamed into NixOS proper, eventually.

I always thought InitWare would be good for that. See https://github.com/NixOS/nixpkgs/issues/26850 --- we've been discussing this before NixBSD existed, even!

If you are currently involved in managing packages for a Linux distribution, then you might want to use the instructions outlined in the GitHub repo to help you build packages for your distributions. My colleague James Ward has recently done this for NixOS (you can see his PR here)

You can do this with vanilla Firefox using policies.json[1]. Check out `DisableAppUpdate` attribute.

If you're using Firefox from nixpkgs this is already disabled by default[2].

[1]: https://support.mozilla.org/en-US/kb/customizing-firefox-usi...

[2]: https://github.com/NixOS/nixpkgs/blob/nixos-24.11/pkgs/appli...

Ah, this is awesome! I currently run k3s on a decently spec-ed NixOS rig. I tried getting k3s to recognize my Nvidia GPU but was unsuccessful. I even used the small guide for getting GPU in k3s to work in nixpkgs[0], but without success.

For now I’m just using Docker’s Nvidia container runtime for containers that need GPU acceleration.

Will likely spend more time digging into your findings — hoping it results in me finding a solution to my setup!

[0] https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...

- Method 1: doesn't really improve layer caching, but it provides a familiar way (via Dockerfile) to use Nix packages. As with any Dockerfile, the creator is in charge of creating layers and making sure those layers are as small (cleaning cache, ...).

- Method 2: Nix language is used to describe (in a declarative way) what the end image should look like. Layers are then calculated based on the dependency tree (or as Nix calls it, dependency closure). The algorithm that creates layers[1] makes sure that there is higher likelihood of cache hits without the user needing to worry about layers, but you can even roll-up your own algorithm that fits your project better.

- Method 3: Using Flox you would get sort of both. An easy way to configure the final docker image via toml configuration and using Method 2 under the hood.

There are other ways how to improve caching efficiency, but those are very use case specific (eg. big "builder" images) and would probably require a completely separate blog post.

[1] https://github.com/NixOS/nixpkgs/blob/63f0da03a3b2c323ea924b...

I spent a while messing around with https://github.com/ansiwave/nimwave, which I enjoyed but I haven't gotten very far. Though I've been avoiding the front end for so long, I don't know what reasonable feels like in that space anyway.

My Nim journey was stalled by this bug in its nix toolchain: https://github.com/NixOS/nixpkgs/issues/308593. I guess that's the price we pay for straying from the beaten path.

Just NixOS. When building the VM / live CD I copy my dotfiles into the Nix store and then during first boot-up I copy them into my home dir and set up symlinks.

The main reason I decided against home-manager was that it makes my simple symlink setup (~/.foo -> ~/.dotfiles/foo) virtually impossible: Symlinks will always point to the read-only Nix store in one way or another. See https://github.com/nix-community/home-manager/issues/3514 or one of the countless other tickets on the topic. Through this episode I also learned that home-manager isn't exactly well-documented, either, and also quite opinionated. (Which, to be fair, is not a bad thing – if it works for you, it probably works great.)

Finally, not using home-manager was also a risk management decision in that it's probably best to not go all-in on Nix, NixOS, home-manager etc. all at once. Start with the simplest possible config that gets you running, then iterate.

(Declarative rclone https://github.com/nix-community/home-manager/pull/6101)

Atop all this is the Nix Operating System, or NixOS. NixOS brings all of the declarative goodness of Nix into a Linux distribution. This means that (almost) everything about your system is declarative, including the packages (obviously), the users, the desktop, the login manager, systemd units, containers, and among other things, even the bootloader! Through some extensions, you can also partition disks, build images, and even configure your home folder. A single NixOS configuration is built into multiple pre-configured operating systems using just a single command!

Read more at: https://github.com/nix-community/home-manager

While I don't use NixOS or home-manager, I would imagine this provides some extra value: i.e. config is versioned or easy to move between machines.

Curiosity got the better of me so I looked it up at https://nix-community.github.io/home-manager/ and it indeed does purport to provide benefits I guessed at and then some.

Whether that's better than just manually managing things yourself is altogether a different matter.

Nix Home Manager is a tool for managing a user environment with Nix. It already has a nice way to install and configure gh with the programs.gh option:

The data definition and operational model of SOPS is well suited for a Nix-powered system. sops-nix offers both NixOS and Nix Home Manager modules which provide a declarative way to manage secrets using SOPS.

There is also nix-on-droid[1] which is a fork of Termux allowing you to manage your environment with nix (similar to home-manager[2])

[1]: https://github.com/nix-community/nix-on-droid

[2]: https://github.com/nix-community/home-manager

It's probably overkill for what you are trying to do. But I have been using home-manager [0] as a way to quickly restore my working environment.

[0] https://nix-community.github.io/home-manager/

$ home-manager --version 23.05 $ nix-channel --add https://github.com/nix-community/home-manager/archive/release-23.11.tar.gz home-manager $ nix-channel --update $ nix-shell '' -A install [...] All done! The home-manager tool should now be installed and you can edit /home/MY-USERNAME/.config/home-manager/home.nix to configure Home Manager. Run 'man home-configuration.nix' to see all available options. $ home-manager --version 23.05