| 28 Jul 2025 |
 jade_ | and is definitely a good way to remove edge cases from the sandbox setup code | 02:27:17 |
 raitobezarius (DECT: 7248) | importing to the store introduces other complexities | 02:27:45 |
| raitobezarius (DECT: 7248) | but EsperLily [she/her] do you perceive there will be a performance issue with this whole thing? | 02:29:53 |
 emily | the bind mount in the store makes this stuff weird | 02:29:56 |
| emily | * the bind mount of the store makes this stuff weird | 02:29:59 |
| raitobezarius (DECT: 7248) | i don't question the possibility for optimizations in the future | 02:30:01 |
 EsperLily [she/her] | it looks like this ultimately uses std::filesystem::copy. i sure hope that will use the appropriate call to make a copy-on-write clone, but that entirely depends on the std impl | 02:30:01 |
| raitobezarius (DECT: 7248) | but 500KB copied on every FOD doesn't seem THAT problematic yet to me | 02:30:17 |
| raitobezarius (DECT: 7248) | like the most it could do is add some latency I'd say | 02:31:09 |
| jade_ | llvm libc++ does https://github.com/llvm/llvm-project/blob/1b4db78d2eaa070b3f364a2d2b2b826a5439b892/libcxx/src/filesystem/operations.cpp#L302 | 02:31:15 |
| jade_ | concur | 02:31:23 |
| raitobezarius (DECT: 7248) | FOD work will probably be dominated by download speed and disk write speeds | 02:31:24 |
| EsperLily [she/her] | i don't know, i hope not, it just feels wasteful to be constantly copying a file around, especially when the file is in the nix store anyway. if Linux has been copying it the whole time then i suppose it's unlikely to be a performance problem | 02:31:53 |
| jade_ | I think we have clear evidence that if we wanted to make lix much faster we have other places to look than a 500kb file copy | 02:31:55 |
| raitobezarius (DECT: 7248) | i mean, it might not be a performance problem now | 02:32:27 |
| raitobezarius (DECT: 7248) | and maybe once we do enough scalability work | 02:32:32 |
| raitobezarius (DECT: 7248) | it will become one | 02:32:33 |
| jade_ | and tbh i think that the most productive thing is to just pick a resolution of code that is not too complex and works and deal with the perf later as we build better tools (e.g. tracing) to have any idea what our perf is like | 02:32:48 |
| raitobezarius (DECT: 7248) | and at that time, i hope we will be in a situation to make the "import to the store" solution work nicely | 02:32:49 |
| raitobezarius (DECT: 7248) | this is the kind of tradeoffs i would like to make by not doing more optimization here | 02:33:02 |
| raitobezarius (DECT: 7248) | obviously with Nix, we are mostly blind, for now | 02:33:25 |
| raitobezarius (DECT: 7248) | once we have more DTrace USDT probes, I hope to add some eBPF exporter to some of the Lix infra and more to examine more things | 02:33:37 |
| raitobezarius (DECT: 7248) | And then I hope I can capture some useful information on large scale performance regressions | 02:33:54 |
| raitobezarius (DECT: 7248) | (and also synthetic benchmarks for these types of regressions as well) | 02:34:03 |
| jade_ | yesss | 02:34:07 |
| EsperLily [she/her] | i will note that if the ssl-cert-file setting points to a path that has permissions problems, that probably wasn't a blocker for Lix before, but with the new code a permissions issue will throw an exception from pathExists() (you could change that pathExists() call to a pathAccessible(path, false) call since that's just pathExists() with a few error types caught). i don't know if this matters, it is weird to configure a path that Lix can't read | 02:34:12 |
| jade_ | might have annoying effects if the sysadmin thinks it's only read by the daemon or something mayb | 02:34:41 |
| raitobezarius (DECT: 7248) | In reply to @esperlily:matrix.org
i will note that if the ssl-cert-file setting points to a path that has permissions problems, that probably wasn't a blocker for Lix before, but with the new code a permissions issue will throw an exception from pathExists() (you could change that pathExists() call to a pathAccessible(path, false) call since that's just pathExists() with a few error types caught). i don't know if this matters, it is weird to configure a path that Lix can't read well there's the classical context problem | 02:35:39 |
| raitobezarius (DECT: 7248) | if you run nix with NIX_REMOTE=local as a user | 02:35:43 |
| raitobezarius (DECT: 7248) | vs. nix daemon | 02:35:46 |
