| 19 Jan 2026 |
 Robert Hensing (roberth) | Shepherd Team
A team of 3-4 community members defined unanimously by the RFC Steering Committee, responsible for accepting or rejecting a specific RFC. | 15:28:38 |
 Mic92 | I maintain two binary caches that were implemented from scratch. It's not much work if you just want to validate a concept, proxies can be quiet easy. So if you want to move fast, just doing it from scratch might very doable. If you have to handle storage i.e. garbage collection, things get trickier. | 15:28:44 |
| Robert Hensing (roberth) | The responsibility of the team is to guide the discussion as long as it is constructive, new points are brought up and the RFC is iterated on and from time to time summarise the current state of discussion. If this is the case no longer, then the Shepherd Team shall step in with a motion for FCP. | 15:29:05 |
| Mic92 | If you don't care about too many feature, you can get a way with two http calls for narinfo and nar and a static one for narinfo | 15:29:59 |
| Mic92 | That's the theory, but in practice it's feels quiet overwhelming to having to respond to so many people. | 15:30:51 |
| Robert Hensing (roberth) | static one for nix-cache-info I think you mean | 15:30:59 |
| Mic92 | * That's the theory, but in practice it's feels quiet overwhelming to having to respond to so many people. With many of them just doing nitpicky reviews of the worst kind. | 15:31:22 |
| Mic92 | * If you don't care about too many feature, you can get a way with two http calls for narinfo and nar and a static one for nix-cache-info | 15:31:49 |
| Mic92 | * If you don't care about too many feature, you can get away with two http calls for narinfo and nar and a static one for nix-cache-info | 15:32:30 |
 infinisil | Robert Hensing (roberth): raboof Taeer Bar-Yam Mic92: Regarding lazy attrs, I stand by my previous conclusion that it should be opt-in with a builtins.lazyUpdate primop | 16:42:26 |
| infinisil | And to implement it, I believe the best way is to make attributes an abstract interface, and for lazyUpdate to create a separate underlying attribute set implementation that's based on two Values | 16:44:10 |
| infinisil | And in my PR I tried to create some automatic merge-into-a-single-attrs-if-both-sides-have-been-accessed thing, which was really complicated, but very necessary if you wanted it to be the standard // operator. By having an explicit primop opt-in, there's no need for this complexity, and it can always just be stored as two Values | 16:47:19 |
| infinisil | Although it looks like that wasn't part of my latest iteration :) | 16:48:54 |
| infinisil | * Although it looks like that wasn't part of my latest iteration anyways :) | 16:49:00 |
| infinisil | * Although it looks like that wasn't part of my latest iteration anymore :) | 16:49:04 |
 Sergei Zimmerman (xokdvium) | In reply to @infinisil:matrix.org
And in my PR I tried to create some automatic merge-into-a-single-attrs-if-both-sides-have-been-accessed thing, which was really complicated, but very necessary if you wanted it to be the standard // operator. By having an explicit primop opt-in, there's no need for this complexity, and it can always just be stored as two Values Wouldn’t it be more like a binary tree of Values of you chain multiple merges around? | 16:52:18 |
| Sergei Zimmerman (xokdvium) | And one that’s arbitrarily deep | 16:52:40 |
| infinisil | Yeah exactly | 16:52:45 |
| infinisil | I don't think that's a problem if it's opt-in. You can decide how the tree-structure should look like with how you write Nix code | 16:53:37 |
| Sergei Zimmerman (xokdvium) | Hm the stack usage is already unbounded, but that could make the situation even worse. I couldn’t really come up with a good algorithm for doing m-way merges with a binary tree that’s a bounded in stack usage | 16:54:20 |
| Sergei Zimmerman (xokdvium) | That’s why I went with a linked list for the structural sharing PR (don’t know if you saw that or not) | 16:54:44 |
| infinisil | (didn't see it) | 16:55:00 |
| Sergei Zimmerman (xokdvium) | https://github.com/NixOS/nix/pull/13987
That reduced nixpkgs-metrics memory usage from 27 GB to ~ 20GB | 16:56:04 |
| Sergei Zimmerman (xokdvium) | I really wanted to do a binary tree, but the on-demand m-way merge got a lot in the way | 16:56:47 |
| Robert Hensing (roberth) | work sesh about to start btw. I'll join after/with some food | 16:59:20 |
| Sergei Zimmerman (xokdvium) | In reply to @roberthensing:matrix.org
work sesh about to start btw. I'll join after/with some food Can’t make it today. Would be very happy if you’ll had a chance to do one more pass on the ssh-ng:// coroutine perf fix in https://github.com/NixOS/nix/pull/14998 | 17:00:53 |
| Sergei Zimmerman (xokdvium) | In reply to @roberthensing:matrix.org
work sesh about to start btw. I'll join after/with some food * Can’t make it today. Would be very happy if you all had a chance to do one more pass on the ssh-ng:// coroutine perf fix in https://github.com/NixOS/nix/pull/14998 | 17:01:04 |
 niksnut | left a comment | 17:22:38 |
| Sergei Zimmerman (xokdvium) | In reply to @niksnut:matrix.org
left a comment Addressed! Much simpler now | 20:33:09 |
| 20 Jan 2026 |
| Sergei Zimmerman (xokdvium) | Exciting times: https://www.phoronix.com/news/Linux-Open-Tree-Namespace | 10:23:54 |
