just seems like extremely poor communication and more “open letter” bullshit that’s really a nothing burger. Seems like one or two people said “we’re disbanding!” while based on some threads I’ve read the remaining team was like “yeah…we really didn’t want to”

There is no remaining team. The two people who are resigning here are the entire team (originally it was four members, but two had already resigned previously). What’s the point of having a team without any members?

just privately quietly resign

How are you supposed to “quietly and privately” resign from a community project that versions team membership and responsibility in Git? Genuinely, what are you imagining that is lower profile than this and not wildly irresponsible?

just swapped it to remove the ${pkgs.coreutils} but i suspect thats not right either

Just /run/current-system/sw/bin/reboot actually would work, although it relies on your system closure containing a reboot binary. That’s a reasonably safe assumption to make on a NixOS system, but you might not want to do this with other packages.

the path i used was the output of which reboot

The reason that doesn’t work is that the structure of packages and the structure of a NixOS fiile system are different. Consider this:

$ ls -l $(readlink $(type -P reboot))
lrwxrwxrwx 33 root root 9  1. Jan 1970  /nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot -> systemctl

So the systemd package in the nix store has a bin subdirectory containing its binaries. However:

$ ls -l /bin/reboot
ls: cannot access '/bin/reboot': No such file or directory
$ ls -l /bin/*
lrwxrwxrwx 1 root root 74 Aug  1 06:31 /bin/sh -> /nix/store/dddwfz7nph37q3cjky9lhpy9kb90rrrx-bash-interactive-5.3p15/bin/sh

NixOS doesn’t, at least not really (/bin/sh must exist because the system syscall uses it). Instead binaries for “installed” packages (the technical term would be “packages which are part of the system closure”) are symlinked to /run/current-system/sw/bin:

$ type -P reboot
/run/current-system/sw/bin/reboot
$ ls -l /run/current-system/sw/bin/reboot
lrwxrwxrwx 9 root root 66  1. Jan 1970  /run/current-system/sw/bin/reboot -> /nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot

More accurately, building a NixOS system creates a sort of meta-package that contains a link farm to all installed binaries in the sw/bin directory, and that meta-package is symlinked to /run/current-system at activation/boot. (Not all package contents are symlinked into this meta-package, also see the NixOS option environment.pathsToLink.)

Putting that together with what string interpolation of packages does… well, you kinda just have to look at/know the contents of the package you are referring to:

$ nix repl
Nix 2.34.8
Type :? for help.
nix-repl> pkgs = import <nixpkgs> { }

nix-repl> "${pkgs.systemd}/bin/reboot"
"/nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot"

nix-repl> "${pkgs.systemd}/run/current-system/sw/bin/reboot"
"/nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/run/current-system/sw/bin/reboot"

One of these paths exists, the other doesn’t.

Side note: You’re looking at the old and mostly abandoned wiki, don’t use that. There’s an official wiki which is better. This particular article happens to be the same in both, but the old wiki also has tons of outdated and terrible articles like For Beginners or NixOS Woke Invasion.

For installed packages, you can use readlink:

$ readlink $(type -P reboot)
/nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot

The NixOS search can also search for binaries. It seems that busybox also provides a reboot which I guess might be useful for weird systemd-less deployments?

If you want to search for any file across all packages, there’s also nix-index, which scrapes Hydra for output files and builds a database which you can then query with nix-locate.

In my world that kind of transpilation should be instant.

Well, as you’ve guessed, it’s not really just a transpilation. A NixOS rebuild evaluates significant parts of Nixpkgs, <nixpkgs/nixos> as well as your configuration from scratch (technically flakes have evaluation caching, but it’s not fit for purpose).

Nix isn’t a fast language to begin with, but the evalModules call that actually takes your configuration and turns it into a package that can be built is very expensive. Because NixOS imports (almost) all modules by default, it has to do deep merges of most of <nixpkgs/nixos>, which amounts to almost 32 MB of Nix code. Everything else is a rounding error compared to that.

Oh, and it has to do this for Home Manager too, because Home Manager is also built on evalModules and also imports all the modules. As is flake-parts if you use that (though in that case the set of modules is small so you it’s much less noticeable).

How much of speedup would it yield to rewrite Nix and/or home-manager in a faster language like Zig or Rust?

It would probably make the performance worse before making it better. Nix is slow but it’s not because of the implementation language (which is C++), you would have to do actual interpreter engineering (e.g. writing a JIT) to make an interpreter much faster than the current one.

A builtin (C++ instead of Nix) implementation of evalModules would probably help, but nobody wants the versioning headaches that would come from that. I’m also not sure it would do that much, the amount of data is just massive.

A more promising optimization is to make NixOS not import all the modules by default, but efforts to do this haven’t really gained traction. Probably because you pretty much have to check all modules for cross dependencies.

As a user the best thing you can do right now is using Home Manager standalone and not as a NixOS module. That way, while switching generations will still be slower than it really should be, at least it won’t evaluate and merge all NixOS modules every time you change your mind about a background color.

You can also use a non-Nix-based dotfile manager and forego Nix evaluation (and building) entirely. The only thing you really lose is being able to remote deploy dotfiles with things like nixos-rebuild build-vm.

As far as I’m aware Home Manager doesn’t set PATH at all, though the Nix installer does. I’m not sure where it adds to the PATH, it might edit /etc/profile or something like that. You should be able to change it since you’re not on NixOS.

Alternatively this should also do the trick, although it’s a bit ugly:

home.sessionVariables.PATH = "$HOME/.local/bin:$PATH";

No, you are getting the correct Lutris derivation, but it seems like you can’t override buildFHSEnv in this way (unlike a regular derivation) which is unfortunate. Looking at it again the package takes an extraLibraries parameter (but it’s a function taking a pkgs argument and producing a list, not a bare list). In principle this should work:

home.packages = with pkgs; [
  (lutris.override {
    extraLibraries = pkgs: [ # shadows the other pkgs!
      (pkgs.runCommand "steamrun-lib" { } ''
        mkdir "$out"
        ln -s "${pkgs.steam-run.fhsenv}"/usr/lib64 "$out"/lib
      '')
    ];
  })
];

But it actually fails because both steam-run and lutris provide /usr/lib64/ld-linux.so.2 leading to a name collision. So unfortunately it seems the idea of just adding the steam-run env to Lutris doesn’t quite work…

You could instead try something like this:

home.packages = with pkgs; [
  (lutris.override {
    extraLibraries = pkgs: with pkgs; [
      glibc
      libxcrypt
      libGL
      # ... other libs in steam-run.fhs but not in the lutris FHS env
    ];
  })
];

Which library the problem game actually needs is anyone’s guess. That information might show up somewhere in the logs, or maybe ldd could tell you… but the signal to noise ratio probably won’t be very good.

Untested but I think you want this expression:

home.packages = with pkgs; [
  (lutris.overrideAttrs (_: prevAttrs: {
    multiPkgs = prevAttrs.multiPkgs ++ [
      (pkgs.runCommand "steamrun-lib" { } ''
        mkdir "$out"
        ln -s "${pkgs.steam-run.fhsenv}"/usr/lib64 "$out"/lib
      '')
    ];
  }))
];

Note the extra parenthesis and use of prevAttrs to get the original multiPkgs to append to.

I don’t use Lutris but there’s an issue on Nixpkgs describing it as “utterly broken”. So I would recommend just not using Nixpkgs Lutris. The Flatpak will probably work.

Unfortunately I don’t think there’s a nice way to do that. You can retrieve secrets from pass (albeit with quite a bit of working around the intended evaluation model) but I don’t see a good way to actually deploy the secrets without just putting the plain text into the Nix store (unless you also use a big server management thing like NixOps, as the author of that blog is, but in the time since blog was written NixOps has decided people shouldn’t be using it anymore… so it’s a bit of a mess). You’d really want something like sops-nix or agenix for that.

You can of course decide you don’t care about the secrets being in the Nix store. It “just” means that every local user on the system can read them, as can anyone booting a live USB if the disk isn’t encrypted. And, while this almost certainly isn’t relevant to you right now, if you use the system as a binary cache for other systems those can get the plaintext secrets too. But you might not actually actually care about any of these.

I don’t see anything in your goals that would really require flakes or home manager. Maybe the podman containers, there seem to be some sharp edges around NixOS support for podman from what I can tell.

You might not want to share your entire config but you could share snippets of what you’re trying to do and isn’t working.

Moving on to more concrete suggestions:

If you aren’t already doing so, you should be using the option search liberally. And you should also read the code of the modules and packages, at least sometimes. Sorry, I know nixpkgs Nix can be quite obtuse, but honestly without it I don’t think it’s possible to really grok how NixOS works.

Secondly, a lot of people seem to think you need flakes to configure multiple systems in one repo, but you can actually also do that just fine with stable nix using the -I flag. It’s even possible to build an arbitrary Nix expression using the (unfortunately undocumented) -f and -A flags like flakes would.

Edit: For secrets, I would recommend using agenix, mostly just because it uses SSH instead of GPG. Instead you can also put them in a separate Nix file and gitignore that, but your secrets will end up in /nix/store that way which is a vulnerability if they’re important (also Flakes also break this completely).

I think they might have read this thread, where the Discourse OP is using Home Manager to declare podman containers because the NixOS module just doesn’t support doing that. And flakes ended up in the question because a lot of other examples online just assume the reader is using flakes.

I’m not a podman user so I’m not sure how much work it would be to not use Home Manager here, it feels like it shouldn’t be much more annoying than what the discourse OP is already doing, but I haven’t tried.

If you just want pinning you can also use npins, and it doesn’t do any of the annoying other things Flakes do like copying the entire repository to the Nix store or failing to import unstaged or gitignored files.

The NixOS community has a lot of cargo culting going on, probably because it’s not super accessible. Using Flakes and Home Manager for absolutely everything is a part of that in my opinion. I ended up going back and forth on both of them, my current opinion is that Home Manager makes sense (if you have a use case for it) but Flakes don’t.

If you really need to import a flake-only project from a non-Flake config you can use builtins.getFlake. Personally if a project makes this required by inlining everything in a flake.nix I would consider that a sign of shoddy programming and it makes me reconsider using it, but it is possible.

If you’re talking about using snippets of what other people have in their configs, then most of them should work perfectly fine. You may have to replace an inputs.whatever.nixosModules.default with a fetchTarball or an equivalent reference to an npins file but that’s a pretty minor change.

For Home Manager such a translation doesn’t exist because Home Manager does a lot of different things, and even when HM reimplements something that’s already in NixOS (like HM dconf vs NixOS services.dconf) it usually doesn’t quite act the same way, if only because most programs treat package, system and user configuration differently.

It understands \n if I recall correctly. You can also write regular bash, use templating tools, etc. Just use the nativeBuildInputs parameter if you need a binary that isn’t provided by stdenv.

Another alternative approach would be to add a duplicate desktop file, but to write it declaratively using Home Manager:

# in home.nix
home.file.".local/share/applications/firefox.desktop".source =
  pkgs.runCommand "firefox-desktop" { } ''
    cp "${pkgs.firefox}/share/applications/firefox.desktop" "$out"
    substituteInPlace "$out" \
      --replace-fail "Terminal=false" "Terminal=true"
  '';

# - or -
home.file.".local/share/applications/firefox.desktop".text = ''
  [Desktop Entry]
  Name=Firefox
  Icon=firefox
  Exec=firefox --name firefox %U
'';

It would be possible to DIY this with user activation scripts, but I don’t really see a value in doing that over the symlinkJoin.

Since the desktop files come directly from a package you’ll need to change the package you’re installing. This works best if you use the postPatch phase of symlinkJoin:

pkgs.symlinkJoin {
  inherit (pkgs.firefox) pname version;
  paths = [ pkgs.firefox ];
  postPatch = ''
    # String replacement example - will run the app in a terminal
    substituteInPlace "$out/share/applications/firefox.desktop" \
      --replace-fail "Terminal=false" "Terminal=true"
  '';
}

The reason for using symlinkJoin here is that it creates a package with the same outputs as the original Firefox, but with this bash script having run. You can use this like any other package:

let
  firefox' = <...>
in
{
  environment.systemPackages = [ firefox' ];
  # - or -
  programs.firefox.package = firefox';
}

Note that symlinkJoin has special handling for postPatch, but ignores all other stdenv phases, so you need to do everything in one bash script. You can use all the parameters for runCommand though, such as buildInputs and nativeBuildInputs - e.g. for compiling sass in a wrapper derivation.

In some cases it’s useful to also inherit meta or passthru because it’s used in some nixpkgs/nixos sanity checks, but it’s usually not required.

Another approach would be to use overrideAttrs, which will also work but will cause Nix to rebuild the package from scratch. This might be fine or even desired in some cases, but you probably don’t want to do that in this case.

Also coming from Arch will induce a bit of a culture shock regarding documentation as the NixOS wiki is just… not very good. It’s neither complete nor reliably accurate for the current release. And some wiki pages are actually just snippets with no explanation for either what they do or why they do it.

The matter of flakes is complicated. Yes they are experimental, but in reality most Nix users use them despite that. I’m a bit on the fence on whether you should start with flakes because they do add some complexity. You can copy paste a sample flake configuration from the Internet (there are many but they all do exactly the same things) and you’ll probably be fine but telling people to just copy paste code they don’t understand feels wrong as well.

Regarding documentation… I wouldn’t go as far as saying you should avoid it entirely but it is in a very unfortunate state with a lot of wiki pages being outdated or just containing snippets that do things in very weird ways, or are over engineered to the point of being incomprehensible.

And that’s if someone bothered to write up anything at all. It’s a bit sad but reading from the nixpkgs GitHub (or other people’s dotfiles) is sometimes the only way to get certain information, such as valid values for package overrides.

As a Home-Manager user I would argue it’s not really worth it. It has it’s moments for some applications but most of the time it’s the same experience as editing the config files directly. Except instead of INI or TOML it’s stringly typed Nix attrsets and you need to rebuild the entire system instead of restarting the app. Not exactly a huge improvement.

And that’s when you’re lucky enough that what you’re configuring can be mapped to attrsets. Styling Waybar via Home-Manager means writing CSS but it’s a multi line string in Nix with no appropriate editor support whatsoever, and writing custom actions for Nixvim means writing Neovim-Lua but… that’s right, in a multi line string.

On a more positive note, I will second the recommendation for the NixOS & Flakes Book, I found it to be much more useful for getting my head around flakes (and Nix in general since I started using them fairly early on in my Nix journey) than e.g. Vimjoyer’s videos, which are good but their repositories were really really cryptic to me at the beginning.

I’m not sure why nix-env is so slow exactly but it’s the wrong tool to use anyways as it just throws away everything NixOS has going for itself in favour of pretending to be a normal package manager. You really just want to use the configuration file.

The “normal” way to install packages in NixOS would be using environment.systemPackages. The various programs.<name> options are intended for packages requiring additional setup, like shells or desktop environments (e.g. iirc for sway it creates a systemd target and adds the .desktop files for login managers to see it). Weston has a package but not an option, so you’d have to figure that additional stuff out yourself (but running Weston from a tty should just work).

There are additional ways to install packages for single users or using home-manager but you don’t need those.

This does kinda demonstrate why (I personally think) NixOS is so hard to learn: There’s a million different ways to do anything and each has it’s own weird gotchas. And critically most of them, even when they are honestly just legacy cruft, are not actually deprecated and may even have users advocating their use, or even if they don’t nobody bothered to remove that part from the wiki (if it was ever there to begin with).

You can also see this in the flake/channel split: One person in this very thread is telling you to use flakes, while another is telling you to stick with the default (channels).

And in some (fortunately relatively rare) cases even things that everyone agrees are bad ideas still get promoted in official documentation or other prominent places, like using nix-env -i under any circumstances, ever.

And it is definitely a learning problem you are having. You are facing the same problems as a new Linux user who just installed Manjaro with KDE 6 on Wayland and is wondering why apt-get and xrandr are not working even though those are accepted answers on Stackoverflow posts from 2012. Of course as experienced Linux users we know why, but a new one has to learn a lot of stuff before “getting it” and will probably stumble onto poor advice more than once in their journey. (And learning Nix is arguably worse than learning Linux for the first time, but that depends a bit on your exact experience and background.)

If you stick to learning NixOS there will be a point when these things seem trivial, but it will be a lot of effort to get there. Is that effort worth it? Well, if the term “declarative package management” doesn’t mean anything to you, maybe not. You do sacrifice a lot of things “just” to declare your entire system state in one configuration file (or more likely, directory). But I do think the things Nix does are really cool, if you can get over the, uh, everything.