| 28 Jul 2025 |
 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 |
| raitobezarius (DECT: 7248) | and you use a path only readable by root | 02:35:49 |
| raitobezarius (DECT: 7248) | either way, I will try to look at this once I'm less tired because I'm not exactly sure what you mean | 02:36:02 |
| raitobezarius (DECT: 7248) | My intent here was to increase debuggability | 02:36:08 |
| raitobezarius (DECT: 7248) | if I didn't get it right, this is a bug | 02:36:20 |
| raitobezarius (DECT: 7248) | if you intended to configure a CA file and it does not exist or is not accessible, you should get an error and unset it | 02:36:56 |
| raitobezarius (DECT: 7248) | is what I'm going for | 02:36:59 |
| raitobezarius (DECT: 7248) | because debugging why your FOD transfers files inside the build is harder | 02:37:08 |
| EsperLily [she/her] | the code that installs the certs calls pathAccessible(settings.caFile) first, that's the thing that I said needs to be pathAccessible(settings.caFile, true). But if that returns false, the code then checks if pathExists(settings.caFile) in order to throw a warning that the path exists but is inaccessible. Unfortunately if the path isn't accessible because of a permissions problem, then the pathExists call will throw an exception. So that pathExists should be pathAccessible(settings.caFile, false) (or pathAccessible(settings.caFile)), so that way a permissions problem just turns into false | 02:37:35 |
| EsperLily [she/her] | oops that was supposed to be a replyto this | 02:37:50 |
| EsperLily [she/her] | * oops that was supposed to be a reply to this | 02:37:54 |
| raitobezarius (DECT: 7248) | In reply to @esperlily:matrix.org
the code that installs the certs calls pathAccessible(settings.caFile) first, that's the thing that I said needs to be pathAccessible(settings.caFile, true). But if that returns false, the code then checks if pathExists(settings.caFile) in order to throw a warning that the path exists but is inaccessible. Unfortunately if the path isn't accessible because of a permissions problem, then the pathExists call will throw an exception. So that pathExists should be pathAccessible(settings.caFile, false) (or pathAccessible(settings.caFile)), so that way a permissions problem just turns into false well spotted | 02:38:05 |
