| 11 Apr 2026 |
 pentane | fwiw i think it's perfectly on-topic, and I'm also interested in this | 06:45:11 |
 magic_rb | Not yet enough offtopic. I never thought of dyndrv as being monadic while normally were in applicative land, but damn youre right | 06:55:49 |
| magic_rb | Does bazel do sandbox setup? Cause assuming you dont use stdenv for your dyndrvs, then the only real thing nix does except for a fork exec is the sandbox setup | 07:37:36 |
| magic_rb | Maybe if we could reuse the sandbox for a group of dyndrvs? | 07:37:50 |
 jaen | It does have sandboxing, but it is less strict about it than Nix. With Nix you have to really try to make something non-reproducible, while with Bazel it's the other way around - it's not too hard to end up with "FFS why it does break with remote execution". | 07:40:51 |
| jaen | I guess it's historically because for Nix hermeticity was the point, while for Bazel it was just means for an end (hard to do webscale builds if you can't reliably cache) | 07:42:10 |
| jaen | Possibly? But then the trade-off becomes, I think, cache granularity. | 07:47:06 |
| jaen | One of the few downsides of Nix as opposed to Bazel is the default build granularity - for Bazel you are encouraged to go as granular as a single file, for Nix is more natural to go at a package granularity. And depending on how you chunk you, end up with different incrementality and early cut-off trade-offs, I think. But "Builds Systems a la Carte" is probably going to explain this better than me. | 07:49:30 |
| jaen | I haven't tested this specifically for building things together, but at least for planning (that is, creating dyndrvs as you go) the exact trade-off is you either rebuild more or you eat more of the overhead. | 07:51:01 |
| jaen | My hope is that there was something obvious missed in the PoC and now that I'll get paid to write it myself, there will be some easy fix lurking. Or if it not, I'll just keep pestering Ericson for fixes/guidance xD | 08:01:34 |
 neobrain | Thanks for the explanation, that's super interesting. I didn't even know about nix-ninja, sounds like plenty exciting stuff is happening in this space :) | 08:25:17 |
 Atemu | @jaen:matrix.org I'd highly recommend you try to dyndrv a bunch of stubs to test scaling before you try to make it work with a real build system | 10:09:35 |
| Atemu | IIRC I did something similar once and discovered sandbox creation overhead to be so massive that this granularity is simply infeasible | 10:10:45 |
| Atemu | And sandbox creation isn't something you can optimise that much further AFAIK | 10:12:17 |
| Atemu | (Ah, referring to per-file drvs here.) | 10:13:05 |
| magic_rb | If we could reuse the sandbox, as in cleaning out the build directory ought to be quick, we wouldnt have to set up a new sandbox from scratch | 10:16:34 |
| magic_rb | But idk | 10:16:38 |
| jaen | Yeah, what I was currently "doing" (or rather forcing Claude to do it for me - not going to say sorry for it, the only way I could reliably progress the PoCs between executive dysfunction and $DAY_JOB) and while it works well enough at the scale of Nix, at scale of Chromium and AOSP it buckles under itself in two different ways and the fixes seem to be in opposition to each other - having bigger chunks (so you rebuild more if something changes) vs. nesting more (so you pay more overhead, because you have more derivations). Now that I will hopefully be paid to do this full time, maybe I'll just find something the LLM was too dumb to chance upon. | 10:41:57 |
| jaen | Naively this goes with "bigger chunks" so you need to rebuild more on cache miss, I think. At least I couldn't side-step that so far. Alternatively, bazel seems to have a concept of persistent worker processes (https://bazel.build/remote/persistent), at worst maybe Nix could get something like that? | 10:43:57 |
| magic_rb | i mean not neccessarily | 10:44:15 |
| magic_rb | you can clean the sandbox, but not throw it away | 10:44:21 |
| magic_rb | if you kno youll be building 500 derivations you setup one sandbox and build everything in that sandbox with separate build directories. If i were to guess what takes the most time, its setting up the filesystem tree, but you can do that once with the union of all the closures. | 10:45:13 |
| magic_rb | Even if you end up having to setup separate pidnss or netnss it shouldnt be that slow | 10:50:26 |
| Atemu | You also have to mount store paths and I'm sure there are lots of relatively expensive steps necessary to ensure hermecity | 10:55:33 |
| jaen | I mean sure, but not with Nix as-is. I would assume those Bazel persistent workers are more less what you're talking about | 10:55:49 |
| Atemu | As I said, I tested this with a real nix-daemon a while ago and it did not scale | 10:56:12 |
| Atemu | I'm sure there are things you can do to make sandbox setups more efficient but not by that large of a perf gap | 10:57:02 |
| Atemu | But feel free to reproduce the experiment | 10:57:24 |
| jaen | I guess we'll see. Even if it's slower, then having to build less on cache just would be a win | 10:57:30 |
| jaen | * | 10:57:40 |
