| 28 Jul 2025 |
 raitobezarius | i'm mostly thinking about all the corporate usecases with their zscaler ca that comes from elsewhere | 02:25:20 |
 emily | I still think "add it to the store (potentially with optimization to not needlessly re-add an existing store path)" is the ~optimal solution modulo complexity | 02:25:21 |
 jade_ | and also lix on normal macos i think, since cacert goes into the system profile | 02:25:44 |
| raitobezarius | NixOS already does something quite different | 02:25:47 |
| raitobezarius | which does not make any use of ssl-cert-file today? | 02:25:55 |
| raitobezarius | nix-darwin does use ssl-cert-file and possibly this is a store path yeah | 02:26:07 |
| jade_ | for CoW filesystems (most modern fs), if our file copy is implemented correctly we can just have the copy be equivalent to hardlink | 02:26:11 |
| raitobezarius | in practice | 02:26:20 |
| raitobezarius | copying from /etc to /nix/var/nix/builds/ may or may not end up being optimized away | 02:26:39 |
| jade_ | i also agree that importing to the store should be able to be fast | 02:26:42 |
| jade_ | and is definitely a good way to remove edge cases from the sandbox setup code | 02:27:17 |
| raitobezarius | importing to the store introduces other complexities | 02:27:45 |
| raitobezarius | 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 | 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 | but 500KB copied on every FOD doesn't seem THAT problematic yet to me | 02:30:17 |
| raitobezarius | 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 | 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 | i mean, it might not be a performance problem now | 02:32:27 |
| raitobezarius | and maybe once we do enough scalability work | 02:32:32 |
| raitobezarius | 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 | 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 | this is the kind of tradeoffs i would like to make by not doing more optimization here | 02:33:02 |
