The Lutris FHS env does have many libraries used by Linux games. If you look at the package definition you'll see it has many more than the steam-run env. Trying to use steam-run inside Lutris is unlikely to resolve these issues. Do you have the Lutris runtime enabled?

That issue gives basically zero info on what's happening, theres a million reasons a game could be failing to install. Ive been using Lutris on NixOS for years and have rarely had issues.

How are you adding the game to lutris? Are you running it through nix-ld/steam-run inside lutris? Can you share an example of a game you're trying to run?

Edit: I hadn't run a native game through Lutris in a while so I grabbed a random one to make sure it hasn't just suddenly stopped working. I downloaded a couple from GOG and each is working as expected, so this sounds like it's most likely a configuration issue, not the Lutris package itself. Make sure you have "Disable Lutris runtime" checked off and "Prefer system libraries" checked on.

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.

I did notice lutris having its own FHS when upgrading, but aw man this looks pretty dam complicated, I'm like a week old to NixOS I have no idea how imma do this lmao, i did attempt the following

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

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

My understanding is that the NixOS Lutris package runs with a virtual FHS that is built with a selection of libraries for running Wine. I think that might mean it doesn't hook up libraries that are configured with nix-ld. If the game runs with steam-app, but not with Lutris, then it sounds like there's a library missing from the Lutris FHS.

You can override to fix that. Looking at the game logs could give you information about which libraries are missing. Or you could add in everything that steam-app uses, the way you configured nix-ld.

There's a configuration snippet that might point you in the right direction in this thread: https://discourse.nixos.org/t/nix-overlay-to-change-fhs-environment/54139/2

No, if something goes wrong with the VPN then the confined service will be unable to reach the internet. The setup runs the confined process in a network namespace that does not have a route to your default wifi or ethernet interfaces. If the VPN interface isn't set up correctly, or stops working there is no other route out.

You can test this with or without setting up VPN-Confinement. To do a quick test without any VPN setup, create a test service like this:

systemd.services.test-unit = {
  serviceConfig = {
    NetworkNamespacePath = "/run/netns/test";
    Type = "oneshot";
  };
  script = ''
    ${pkgs.iputils}/bin/ping 1.1.1.1
  '';
};

Create a matching network namespace that doesn't route anywhere:

sudo ip netns add test

Then set the unit running, and watch its output:

sudo systemctl start test-unit.service
journalctl -u test-unit.service -f

You'll see ping report that the network is unreachable. If you delete the namespace while ping is running it will continue to report that the network is unreachable.

sudo ip netns del test

(If you don't want to bother with a systemd unit, you can run a process in a given network namespace using sudo ip netns exec <namespace> <command>. For example, sudo ip netns exec test ping 1.1.1.1.)

If the namespace wasn't set up for whatever reason the confined service won't start. (See the edit on the post.)

I also did some tests with the VPN-Confinement setup with this test unit:

systemd.services.test-unit = {
  serviceConfig = {
    Type = "oneshot";
  };
  script = ''
    while true; do
      ${pkgs.curl}/bin/curl https://am.i.mullvad.net/connected
      sleep 5
    done
  '';
  vpnConfinement = {
    enable = true;
    inherit vpnNamespace;
  };
};

If I set vpnNamespace to a name that doesn't match a configured vpnNamespace then the service won't start.

If I bring down the VPN namespace while that curl loop is running with sudo systemctl stop wg.service then test-unit also stops, because of the systemd dependencies that systemd.services.<name>.vpnConfinement sets up.

If I bring down the network namespace manually while the curl loop is running with sudo ip netns del wg then the curl loop keeps running, and continues to report that it is connected to Mullvad. I guess the network namespace continues to exist while a running process is using it.

If I bring down the VPN network interface with sudo ip -n wg link set dev wg0 down then curl fails with status=6/NOTCONFIGURED

What happens when the VPN stops? Are all requests then just sent through the clear web?

Installing NixOS was a real bird-brained move, huh Kasane Teto?

I'll see myself out

I'm going to find someone who just uses arch

I use arch btw

Dude just restart your computer and roll back to a previous version of your relationship when everything wasn't fucked.

Not the first relationship to be destroyed by nixos 😢

Have a read of the thoughts of somebody with closer ties than myself.

I like flakes. They solve several problems and are convenient. Only oddity ive hit is that theyre a subset of the nix language. What am I missing? What would forward look like?

TL;DR lockfile with inputs (deps like nixpkgs) and consumable outputs (packages, shells, system)

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 already use Unix pass as my password manager and have a private git server for it. Is there a nice way to get that working with secrets in my config? I know that directly goes against the suggestion of SSH vs GPG, but I’ve already got lots of data saved within that system.

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).

