| 19 Jan 2026 |
Mic92 | But it's nicer if everyone use the same standard of course | 15:20:29 |
Mic92 | Right now cache.nixos.org is a rather big dataset that is hard to experiment with. | 15:22:14 |
Robert Hensing (roberth) | It is the most worthwhile though | 15:22:32 |
Robert Hensing (roberth) | Most worthwhile per byte even, I would argue ;) | 15:22:42 |
Robert Hensing (roberth) | But do ignore me if I'm just a whiny bitch | 15:23:19 |
Robert Hensing (roberth) | That is a very real possibility | 15:23:31 |
Mic92 | Yeah a lot RFCs are suffering from feature creap. | 15:23:40 |
Robert Hensing (roberth) | Maybe we need more version twos | 15:24:09 |
Robert Hensing (roberth) | At least this is a relatively transient and optional thing where going to a v2 isn't all that painful. Just switch | 15:24:53 |
Mic92 | As an RFCs author you are exposed to a multitude of opinions that can become noisy and contradict each other. | 15:25:04 |
Mic92 | I sometimes have a feeling the are too many cooks. | 15:25:22 |
raboof | Mic92: apropos binary cache proxies: at some point I want to build a binary cache proxy that does "fetch from upstream binary cache if there's a matching trusted independent rebuild attestation, otherwise rebuild myself". Any recommendations on whether I should base that on any existing cache proxy (which one?) or just keep it independent? It seems fairly simple (but that's famous last words :D ) | 15:25:30 |
Robert Hensing (roberth) | Well, that's the point, right? You get all the opinions, and then you decide | 15:25:41 |
Robert Hensing (roberth) | It creates a well-informed decision | 15:25:56 |
Mic92 | Well the problem is that you it's hard to decide which opinions you have to ignored. | 15:26:12 |
Mic92 | * Well the problem is that you it's hard to decide which opinions you have to ignore. | 15:26:17 |
Robert Hensing (roberth) | That is also something an RFC author should be able to decide IMO. With shepherds I guess | 15:26:58 |
raboof | * Mic92: apropos binary cache proxies: at some point I want to build a binary cache proxy that does "fetch from upstream binary cache if there's a matching trusted independent rebuild attestation, otherwise let/force me to rebuild myself". Any recommendations on whether I should base that on any existing cache proxy (which one?) or just keep it independent? It seems fairly simple (but that's famous last words :D ) | 15:28:04 |
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 |