| 28 Jul 2025 |
 jade_ | https://git.lix.systems/lix-project/lix/issues/936 | 02:20:18 |
 EsperLily [she/her] | hey here's a thought, if the cacert file is actually a store file (if you resolve the path), we could just hard-link it instead of copying it (though this probably only works for chroot, since you're using tmpDir otherwise and there's no guarantee that's on the same volume; you could also perhaps just use chrootRootDir even without chroot though?) | 02:22:26 |
| jade_ | i don't like this because i think it could equivalently be solved without more implementation complexity by a better file copy function | 02:24:26 |
 raitobezarius (DECT: 7248) | In reply to @esperlily:matrix.org
hey here's a thought, if the cacert file is actually a store file (if you resolve the path), we could just hard-link it instead of copying it (though this probably only works for chroot, since you're using tmpDir otherwise and there's no guarantee that's on the same volume; you could also perhaps just use chrootRootDir even without chroot though?) cacert is not a store file in general | 02:24:46 |
| EsperLily [she/her] | it should be on NixOS and nix-darwin? | 02:24:56 |
| raitobezarius (DECT: 7248) | 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 (DECT: 7248) | NixOS already does something quite different | 02:25:47 |
| raitobezarius (DECT: 7248) | which does not make any use of ssl-cert-file today? | 02:25:55 |
| raitobezarius (DECT: 7248) | 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 (DECT: 7248) | in practice | 02:26:20 |
| raitobezarius (DECT: 7248) | 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 (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 |
