[GH-ISSUE #371 ] Easier NVIDIA volume creation on NixOS #251

Owner

Originally created by @altano on GitHub (Mar 17, 2026).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/371

Hello,

For users on NixOS (which searching this repo's issues tells me is a non-zero number of users) the Quickstart can be simplified a bit, especially around the NVIDIA volume creation. I've created a re-usable flake that takes your NVIDIA package as input and then produces a usable volume for you. If your package changes (e.g. you update your nixos) it'll produce a new volume automatically.

The flake: https://github.com/altano/flakes/tree/main/wolf-nvidia-vol#how-to-use-it

Using it is as simple as:

Add to your flake.nix:

{
  inputs = {
    wolf-nvidia-vol = {
      url = "github:altano/flakes?dir=wolf-nvidia-vol";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };
}

Add to your Wolf service:

{
  config,
  pkgs,
  inputs,
  ...
}:
let
  wolfNvidiaVol = inputs.wolf-nvidia-vol.lib.mkWolfNvidiaVol {
    inherit pkgs;
    nvidiaPackage = config.hardware.nvidia.package;
    # libnvrtc is required by GStreamer's cudaconvertscale element for
    # NVENC hardware encoding. It's not included in the driver .run file.
    extraLibs = [ pkgs.cudaPackages.cuda_nvrtc.lib ];
  };
in
{
  virtualisation.oci-containers.containers.wolf = {
    volumes = [
      "${wolfNvidiaVol}:/usr/nvidia:ro"
    ];
    environment = {
      # Wolf passes this to child containers via Binds API — host paths work
      NVIDIA_DRIVER_VOLUME_NAME = "${wolfNvidiaVol}";
    };
  };
}

I've tested this in my local setup and it works perfectly. Might need more testing from other people to be considered robust though.

If you want this in the official docs, either feel free to add it or let me know and I can try to submit a PR to do it myself?

(heads up, I originally named this gow-nvidia-vol but renamed it to wolf-nvidia-vol)

Originally created by @altano on GitHub (Mar 17, 2026). Original GitHub issue: https://github.com/games-on-whales/wolf/issues/371 Hello, For users on NixOS (which searching this repo's issues tells me is a non-zero number of users) the Quickstart can be simplified a bit, especially around the NVIDIA volume creation. I've created a re-usable flake that takes your NVIDIA package as input and then produces a usable volume for you. If your package changes (e.g. you update your nixos) it'll produce a new volume automatically. The flake: https://github.com/altano/flakes/tree/main/wolf-nvidia-vol#how-to-use-it Using it is as simple as: Add to your flake.nix: ```nix { inputs = { wolf-nvidia-vol = { url = "github:altano/flakes?dir=wolf-nvidia-vol"; inputs.nixpkgs.follows = "nixpkgs"; }; }; } ``` Add to your Wolf service: ```nix { config, pkgs, inputs, ... }: let wolfNvidiaVol = inputs.wolf-nvidia-vol.lib.mkWolfNvidiaVol { inherit pkgs; nvidiaPackage = config.hardware.nvidia.package; # libnvrtc is required by GStreamer's cudaconvertscale element for # NVENC hardware encoding. It's not included in the driver .run file. extraLibs = [ pkgs.cudaPackages.cuda_nvrtc.lib ]; }; in { virtualisation.oci-containers.containers.wolf = { volumes = [ "${wolfNvidiaVol}:/usr/nvidia:ro" ]; environment = { # Wolf passes this to child containers via Binds API — host paths work NVIDIA_DRIVER_VOLUME_NAME = "${wolfNvidiaVol}"; }; }; } ``` I've tested this in my local setup and it works perfectly. Might need more testing from other people to be considered robust though. If you want this in the official docs, either feel free to add it or let me know and I can try to submit a PR to do it myself? (heads up, I originally named this `gow-nvidia-vol` but renamed it to `wolf-nvidia-vol`)

bsakaguchi added the

documentation

label

bsakaguchi commented

Author

Owner

@JBailes commented on GitHub (Mar 30, 2026):

@altano This has been built into the quickstart script. If you would review the already-merged PR at https://github.com/JBailes/wolf/pull/4 to verify it works on nix-os (And even better, test it yourself!), it would be great.

@JBailes commented on GitHub (Mar 30, 2026): @altano This has been built into the quickstart script. If you would review the already-merged PR at https://github.com/JBailes/wolf/pull/4 to verify it works on nix-os (And even better, test it yourself!), it would be great.

bsakaguchi commented

Author

Owner

@clsty commented on GitHub (Apr 28, 2026):

This works for me (modified from the nix file generated using https://github.com/JBailes/wolf ).

# NOTE: Also remember to write wolf-nvidia-vol in inputs!
{ config, pkgs, lib, ... }:
let
  wolfNvidiaVol = inputs.wolf-nvidia-vol.lib.mkWolfNvidiaVol {
    inherit pkgs;
    nvidiaPackage = config.hardware.nvidia.package;
    # libnvrtc is required by GStreamer's cudaconvertscale element for
    # NVENC hardware encoding. Not included in the driver .run file.
    extraLibs = [ pkgs.cudaPackages.cuda_nvrtc.lib ];
  };
in
{
  # Enable Docker (used by Wolf to launch game containers)
  virtualisation.docker.enable = true;

  # Udev rules for Wolf virtual input devices
  services.udev.extraRules = ''
    # Allows Wolf to acces /dev/uinput (only needed for joypad support)
    KERNEL=="uinput", SUBSYSTEM=="misc", MODE="0660", GROUP="input", OPTIONS+="static_node=uinput", TAG+="uaccess"

    # Allows Wolf to access /dev/uhid (only needed for DualSense emulation)
    KERNEL=="uhid", GROUP="input", MODE="0660", TAG+="uaccess"

    # Joypads
    KERNEL=="hidraw*",   ATTRS{name}=="Wolf PS5 (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9"
    SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9"
    SUBSYSTEMS=="input", ATTRS{name}=="Wolf PS5 (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9"
    SUBSYSTEMS=="input", ATTRS{name}=="Wolf gamepad (virtual) motion sensors", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9"
    SUBSYSTEMS=="input", ATTRS{name}=="Wolf Nintendo (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9"
  '';

  # Persistent directories for Wolf data
  systemd.tmpfiles.rules = [
    "d /etc/wolf 0755 root root -"
    "d /etc/wolf/cfg 0755 root root -"
    "d /etc/wolf/wolf-den 0755 root root -"
    "d /etc/wolf/covers 0755 root root -"
    "d /etc/wolf/steam 0755 root root -"
  ];

  # Wolf OCI containers
  virtualisation.oci-containers.backend = "docker";
  virtualisation.oci-containers.containers = {
    wolf = {
      image = "ghcr.io/games-on-whales/wolf:stable";
      environment = let
        wolfPortBase = 20000;
        port = offset: builtins.toString (wolfPortBase + offset);
      in
      {
        WOLF_RENDER_NODE = "/dev/dri/renderD128";
        NVIDIA_DRIVER_VOLUME_NAME = "${wolfNvidiaVol}";
        WOLF_CFG_FILE = "/etc/wolf/cfg/config.toml";
        WOLF_DOCKER_SOCKET = "/var/run/docker.sock";
        WOLF_SOCKET_PATH = "/var/run/wolf/wolf.sock";
        WOLF_HTTPS_PORT= port 0;
        WOLF_HTTP_PORT= port 5;
        WOLF_CONTROL_PORT= port 15;
        WOLF_RTSP_SETUP_PORT= port 26;
        WOLF_VIDEO_PING_PORT= port 116;
        WOLF_AUDIO_PING_PORT= port 216;
      };
      volumes = [
        "/etc/wolf:/etc/wolf:rw"
        "/var/run/docker.sock:/var/run/docker.sock:rw"
        "/var/run/wolf:/var/run/wolf:rw"
        "/dev/:/dev/:rw"
        "/run/udev:/run/udev:rw"
        "${wolfNvidiaVol}:/usr/nvidia:ro"
      ];
      extraOptions = [
        "--network=host"
        "--device=/dev/dri"
        "--device=/dev/uinput"
        "--device=/dev/uhid"
        "--device=/dev/nvidia0"
        "--device=/dev/nvidiactl"
        "--device=/dev/nvidia-modeset"
        "--device=/dev/nvidia-uvm"
        "--device=/dev/nvidia-uvm-tools"
        "--device-cgroup-rule=c 13:* rmw"
      ];
    };

    wolf-den = {
      image = "ghcr.io/games-on-whales/wolf-den:stable";
      environment = {
        WOLF_SOCKET_PATH = "/var/run/wolf/wolf.sock";
      };
      volumes = [
        "/etc/wolf/wolf-den:/app/wolf-den"
        "/etc/wolf/covers:/etc/wolf/covers"
        "/var/run/wolf:/var/run/wolf:rw"
      ];
      ports = [ "8081:8080" ];
      dependsOn = [ "wolf" ];
    };
  };
}

@JBailes According to my test, the generated Nix file has two problems, I've created a PR to fix it.

@clsty commented on GitHub (Apr 28, 2026): This works for me (modified from the nix file generated using https://github.com/JBailes/wolf ). ```nix # NOTE: Also remember to write wolf-nvidia-vol in inputs! { config, pkgs, lib, ... }: let wolfNvidiaVol = inputs.wolf-nvidia-vol.lib.mkWolfNvidiaVol { inherit pkgs; nvidiaPackage = config.hardware.nvidia.package; # libnvrtc is required by GStreamer's cudaconvertscale element for # NVENC hardware encoding. Not included in the driver .run file. extraLibs = [ pkgs.cudaPackages.cuda_nvrtc.lib ]; }; in { # Enable Docker (used by Wolf to launch game containers) virtualisation.docker.enable = true; # Udev rules for Wolf virtual input devices services.udev.extraRules = '' # Allows Wolf to acces /dev/uinput (only needed for joypad support) KERNEL=="uinput", SUBSYSTEM=="misc", MODE="0660", GROUP="input", OPTIONS+="static_node=uinput", TAG+="uaccess" # Allows Wolf to access /dev/uhid (only needed for DualSense emulation) KERNEL=="uhid", GROUP="input", MODE="0660", TAG+="uaccess" # Joypads KERNEL=="hidraw*", ATTRS{name}=="Wolf PS5 (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9" SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9" SUBSYSTEMS=="input", ATTRS{name}=="Wolf PS5 (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9" SUBSYSTEMS=="input", ATTRS{name}=="Wolf gamepad (virtual) motion sensors", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9" SUBSYSTEMS=="input", ATTRS{name}=="Wolf Nintendo (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9" ''; # Persistent directories for Wolf data systemd.tmpfiles.rules = [ "d /etc/wolf 0755 root root -" "d /etc/wolf/cfg 0755 root root -" "d /etc/wolf/wolf-den 0755 root root -" "d /etc/wolf/covers 0755 root root -" "d /etc/wolf/steam 0755 root root -" ]; # Wolf OCI containers virtualisation.oci-containers.backend = "docker"; virtualisation.oci-containers.containers = { wolf = { image = "ghcr.io/games-on-whales/wolf:stable"; environment = let wolfPortBase = 20000; port = offset: builtins.toString (wolfPortBase + offset); in { WOLF_RENDER_NODE = "/dev/dri/renderD128"; NVIDIA_DRIVER_VOLUME_NAME = "${wolfNvidiaVol}"; WOLF_CFG_FILE = "/etc/wolf/cfg/config.toml"; WOLF_DOCKER_SOCKET = "/var/run/docker.sock"; WOLF_SOCKET_PATH = "/var/run/wolf/wolf.sock"; WOLF_HTTPS_PORT= port 0; WOLF_HTTP_PORT= port 5; WOLF_CONTROL_PORT= port 15; WOLF_RTSP_SETUP_PORT= port 26; WOLF_VIDEO_PING_PORT= port 116; WOLF_AUDIO_PING_PORT= port 216; }; volumes = [ "/etc/wolf:/etc/wolf:rw" "/var/run/docker.sock:/var/run/docker.sock:rw" "/var/run/wolf:/var/run/wolf:rw" "/dev/:/dev/:rw" "/run/udev:/run/udev:rw" "${wolfNvidiaVol}:/usr/nvidia:ro" ]; extraOptions = [ "--network=host" "--device=/dev/dri" "--device=/dev/uinput" "--device=/dev/uhid" "--device=/dev/nvidia0" "--device=/dev/nvidiactl" "--device=/dev/nvidia-modeset" "--device=/dev/nvidia-uvm" "--device=/dev/nvidia-uvm-tools" "--device-cgroup-rule=c 13:* rmw" ]; }; wolf-den = { image = "ghcr.io/games-on-whales/wolf-den:stable"; environment = { WOLF_SOCKET_PATH = "/var/run/wolf/wolf.sock"; }; volumes = [ "/etc/wolf/wolf-den:/app/wolf-den" "/etc/wolf/covers:/etc/wolf/covers" "/var/run/wolf:/var/run/wolf:rw" ]; ports = [ "8081:8080" ]; dependsOn = [ "wolf" ]; }; }; } ``` @JBailes According to my test, the generated Nix file has two problems, I've created a [PR](https://github.com/JBailes/wolf/pull/12) to fix it.

bsakaguchi commented

Author

Owner

@altano commented on GitHub (Jun 1, 2026):

FWIW there are a couple of things here that aren't very idiomatic for nix:

having a bash script to generate a .nix file to install wolf
the virtualisation.oci-containers.containers.image being set to ghcr.io/games-on-whales/wolf:stable means the nix setup is not reproducible and always pulls the latest stable image

Plus you're maintaining a complicated wolf.nix in your personal configuration at that point.

If you want to support nix I would recommend going a different approach:

have a flake.nix in this repo that hides the complexity of setting up a wolf install behind a few configurable options
keep it up to date with releases in this repo

Then your install instructions go from "run wolf.sh, import wolf.nix into your user configuration" (very not nix) to "import this flake" (very nix). The downside: you'll be duplicating some work by keeping the flake.nix config options in sync with your docker container config options. If you're at all possibly amenable to going that route, I could demonstrate what that would look like by shipping a wolf flake in my repo so you can see an example. Let me know.

Oh, and regarding the docker image label/hash, I would recommend this (regardless of whether or not you keep the wolf.sh or make a flake.nix):

the ci task that publishes the container image should write the version and sha256 digest to a stable.json file in the repo
flake.nix would read stable.json (or wolf.nix or whatever uses the docker container)
~~you need a ci task (or re-use the docker publish one) that runs nix flake update to pick up the stable.json change and updates flake.lock~~ you don't even need this actually

I can potentially help with that too if you're interested. Let me know how you'd like to proceed:

disregard everything i'm saying, stick with current wolf.sh + wolf.nix
investigate ONLY pinning the docker version in the generated wolf.nix
investigate both the flake.nix in this repo and pinning the docker version

@altano commented on GitHub (Jun 1, 2026): FWIW there are a couple of things here that aren't very idiomatic for nix: - having a bash script to generate a .nix file to install wolf - the `virtualisation.oci-containers.containers.image` being set to `ghcr.io/games-on-whales/wolf:stable` means the nix setup is not reproducible and always pulls the latest stable image Plus you're maintaining a complicated wolf.nix in your personal configuration at that point. If you want to support nix I would recommend going a different approach: - have a flake.nix in this repo that hides the complexity of setting up a wolf install behind a few configurable options - keep it up to date with releases in this repo Then your install instructions go from "run wolf.sh, import wolf.nix into your user configuration" (very not nix) to "import this flake" (very nix). The downside: you'll be duplicating some work by keeping the flake.nix config options in sync with your docker container config options. If you're at all possibly amenable to going that route, I could demonstrate what that would look like by shipping a wolf flake in my repo so you can see an example. Let me know. Oh, and regarding the docker image label/hash, I would recommend this (regardless of whether or not you keep the wolf.sh or make a flake.nix): 1. the ci task that publishes the container image should write the version and sha256 digest to a stable.json file in the repo 2. flake.nix would read stable.json (or wolf.nix or whatever uses the docker container) 3. ~~you need a ci task (or re-use the docker publish one) that runs `nix flake update` to pick up the stable.json change and updates flake.lock~~ you don't even need this actually I can potentially help with that too if you're interested. Let me know how you'd like to proceed: 1. disregard everything i'm saying, stick with current wolf.sh + wolf.nix 2. investigate ONLY pinning the docker version in the generated wolf.nix 3. investigate both the flake.nix in this repo and pinning the docker version

bsakaguchi commented

Author

Owner

@altano commented on GitHub (Jun 1, 2026):

ALSO: in an ideal world, the runtime config which is still currently this mutable blob on the server that's modified out-of-band, would be configured via nix.

@altano commented on GitHub (Jun 1, 2026): ALSO: in an ideal world, the runtime config which is still currently this mutable blob on the server that's modified out-of-band, would be configured via nix.

bsakaguchi commented

https://github.com/altano/flakes/tree/main/wolf

Author

Owner

@altano commented on GitHub (Jun 3, 2026):

Okay, I felt like making this nix flake for some reason:

Usage is dead simple and doesn't require a bash script generating a wolf.nix. You just import the flake and use it. See the readme for examples.

It allows you to declaratively define config.toml options, user profiles, and apps from nix.

There's a nightly github CI action that generates a containers.json based on the latest sha hash of every Wolf docker image based on their tag, e.g. currently ghcr.io/games-on-whales/wolf:stable => sha256:8b0d3a744237f009e9ff5195672df82712f095475f7cc9e92dc8bcd8ac3a31dc, so people who use this flake will get the latest docker containers as published by you, without my needing to update manually, in a fully nix-friendly and reproducible way.

If you love it, I'd be happy to help you pull the flake into your repo. If you hate it then people who want it can just use it from my flake repo. Up to you, @JBailes !

@altano commented on GitHub (Jun 3, 2026): Okay, I felt like making this nix flake for some reason: https://github.com/altano/flakes/tree/main/wolf Usage is dead simple and doesn't require a bash script generating a wolf.nix. You just import the flake and use it. See [the readme](https://github.com/altano/flakes/tree/main/wolf#readme) for examples. It allows you to declaratively define config.toml options, user profiles, and apps from nix. There's a nightly github CI action that generates a [containers.json](https://github.com/altano/flakes/blob/main/wolf/generated/containers.json) based on the latest sha hash of every Wolf docker image based on their tag, e.g. currently `ghcr.io/games-on-whales/wolf:stable` => `sha256:8b0d3a744237f009e9ff5195672df82712f095475f7cc9e92dc8bcd8ac3a31dc`, so people who use this flake will get the latest docker containers as published by you, without my needing to update manually, in a fully nix-friendly and reproducible way. If you love it, I'd be happy to help you pull the flake into your repo. If you hate it then people who want it can just use it from my flake repo. Up to you, @JBailes !

bsakaguchi commented

Author

Owner

@clsty commented on GitHub (Jun 3, 2026):

Personally I think it'll be better to create/transfer-to a repo under this organization (games-on-whales), which could mean easier access for new users, more feedback and maintenance in long term. For both https://github.com/JBailes/wolf and https://github.com/altano/flakes .

For example,

If both of you agree, then we could combine these two repos into a new games-on-whales/wolf-quickstart.
If @altano agrees and @JBailes wants to keep JBailes/wolf as before, then we could transfer altano/flakes into a new games-on-whales/wolf-flakes.

And @ABeltramo I also need your opinion here.

@clsty commented on GitHub (Jun 3, 2026): Personally I think it'll be better to create/transfer-to a repo under this organization (games-on-whales), which could mean easier access for new users, more feedback and maintenance in long term. For both https://github.com/JBailes/wolf and https://github.com/altano/flakes . For example, - If both of you agree, then we could combine these two repos into a new `games-on-whales/wolf-quickstart`. - If @altano agrees and @JBailes wants to keep `JBailes/wolf` as before, then we could transfer `altano/flakes` into a new `games-on-whales/wolf-flakes`. And @ABeltramo I also need your opinion here.

bsakaguchi commented

Author

Owner

@JBailes commented on GitHub (Jun 3, 2026):

Personally I think it'll be better to create/transfer-to a repo under this organization (games-on-whales), which could mean easier access for new users, more feedback and maintenance in long term. For both https://github.com/JBailes/wolf and https://github.com/altano/flakes .

For example,

If both of you agree, then we could combine these two repos into a new games-on-whales/wolf-quickstart.

If @altano agrees and @JBailes wants to keep JBailes/wolf as before, then we could transfer altano/flakes into a new games-on-whales/wolf-flakes.

And @ABeltramo I also need your opinion here.

I tried to get the quickstart script on GOW before, Abe didn't like the idea ;)

@JBailes commented on GitHub (Jun 3, 2026): > Personally I think it'll be better to create/transfer-to a repo under this organization (games-on-whales), which could mean easier access for new users, more feedback and maintenance in long term. For both https://github.com/JBailes/wolf and https://github.com/altano/flakes . > > For example, > > * If both of you agree, then we could combine these two repos into a new `games-on-whales/wolf-quickstart`. > * If [@altano](https://github.com/altano) agrees and [@JBailes](https://github.com/JBailes) wants to keep `JBailes/wolf` as before, then we could transfer `altano/flakes` into a new `games-on-whales/wolf-flakes`. > > And [@ABeltramo](https://github.com/ABeltramo) I also need your opinion here. I tried to get the quickstart script on GOW before, Abe didn't like the idea ;)

bsakaguchi commented

Author

Owner

@clsty commented on GitHub (Jun 3, 2026):

I tried to get the quickstart script on GOW before, Abe didn't like the idea ;)

I see. And yes, that also makes sense cuz quickstart script isn't necessary for non-NixOS distros. We already have docker-compose.yml from GoW document which works quick and well.

However for NixOS users altano/flakes is almost a must-to-have, and the only way they'll get to know this repo would be searching issues, which probably happens after they've experienced painful hours on trying the docker-compose.yml from GoW document and find it not working at all on NixOS.

We could also write a note in GoW document about NixOS, however in that case we'd better provide a link to an official repo (games-on-whales/wolf-flakes, not exist yet) and maintain it for long-term.

@clsty commented on GitHub (Jun 3, 2026): > I tried to get the quickstart script on GOW before, Abe didn't like the idea ;) I see. And yes, that also makes sense cuz quickstart script isn't necessary for non-NixOS distros. We already have `docker-compose.yml` from GoW document which works quick and well. However for NixOS users `altano/flakes` is almost a must-to-have, and the only way they'll get to know this repo would be searching issues, which probably happens after they've experienced painful hours on trying the `docker-compose.yml` from GoW document and find it not working at all on NixOS. We could also write a note in GoW document about NixOS, however in that case we'd better provide a link to an official repo (`games-on-whales/wolf-flakes`, not exist yet) and maintain it for long-term.

bsakaguchi commented

Author

Owner

@ABeltramo commented on GitHub (Jun 3, 2026):

For completeness, here's my view of the quickstart script https://github.com/games-on-whales/wolf/pull/382#issuecomment-4182023584

As for NixOS, something like what was posted earlier by @clsty (https://github.com/games-on-whales/wolf/issues/371#issuecomment-4336228645) makes sense, and it looks to me like the Podman quadlet version that we have in the quickstart guide. I'd be happy to add something like that to the docs.
I kind of struggle to see the benefits of having something like altano/flakes in GOW..

First off the config.toml file isn't stable, it's versioned, and it will change between releases. Having that deep integrated into the flake means that every change to Wolf needs a change in the flake adding unnecessary maintenance burden to the project. On top of that, the file will be changed at runtime by Wolf (upgrading between versions, and when a user pairs via Moonlight) and obviously by WolfDen (via the Wolf APIs though, which is the stable way of configuring Wolf). Any change that happens there wouldn't be reflected in the state of the flake, potentially breaking things.

As for pinning down a version of Wolf for reproducibility, that's already part of Docker. You can pin down an image instead of pulling the latest :stable; this isn't a NixOS unique property. And the result wouldn't be reproducible anyway because Wolf will spin up additional images that aren't tied to the tag of the Wolf container. WolfUI also embeds a way to update the app images by pulling the latest. You could pin down all the images in your config.toml, but again, that's a property of Docker.

I'm sorry if this comes of as rude, but I need a very strong motivation for having to maintain another project, in another language. So far, I struggle to see the advantage apart from some easier ergonomics for NixOS users. And this is still missing the logic to support non Nvidia HW too, I wonder how much complexity that would add.

@ABeltramo commented on GitHub (Jun 3, 2026): For completeness, here's my view of the quickstart script https://github.com/games-on-whales/wolf/pull/382#issuecomment-4182023584 As for NixOS, something like what was posted earlier by @clsty (https://github.com/games-on-whales/wolf/issues/371#issuecomment-4336228645) makes sense, and it looks to me like the Podman quadlet version that we have in the quickstart guide. I'd be happy to add something like that to the docs. I kind of struggle to see the benefits of having something like `altano/flakes` in GOW.. First off **the config.toml file isn't stable**, it's versioned, and it will change between releases. Having that deep integrated into the flake means that every change to Wolf needs a change in the flake adding unnecessary maintenance burden to the project. On top of that, the file will be changed at runtime by Wolf (upgrading between versions, and when a user pairs via Moonlight) and obviously by WolfDen (via the Wolf APIs though, which is the stable way of configuring Wolf). Any change that happens there wouldn't be reflected in the state of the flake, potentially breaking things. As for pinning down a version of Wolf for reproducibility, that's already part of Docker. You can pin down an image instead of pulling the latest `:stable`; this isn't a NixOS unique property. And the result wouldn't be reproducible anyway because Wolf will spin up additional images that aren't tied to the tag of the Wolf container. WolfUI also embeds a way to update the app images by pulling the latest. You could pin down all the images in your `config.toml`, but again, that's a property of Docker. I'm sorry if this comes of as rude, but I need a very strong motivation for having to maintain another project, in another language. So far, I struggle to see the advantage apart from some easier ergonomics for NixOS users. And this is still missing the logic to support non Nvidia HW too, I wonder how much complexity that would add.

bsakaguchi commented

Author

Owner

@clsty commented on GitHub (Jun 3, 2026):

And this is still missing the logic to support non Nvidia HW too, I wonder how much complexity that would add.

FYI, https://github.com/games-on-whales/wolf/issues/371#issuecomment-4336228645 is a generated result, which is specific to Nvidia HW.

For both Nvidia HW and non Nvidia HW, altano/flakes and JBailes/wolf have already taken them into consideration.

@clsty commented on GitHub (Jun 3, 2026): > And this is still missing the logic to support non Nvidia HW too, I wonder how much complexity that would add. FYI, https://github.com/games-on-whales/wolf/issues/371#issuecomment-4336228645 is a generated result, which is specific to Nvidia HW. For both Nvidia HW and non Nvidia HW, `altano/flakes` and `JBailes/wolf` have already taken them into consideration.

bsakaguchi commented

Author

Owner

@ABeltramo commented on GitHub (Jun 3, 2026):

Not according to the README for altano/flakes though 😉

@ABeltramo commented on GitHub (Jun 3, 2026): Not according to the [README](https://github.com/altano/flakes/blob/main/wolf/README.md) for `altano/flakes` though 😉

bsakaguchi commented

Author

Owner

@clsty commented on GitHub (Jun 3, 2026):

For altano/flakes I can see it supporting non-Nvidia HW according to github.com/altano/flakes@07623e7a34/wolf/module.nix (L343-L349)

Update: Oh I missed the description.

GPU vendor. "none" (default) adds no GPU-specific config. "nvidia"
builds and mounts a driver volume via wolf-nvidia-vol and uses CDI.
"intel"/"amd" are reserved but not yet implemented.

@clsty commented on GitHub (Jun 3, 2026): For `altano/flakes` I can see it supporting non-Nvidia HW according to https://github.com/altano/flakes/blob/07623e7a34d728d6247b1e809aeb8a9f5a353bb4/wolf/module.nix#L343-L349 Update: Oh I missed the [description](https://github.com/altano/flakes/blob/07623e7a34d728d6247b1e809aeb8a9f5a353bb4/wolf/module.nix#L352-L354). > GPU vendor. "none" (default) adds no GPU-specific config. "nvidia" builds and mounts a driver volume via wolf-nvidia-vol and uses CDI. "intel"/"amd" are reserved but not yet implemented.

bsakaguchi commented

Author

Owner

@clsty commented on GitHub (Jun 3, 2026):

As for NixOS, something like what was posted earlier by @clsty (https://github.com/games-on-whales/wolf/issues/371#issuecomment-4336228645) makes sense, and it looks to me like the Podman quadlet version that we have in the quickstart guide. I'd be happy to add something like that to the docs.
I kind of struggle to see the benefits of having something like altano/flakes in GOW..

Well, my point is that if we're providing such config example for NixOS users in GoW document, then we'll also have to include a link to a non-GoW-official repo "github:altano/flakes?dir=wolf-nvidia-vol" in GoW document (this is a must for wolf-nvidia-vol to work):

{
  inputs = {
    wolf-nvidia-vol = {
      url = "github:altano/flakes?dir=wolf-nvidia-vol";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };
}

@ABeltramo If you think it's fine, then surely I'm also fine with it. I was just personally prefer a project to self-contain the directly relative part.

@clsty commented on GitHub (Jun 3, 2026): > As for NixOS, something like what was posted earlier by @clsty (https://github.com/games-on-whales/wolf/issues/371#issuecomment-4336228645) makes sense, and it looks to me like the Podman quadlet version that we have in the quickstart guide. I'd be happy to add something like that to the docs. > I kind of struggle to see the benefits of having something like altano/flakes in GOW.. Well, my point is that if we're providing such config example for NixOS users in GoW document, then we'll also have to include a link to a non-GoW-official repo `"github:altano/flakes?dir=wolf-nvidia-vol"` in GoW document (this is a must for `wolf-nvidia-vol` to work): ```nix { inputs = { wolf-nvidia-vol = { url = "github:altano/flakes?dir=wolf-nvidia-vol"; inputs.nixpkgs.follows = "nixpkgs"; }; }; } ``` @ABeltramo If you think it's fine, then surely I'm also fine with it. I was just personally prefer a project to self-contain the directly relative part.

bsakaguchi commented

Author

Owner

@altano commented on GitHub (Jun 3, 2026):

Intel/AMD are not supported yet with my flake as I don't have hardware to test on, so I can't add that. But, that doesn't mean you can't use Intel/AMD GPUs: you can use your Intel/AMD GPU if you configure it yourself, just like with the current quickstart script/nix config.

Taking a step back, let me try to summarize the conversation so far, which can hopefully guide the conversation:

Current approach - Bootstrap Bash Script:

There's a quick-start bash script which generates nix config.
The generated nix config is a thin abstraction to set things up. It's just the entire nix config you need to install wolf and has no dependencies.

Pros

There isn't a ton of maintenance burden on this org because the quick-start is not too complicated and does things similar to installation for other platforms. it's not 0 maintenance but it's not a lot either.
It's fully contained in this repo, and can be maintained alongside wolf.
If low-level things like the config format change, this approach keeps working, since it's a very thin abstraction.

Cons

It produces a non-trivial nix config that the user has to fold into their config.
That generated nix config can't be updated by this repo, so if we change the quick-start the user doesn't get the update.
It uses tagged version of all the docker images, so it's not reproducible
It doesn't allow declarative management of your Wolf config, profiles, apps, etc

My (@altano) wolf flake:

Pros

Manage apps, profiles, and Wolf's config.toml declaratively, fully configurable via the nix module.
Fully reproducible, uses docker image hashes that track the tags.
The amount of nix config the user adds is small.
The flake can be updated, and updates make their way to the user.
Can auto-configure NVIDIA GPU drivers (AMD/Intel not yet supported).

Cons

There's a LOT more code/nix config to maintain than the quick-start script. MUCH more.
If the low-level config.toml format changes, this flake breaks. And it does so automatically, as in a new version of stable docker image could break this flake when it gets automatically pulled in via the nightly GitHub action. The user's next nix flake update would pull the broken version.
There's a lot of things that have to be kept in sync with Wolf, from configuration, documentation, and implementation assumptions.

So what should we do?

I think there are two totally separate questions:

Does Wolf/GoW want to support NixOS as a first-class platform?
If yes, how should it do so?

The implementation details of my flake aren't super important until we decide the above.

My take - opinions start here!

I would argue that the quick-start bash script is probably not worth it and you shouldn't bother. It's not a bad idea! And some people might find it helpful. But it's so far from idiomatic Nix that it's probably not worth the maintenance burden to you all. That's for you to decide tho of course.

If you decide you want to support NixOS as a first-class platform, I would argue that the only way to do it is with a Nix flake that at least tries to accomplish some of the same goals as mine, whether or not it does so in the same way.

The implementation details are a totally separate question, such as:

Should we track the Docker images automatically or manually release those?
Should we manage the config.toml file directly or only go through the API?
Should the flake repackage Wolf directly without using the Docker image?
etc.

Apologies if I misrepresented anything in my recap above. Just trying to summarize things.

@altano commented on GitHub (Jun 3, 2026): Intel/AMD are not supported yet with my flake as I don't have hardware to test on, so I can't add that. But, that doesn't mean you can't use Intel/AMD GPUs: you can use your Intel/AMD GPU if you configure it yourself, just like with the current quickstart script/nix config. Taking a step back, let me try to summarize the conversation so far, which can hopefully guide the conversation: ## Current approach - Bootstrap Bash Script: - There's a quick-start bash script which generates nix config. - The generated nix config is a thin abstraction to set things up. It's just the entire nix config you need to install wolf and has no dependencies. ### Pros - There isn't a ton of maintenance burden on this org because the quick-start is not too complicated and does things similar to installation for other platforms. it's not 0 maintenance but it's not a lot either. - It's fully contained in this repo, and can be maintained alongside wolf. - If low-level things like the config format change, this approach keeps working, since it's a very thin abstraction. ### Cons - It produces a non-trivial nix config that the user has to fold into their config. - That generated nix config can't be updated by this repo, so if we change the quick-start the user doesn't get the update. - It uses tagged version of all the docker images, so it's not reproducible - It doesn't allow declarative management of your Wolf config, profiles, apps, etc ## My (@altano) wolf flake: ### Pros - Manage apps, profiles, and Wolf's config.toml declaratively, fully configurable via the nix module. - Fully reproducible, uses docker image hashes that track the tags. - The amount of nix config the user adds is small. - The flake can be updated, and updates make their way to the user. - Can auto-configure NVIDIA GPU drivers (AMD/Intel not yet supported). ### Cons - There's a LOT more code/nix config to maintain than the quick-start script. MUCH more. - If the low-level config.toml format changes, this flake breaks. And it does so automatically, as in a new version of `stable` docker image could break this flake when it gets automatically pulled in via the nightly GitHub action. The user's next `nix flake update` would pull the broken version. - There's a lot of things that have to be kept in sync with Wolf, from configuration, documentation, and implementation assumptions. ## So what should we do? I think there are two totally separate questions: 1. Does Wolf/GoW want to support NixOS as a first-class platform? 2. If yes, _how_ should it do so? The implementation details of my flake aren't super important until we decide the above. ## My take - opinions start here! I would argue that the quick-start bash script is probably not worth it and you shouldn't bother. It's not a bad idea! And some people might find it helpful. But it's so far from idiomatic Nix that it's _probably_ not worth the maintenance burden to you all. That's for you to decide tho of course. If you decide you want to support NixOS as a first-class platform, I would argue that the only way to do it is with a Nix flake that at least tries to accomplish some of the same goals as mine, whether or not it does so in the same way. The implementation details are a totally separate question, such as: - Should we track the Docker images automatically or manually release those? - Should we manage the config.toml file directly or only go through the API? - Should the flake repackage Wolf directly without using the Docker image? - etc. Apologies if I misrepresented anything in my recap above. Just trying to summarize things.

bsakaguchi commented

Author

Owner

@altano commented on GitHub (Jun 3, 2026):

Intel/AMD are not supported yet with my flake as I don't have hardware to test on, so I can't add that. But, that doesn't mean you can't use Intel/AMD GPUs: you can use your Intel/AMD GPU if you configure it yourself, just like with the current bootstrap script/nix config.

Taking a step back, let me try to summarize the conversation so far, which can hopefully guide the conversation:

Current approach - Bootstrap Bash Script:

There's a bootstrap bash script which generates nix config.
The generated nix config is a thin abstraction to set things up. It's just the entire nix config you need to install wolf and has no dependencies.

Pros

There isn't a ton of maintenance burden on this org because the bootstrap is not too complicated and does things similar to installation for other platforms. it's not 0 maintenance but it's not a lot either.
It's fully contained in this repo, and can be maintained alongside wolf.
If low-level things like the config format change, this approach keeps working, since it's a very thin abstraction.

Cons

It produces a non-trivial nix config that the user has to fold into their config.
That generated nix config can't be updated by this repo, so if we change the bootstrap the user doesn't get the update.
It uses tagged version of all the docker images, so it's not reproducible
It doesn't allow declarative management of your Wolf config, profiles, apps, etc

My (@altano) wolf flake:

Pros

Manage apps, profiles, and Wolf's config.toml declaratively, fully configurable via the nix module.
Fully reproducible, uses docker image hashes that track the tags.
The amount of nix config the user adds is small.
The flake can be updated, and updates make their way to the user.
Can auto-configure NVIDIA GPU drivers (AMD/Intel not yet supported).

Cons

There's a LOT more code/nix config to maintain than the bootstrap script. MUCH more.
If the low-level config.toml format changes, this flake breaks. And it does so automatically, as in a new version of stable docker image could break this flake when it gets automatically pulled in via the nightly GitHub action. The user's next nix flake update would pull the broken version. The breakage is easy to revert (you just go back to the previous flake hash and that fixes everything).
There's a lot of things that have to be kept in sync with Wolf, from configuration, documentation, and implementation assumptions.

So what should we do?

I think there are two totally separate questions:

Does Wolf/GoW want to support NixOS as a first-class platform?
If yes, how should it do so?

The implementation details of my flake aren't super important until we decide the above.

My take - opinions start here!

I would argue that the bootstrap bash script is probably not worth it and you shouldn't bother. It's not a bad idea! And some people might find it helpful. But it's so far from idiomatic Nix that it's probably not worth the maintenance burden to you all. That's for you to decide tho of course.

If you decide you want to support NixOS as a first-class platform, I would argue that the only way to do it is with a Nix flake that at least tries to accomplish some of the same goals as mine, whether or not it does so in the same way.

The implementation details are a totally separate question, such as:

Should we track the Docker images automatically or manually release those?
Should we manage the config.toml file directly or only go through the API?
Should the flake repackage Wolf directly without using the Docker image?
etc.

Apologies if I misrepresented anything in my recap above. Just trying to summarize things.

@altano commented on GitHub (Jun 3, 2026): Intel/AMD are not supported yet with my flake as I don't have hardware to test on, so I can't add that. But, that doesn't mean you can't use Intel/AMD GPUs: you can use your Intel/AMD GPU if you configure it yourself, just like with the current bootstrap script/nix config. Taking a step back, let me try to summarize the conversation so far, which can hopefully guide the conversation: ## Current approach - Bootstrap Bash Script: - There's a bootstrap bash script which generates nix config. - The generated nix config is a thin abstraction to set things up. It's just the entire nix config you need to install wolf and has no dependencies. ### Pros - There isn't a ton of maintenance burden on this org because the bootstrap is not too complicated and does things similar to installation for other platforms. it's not 0 maintenance but it's not a lot either. - It's fully contained in this repo, and can be maintained alongside wolf. - If low-level things like the config format change, this approach keeps working, since it's a very thin abstraction. ### Cons - It produces a non-trivial nix config that the user has to fold into their config. - That generated nix config can't be updated by this repo, so if we change the bootstrap the user doesn't get the update. - It uses tagged version of all the docker images, so it's not reproducible - It doesn't allow declarative management of your Wolf config, profiles, apps, etc ## My (@altano) wolf flake: ### Pros - Manage apps, profiles, and Wolf's config.toml declaratively, fully configurable via the nix module. - Fully reproducible, uses docker image hashes that track the tags. - The amount of nix config the user adds is small. - The flake can be updated, and updates make their way to the user. - Can auto-configure NVIDIA GPU drivers (AMD/Intel not yet supported). ### Cons - There's a LOT more code/nix config to maintain than the bootstrap script. MUCH more. - If the low-level config.toml format changes, this flake breaks. And it does so automatically, as in a new version of `stable` docker image could break this flake when it gets automatically pulled in via the nightly GitHub action. The user's next `nix flake update` would pull the broken version. The breakage is easy to revert (you just go back to the previous flake hash and that fixes everything). - There's a lot of things that have to be kept in sync with Wolf, from configuration, documentation, and implementation assumptions. ## So what should we do? I think there are two totally separate questions: 1. Does Wolf/GoW want to support NixOS as a first-class platform? 2. If yes, _how_ should it do so? The implementation details of my flake aren't super important until we decide the above. ## My take - opinions start here! I would argue that the bootstrap bash script is probably not worth it and you shouldn't bother. It's not a bad idea! And some people might find it helpful. But it's so far from idiomatic Nix that it's _probably_ not worth the maintenance burden to you all. That's for you to decide tho of course. If you decide you want to support NixOS as a first-class platform, I would argue that the only way to do it is with a Nix flake that at least tries to accomplish some of the same goals as mine, whether or not it does so in the same way. The implementation details are a totally separate question, such as: - Should we track the Docker images automatically or manually release those? - Should we manage the config.toml file directly or only go through the API? - Should the flake repackage Wolf directly without using the Docker image? - etc. Apologies if I misrepresented anything in my recap above. Just trying to summarize things.

bsakaguchi commented

Author

Owner

@altano commented on GitHub (Jun 3, 2026):

As for pinning down a version of Wolf for reproducibility, that's already part of Docker. You can pin down an image instead of pulling the latest :stable; this isn't a NixOS unique property.

Sure, in theory, but you'd have to write a script to update all the hard-coded Docker image hashes to do an update. No one does this for a reason: it's too hard/inconvenient. With NixOS you just run nix flake update wolf and you'd update Wolf and all the Docker images.

And the result wouldn't be reproducible anyway because Wolf will spin up additional images that aren't tied to the tag of the Wolf container.

All the additional images that are provided by GoW (e.g. Lutris) are handled in the same way. If you put them in your profile, you're getting pinned Docker images. The only ones that aren't pinned are the user's custom Docker images because we don't manage those, but those are probably versioned Dockerfiles in the repo anyway.

WolfUI also embeds a way to update the app images by pulling the latest. You could pin down all the images in your config.toml, but again, that's a property of Docker.

Sure but this is a manual, not automatic, action, and redeploying your flake will revert the images. This is fairly standard Nix behavior.

I'm sorry if this comes of as rude, but I need a very strong motivation for having to maintain another project, in another language.

Not at all! The maintenance burden is real and you having concerns is extremely expected. It's not rude at all.

So far, I struggle to see the advantage apart from some easier ergonomics for NixOS users.

I hope I explained above why this approach improves the ergonomics a lot!

@altano commented on GitHub (Jun 3, 2026): > As for pinning down a version of Wolf for reproducibility, that's already part of Docker. You can pin down an image instead of pulling the latest :stable; this isn't a NixOS unique property. Sure, in theory, but you'd have to write a script to update all the hard-coded Docker image hashes to do an update. No one does this for a reason: it's too hard/inconvenient. With NixOS you just run `nix flake update wolf` and you'd update Wolf and all the Docker images. > And the result wouldn't be reproducible anyway because Wolf will spin up additional images that aren't tied to the tag of the Wolf container. All the additional images that are provided by GoW (e.g. [Lutris](https://github.com/altano/flakes/blob/main/wolf/generated/containers.json#L23-L29)) are handled in the same way. If you put them in your profile, you're getting pinned Docker images. The only ones that aren't pinned are the user's custom Docker images because we don't manage those, but those are probably versioned Dockerfiles in the repo anyway. > WolfUI also embeds a way to update the app images by pulling the latest. You could pin down all the images in your config.toml, but again, that's a property of Docker. Sure but this is a manual, not automatic, action, and redeploying your flake will revert the images. This is fairly standard Nix behavior. > I'm sorry if this comes of as rude, but I need a very strong motivation for having to maintain another project, in another language. Not at all! The maintenance burden is real and you having concerns is extremely expected. It's not rude at all. > So far, I struggle to see the advantage apart from some easier ergonomics for NixOS users. I hope I explained above why this approach improves the ergonomics a lot!

bsakaguchi commented

Author

Owner

@ABeltramo commented on GitHub (Jun 4, 2026):

Sure, in theory, but you'd have to write a script to update all the hard-coded Docker image hashes to do an update. No one does this for a reason: it's too hard/inconvenient. With NixOS you just run nix flake update wolf and you'd update Wolf and all the Docker images.

But.. you did exactly that 😅 You've created the script it's not a unique property of NixOS.

I think we are pretty much on the same page on the pros/cons. Personally I don't use NixOS, so I'm not going to add first support for it. I also personally think that it shouldn't be that complex: your repo is quite large already, with the main module.nix close to 1000 lines. But that's just me rambling at this point..

Anyway, the project is open source, anyone is free to do it; would any of you want to be an official maintainer of the flake? Does NixOS manage this like other distros where packages are done and maintained by the community outside the original upstream repos?

I'm open to ideas, I'd be happy to link to an external repo officially in the docs and/or bring such a repo directly into our org. We already have quite a few subprojects that aren't necessarily maintained by me personally but are more of a "community project".

@ABeltramo commented on GitHub (Jun 4, 2026): > Sure, in theory, but you'd have to write a script to update all the hard-coded Docker image hashes to do an update. No one does this for a reason: it's too hard/inconvenient. With NixOS you just run nix flake update wolf and you'd update Wolf and all the Docker images. But.. you did exactly that 😅 You've created [the script](https://github.com/altano/flakes/blob/main/wolf/update-containers.sh) it's not a unique property of NixOS. I think we are pretty much on the same page on the pros/cons. Personally I don't use NixOS, so I'm not going to add first support for it. I also personally think that it shouldn't be that complex: your repo is quite large already, with the main `module.nix` close to 1000 lines. But that's just me rambling at this point.. Anyway, the project is open source, anyone is free to do it; would any of you want to be an official maintainer of the flake? Does NixOS manage this like other distros where packages are done and maintained by the community outside the original upstream repos? I'm open to ideas, I'd be happy to link to an external repo officially in the docs and/or bring such a repo directly into our org. We already have quite a few subprojects that aren't necessarily maintained by me personally but are more of a "community project".

bsakaguchi commented

Author

Owner

@altano commented on GitHub (Jun 6, 2026):

Personally I don't use NixOS, so I'm not going to add first support for it.

Seems extremely straightforward.

would any of you want to be an official maintainer of the flake?

Maybe the best course of action though is to just reference my flake as a community resource in the install instructions for NixOS users and dump the quickstart/bootstrap script? There's probably no reason to make my flake an official part of the org if you have no intention of using NixOS or maintaining it. Unless there's a benefit I'm missing. The pointer to the flake should enable discovery and that's the important thing.

Thoughts everyone?

I'm ultimately happy to help maintain it either way, as long as I'm an active Wolf user. Whether you want to absorb the flake into the org or just leave it on my user, it's fine by me and I will pitch in.

But.. you did exactly that 😅 You've created the script it's not a unique property of NixOS.

That's fair, heh, BUT: I can write 50 lines of bash in the flake and then no one else is managing the docker hashes, meanwhile you're suggesting USERS can write such a script. In my case the flake users don't need it. With Docker, you can't abstract that away. But whatever, this isn't really important anyway.

@altano commented on GitHub (Jun 6, 2026): > Personally I don't use NixOS, so I'm not going to add first support for it. Seems extremely straightforward. > would any of you want to be an official maintainer of the flake? Maybe the best course of action though is to just reference my flake as a community resource in the install instructions for NixOS users and dump the quickstart/bootstrap script? There's probably no reason to make my flake an official part of the org if you have no intention of using NixOS or maintaining it. Unless there's a benefit I'm missing. The pointer to the flake should enable discovery and that's the important thing. Thoughts everyone? I'm ultimately happy to help maintain it either way, as long as I'm an active Wolf user. Whether you want to absorb the flake into the org or just leave it on my user, it's fine by me and I will pitch in. > But.. you did exactly that 😅 You've created [the script](https://github.com/altano/flakes/blob/main/wolf/update-containers.sh) it's not a unique property of NixOS. That's fair, heh, BUT: I can write 50 lines of bash in the flake and then no one else is managing the docker hashes, meanwhile you're suggesting USERS can write such a script. In my case the flake users don't need it. With Docker, you can't abstract that away. But whatever, this isn't really important anyway.

bsakaguchi commented