| 28 Jul 2025 |
 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 |
| raitobezarius (DECT: 7248) | this is also a problem for other code paths | 02:38:10 |
| raitobezarius (DECT: 7248) | thank you :) | 02:38:13 |
| EsperLily [she/her] | it bothers me how many of our filesystem helpers just happily throw exceptions without necessarily being obvious from the function call that it's going to do that. In many cases yeah a permissions problem should turn into a hard error, but in other cases it shouldn't, and because this is done with exceptions it's a silent problem and too easy to miss | 02:40:30 |
| raitobezarius (DECT: 7248) | i mean the technical debt in this codebase is what it is | 02:41:28 |
