| 28 Jul 2025 |
 raitobezarius | obviously with Nix, we are mostly blind, for now | 02:33:25 |
| raitobezarius | 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 | And then I hope I can capture some useful information on large scale performance regressions | 02:33:54 |
| raitobezarius | (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 | 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 | if you run nix with NIX_REMOTE=local as a user | 02:35:43 |
| raitobezarius | vs. nix daemon | 02:35:46 |
| raitobezarius | and you use a path only readable by root | 02:35:49 |
| raitobezarius | 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 | My intent here was to increase debuggability | 02:36:08 |
| raitobezarius | if I didn't get it right, this is a bug | 02:36:20 |
| raitobezarius | 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 | is what I'm going for | 02:36:59 |
| raitobezarius | 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 | 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 | this is also a problem for other code paths | 02:38:10 |
| raitobezarius | 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 | i mean the technical debt in this codebase is what it is | 02:41:28 |
| raitobezarius | my biggest nightmares right now are really the StorePath class | 02:41:55 |
| raitobezarius | and how it goes from StorePath to string | 02:42:01 |
| raitobezarius | and what a disaster it is wrt to chroot, not chroot, sandbox, not sandbox, linux, not linux, etc. | 02:42:12 |
| raitobezarius | and I think I'm going to tackle this at some point | 02:42:29 |
| EsperLily [she/her] | that sounds like a mess | 02:42:47 |
