| 14 Jan 2026 |
 ginkogruen | Oh macOS could you please just work and not cause issues.
Thanks for the info I’ll guess then I’ll either run the slot machine or disable checks.
Thanks for looking into it or at least trying to come up with a fix to this. | 14:23:32 |
 raitobezarius | https://git.lix.systems/lix-project/lix/issues/1101 | 14:26:01 |
| raitobezarius | I assembled this quickly | 14:26:04 |
| raitobezarius | This is now pinned | 14:26:16 |
| raitobezarius | if we figure out a fix, we will send it to all released Lix versions as well | 14:27:00 |
| raitobezarius | tbh, it's also kinda our historical fault but heh | 14:27:16 |
|  @petrichor:envs.net changed their display name from Jez (-> @jez:cooperative.computer) to Jez → @jez:cooperative.computer. | 14:41:55 |
| @petrichor:envs.net left the room. | 14:43:01 |
 KFears (they/them) | In reply to @sofiedotcafe:matrix.org
@k900:0upti.me do you think running a homelab with data center software like open stack would be "fun", not practical but "fun" 😭 Fuck no | 15:03:46 |
| KFears (they/them) | I did Openstack as a job | 15:04:00 |
| KFears (they/them) | Basically there are like 5 services that work decently, everything else is best-effort. Dependencies between services are not always clear, there are a bunch of feature flags for everything, the whole thing is thousands of poorly written Python lines. The only real deployment mode is a bunch of shitty Ansible playbooks, they often need to be re-ran for reasons, communication between services is done with a central RabbitMQ, and the whole thing is basically a distributed monolith with no graceful failure at all. Many services don't work in default configuration, if they work at all. Each deployment is basically megabytes of poorly stitched custom configs, version cherry-picks, and patches to make it work at all | 15:13:46 |
| KFears (they/them) | It's like Kubernetes if Kubernetes was broken dysfunctional shit | 15:14:15 |
 hexa | it was yanked from nixpkgs years ago because it was unmaintainable garbage | 15:14:41 |
| hexa | but all that is … off-topic | 15:15:09 |
 K900 | Well the nice thing about it being unmaintainable is it's also unusable | 15:15:48 |
| K900 | So no one wants it anyway | 15:15:51 |
 Sofie 🏳️⚧️ (she/her) | thank you! | 15:44:27 |
 maralorn | Is it bad style to use fetchGit to load sources which are then used during eval? Does that count as IFD? | 19:25:29 |
 rosssmyth | fetchGit runs during eval, so no, it doesn't count as IFD. | 19:31:06 |
| maralorn | I think I am misunderstanding something. | 19:32:39 |
| maralorn | Why isn’t that used all the time e.g. to load large .json files with pins into nixpkgs without checking them in the repo? | 19:33:35 |
| maralorn | Is it not IFD but still forbidden in nixpkgs? | 19:33:50 |
| K900 | Forbidden on Hydra yes | 19:36:38 |
| K900 | Also generally evaluating nixpkgs offline is something people rely on | 19:38:11 |
 Acid Bong | not ifd, cuz builtin fetchers' outputs aren't derivations (this is why import (fetchTarball ...) is a valid Nix code and why remote Nix code (Npins, Flakes, etc) works in general) | 19:46:43 |
| Acid Bong | where are you suggesting to store them and keep them pure? | 19:47:51 |
| maralorn | Any github repo? Well it would be reasonably pure when you pin the commit. But of course when you have a cache miss you need network, which I understand is not a good idea for nixpkgs. | 19:49:21 |
 teo (they/he) | Eval time fetchers also tend to be quite bad for eval performance | 19:57:20 |
| maralorn | Even when they are cached? | 20:06:53 |
| teo (they/he) | The caching is a bit annoying cause it gets cached in the evaluating users xdg cache and it has a ttl | 20:35:56 |
