| 10 May 2026 |
 hexa | I'd say right now the problem is that renting aarch64-linux for cheap is not really possible | 20:49:27 |
 neobrain | Ah! nixos-dgx-spark overrides nixpkgs.config.cudaCapabilities in an attempt to improve compile times, but then the side effect of it is that the slim configuration isn't cached by flox. Resetting the variable gives me cache hits again | 20:50:21 |
| neobrain | Yup they do | 20:50:34 |
| neobrain | yeah that makes sense :( | 20:51:39 |
 Robbie Buxton | In reply to @hexa:lossy.network
I'd say right now the problem is that renting aarch64-linux for cheap is not really possible I don’t think it’s too bad in hyper scalers (graviton isn’t bad) not sure about other places tho | 20:54:26 |
| hexa | yeah, but cheap :D | 20:57:14 |
| Robbie Buxton | Last time I checked graviton was similar if not cheaper | 20:58:00 |
| neobrain | I'm guessing self-hosting has been considered but isn't an option? nvidia has a pretty generous marketing budget for free hardware | 21:01:09 |
 Gaétan Lepage | aarch64-linux support is definitely on our roadmap. For now, the critical blocker is getting access to relevant hardware. I'll give updates in this channel as soon as we get new opportunities in this regard. | 21:01:46 |
|  NixOS Moderation Botchanged room power levels. | 21:07:38 |
| 11 May 2026 |
| Gaétan Lepage | Looking for an approval on https://github.com/NixOS/nixpkgs/pull/517764 (cudaPackages.cudnn update).
connor (burnt/out) (UTC-8) maybe? | 15:52:02 |
 smudge (she/her) | Redacted or Malformed Event | 19:34:06 |
| smudge (she/her) | should the nixos wiki cuda page's cache section be corrected? it recommends the cache.nixos-cuda.org cache and doesn't mention others which lead me to assume it was the one for public use. is nix-community.cachix.org (per this announcement) the one that should be primarily recommended on the wiki? as well as information about using flox's nixpkgs repo and its cache? Or, if the nix-community.cachix.org isn't actually allowed to distribute should flox be the primary suggested cache?
also should the information for cache.nixos-cuda.org be retained, just with a proper disclaimer that it is for internal use only, or how would you like that to be handled? | 19:40:10 |
| smudge (she/her) | should the nixos wiki cuda page's cache section be corrected? it recommends the cache.nixos-cuda.org cache and doesn't mention others which lead me to assume it was the one for public use. is nix-community.cachix.org (per this announcement) the one that should be primarily recommended on the wiki? as well as information about using flox's nixpkgs repo and its cache? Or, if the nix-community.cachix.org isn't actually allowed to distribute should flox be the primary suggested way to access a cuda cache?
also should the information for cache.nixos-cuda.org be retained, just with a proper disclaimer that it is for internal use only, or how would you like that to be handled? | 19:44:22 |
| smudge (she/her) | should the nixos wiki cuda page's cache section be corrected? it recommends the cache.nixos-cuda.org cache and doesn't mention others which lead me to assume it was the one for public use. is nix-community.cachix.org (per this announcement) the one that should be primarily recommended on the wiki? as well as information about using flox's nixpkgs repo and its cache? Or, if the nix-community.cachix.org isn't technically allowed to distribute should flox be the primary suggested way to access a cuda cache?
also should the information for cache.nixos-cuda.org be retained, just with a proper disclaimer that it is for internal use only, or how would you like that to be handled? | 20:10:58 |
| smudge (she/her) | should the nixos wiki cuda page's cache section be corrected? it recommends the cache.nixos-cuda.org cache and doesn't mention others which lead me to assume it was the one for public use. is nix-community.cachix.org (per this announcement) the one that should be primarily recommended on the wiki? as well as information about using flox's nixpkgs repo and its cache? Or, if the nix-community.cachix.org isn't technically allowed to distribute should flox be the primary suggested way to access a cuda cache?
also should the information for cache.nixos-cuda.org be retained, just with a disclaimer that it is for internal use only? | 20:14:14 |
| 13 May 2026 |
| smudge (she/her) changed their display name from smudge to smudge (she/her). | 08:48:06 |
| 14 May 2026 |
|  weriomat joined the room. | 21:11:04 |
| 15 May 2026 |
|  Grayson Tinker changed their display name from graysontinker to Grayson Tinker. | 03:47:21 |
| 4 Aug 2022 |
|  Winter (she/her) joined the room. | 03:26:42 |
| Winter (she/her) | (hi, just came here to read + respond to this.) | 03:28:52 |
 tpw_rules | hey. i had previously sympathzied with samuela and like i said before had some of the same frustrations. i just edited my github comment to add "[CUDA] packages are universally complicated, fragile to package, and critical to daily operations. Nix being able to manage them is unbelievably helpful to those of us who work with them regularly, even if support is downgraded to only having an expectation of function on stable branches." | 03:29:14 |
| Winter (she/her) | In reply to @tpw_rules:matrix.org
i'm mildly peeved about a recent merging of something i maintain where i'm pretty sure the merger does not own the expensive hardware required to properly test the package. i don't think it broke anything but i was given precisely 45 minutes to see the notification before somebody merged it ugh, 45 minutes? that's... not great. not to air dirty laundry but did you do what samuela did in the wandb PR and at least say that that wasn't a great thing to do? (not sure how else to word that, you get what i mean) | 03:30:23 |
| tpw_rules | no, i haven't yet, but i probably will | 03:31:03 |
| Winter (she/her) | i admittedly did that with a PR once, i forget how long the maintainer was requested for but i merged it because multiple people reported it fixed the issue. the maintainer said "hey, don't do that" after and now i do think twice before merging. so it could help, is what i'm saying. | 03:31:50 |
| tpw_rules | i'm not sure what went wrong with the wandb PR anyway, i think it was just a boneheaded move on the maintainer's part | 03:32:10 |
| Winter (she/her) | (it was also simple enough that it was fine and the maintainer said it looked good after) | 03:32:15 |
| tpw_rules | * i'm not sure what went wrong with the wandb PR anyway, i think it was just a boneheaded move on the merger's part | 03:32:19 |
| tpw_rules | but i thought most of the frustration was around packages which don't really involve CUDA breaking the fragile CUDA packages, and i'm not sure how the warning helps in this case. it's not like nixpkgs-review prints out the comments. maybe i'm wrong. but it is a legitimate problem | 03:34:19 |
| Winter (she/her) | the frustration that i see is that people are touching packages that he maintains, am i missing further context here? | 03:35:09 |