Lots of good suggestions from people, and replying individually was going to be a mess. Please see the comment I added.

Lots of good suggestions from people, and replying individually was going to be a mess. Please see the comment I added.

Lots of good suggestions from people, and replying individually was going to be a mess. Please see the comment I added.

Lots of good suggestions from people, and replying individually was going to be a mess. Please see the comment I added.

God, I wish I could just do like a live coding session with a group to explain what I know and like and how to translate that into flakes and hm. Lots of good info and suggestions from everyone, but I feel I could explain myself better with my system in front of me. I get the flakes concept of locking a program to a particular version. I like that idea, but I also think I’m still in a stage of building out my system, discovering which packages I want. And I understand home manager is for handling my home folder and config within nix.

I can’t place it, but for some reason I don’t mind my config files living in .config, and keeping my system (for now) up to date and running the latest version of most software. That being said I of course see the value in both of these in the long term, especially as I work to build out a config I can install on all my systems and automatically toggles the correct modules based on device and user. I want that, but my repeat failure to get the flakes I want working, working, tells me I need to learn more base nix before I tackle that.

In fact I could tell I learned a lot when I had to figure out how to remove flakes and hm when I kind of got them working. While I had moved my config into home manager, I also broke a bunch of other things, rendering enough of my desktop environment non-functional (audio mostly lol), that I needed to do something. The solution I knew I could pull off was completely rewriting my config as a sort of in between of my single file Hyprland based config, to a directory of files and niri. Learning to properly import other files, learning about needing to include default.nix and how I can toggle which files are imported very easily with comments. The broader nix ecosystem started to make more sense.

I finally got good about using git, I made a folder structure that makes a lot of sense to me as far as parts of my config that are interoperable or machine specific. It’s clicking. I know the next step from that is probably flakes and hm, but again, the last time I tried to add those to my config, I broke way more than I fixed.

I feel just dumb enough with this that I’m not sure I’m comfortable sharing my config publicly yet. For example I haven’t implemented a secrets setup, so things like my syncthing IDs are in my config still.

As far as clearer goals. I’d like a config I can distribute across 3 machines (for now).

• A desktop running niri, and kind of for fun as much other rust based software as possible (iron bar, helix, etc.). I know there will have to be exceptions, but it’s been fun engaging with a lot of recent work using rust.
• A home server/nas/router using Podman for containers like Tailscale/wireguard, Jellyfin, audiobookshelf and such. If this can also handle my pihole/local dns and firewall that would be awesome, but I also have a RespberryPi I can dedicate to those.
• A living room PC that boots straight to steam big picture, and has all the emulator platforms I could ask for.

There’s many more thoughts prancing around in my head, but I don’t know how to prompt them.

when I first started using NixOS I was like you. I refused to use flakes and the home manager cause it just didn't make sense to me. Then I borked my system royally and had to reinstall. just going off the configuration.nix alone was...it was rough. possible but rough. So I decided to use flake, home manager, along with my configuration and then suddenly NixOS just clicked for me, I finally made sense.

using all 3 just makes your system easier to manage. For example say you use a WM and you want to keep your WM (like niri or hyprland or sway or i3 or whatever) config reproducible just like the rest of your system. Sure you can throw your entire config into the home manager OR you can simply have the home manager literally manage said config. Keep your config files in your "nixos-configs" directory along with your home, flake, and configuration.nix and repo all that, boom it's backed up and easy to reproduce if something goes wrong or you want to move your ENTIRE system to another computer. I do this for Niri, KDE, Yazi, Aerc, DOOM Emacs, Nvim, whatever I have a config for. So say I royally mess up a config for one of those programs or WMs just like my NixOS I can go back to a previous generation of one of them very easily thanks to my home manager.

Flakes are also good in case you want to use something that hasn't been packaged on NixOS. Say like some awesome TUI or application someone recently made you can input the git repo into your flake and then "install" it via your home manager. makes things easy.

It also helps to understand and manage if you sort what each thing does. For me I use my home.nix to list packages that I directly interact with. So stuff like Qutebrowser, floorp, steam, OBS, Krita, etc, etc are all in my home manager. stuff that's more backend/system dependent like git, libnotify, fzf, etc are in my configuration.nix i.e. the config of my OS while the home.nix is just like a package list and config files of things I'm more likely to interact with on a daily basis. It's easier to manage when things are separate like that.

I keep all of this stuff in its own directory that is a git repo. so before I rebuild I stage it all. then rebuild. if it's good commit it all, push it to my forgejo, boom instantly backed up. something goes wrong then I can either roll back a generation or clone the repo and rebuild from that.