| 7 Nov 2024 |
 KFears (annoying) | Vaguely related q: how long have static builds been broken for? | 10:02:24 |
| KFears (annoying) | Maybe there's space for improving installer since we have static builds now | 10:02:45 |
 K900 | I do wonder if we can/should just do non-NixOS installs by just dropping a static binary somewhere yeah | 10:04:05 |
| KFears (annoying) | Btw, assuming we want to install static binary into the Nix store, there are no runtime dependencies right? Just the CA certs? | 10:06:38 |
| KFears (annoying) | (I do think dropping a static binary somewhere is a much better approach than using Nix store for this btw) | 10:07:15 |
| KFears (annoying) | That would also make upgrading extremely smooth | 10:07:54 |
| KFears (annoying) | Like, the whole upgrade procedure would just come down to replacing the binary with a newer version | 10:08:27 |
 Atemu | Lix is more than a single binary | 10:09:39 |
| Atemu | You need integrations with the system such as users, groups and shell hooks | 10:10:00 |
| Atemu | And the nix-daemon if course | 10:10:14 |
| Atemu | And even mounting the Nix store on some systems | 10:11:12 |
 V. 🏳️⚧️ | Yeah but point is, it is dramatically simpler | 10:11:28 |
| KFears (annoying) | Yeah, I might have given off the wrong impression, I don't try to say that we'll be able to drop installer and just distribute ready-to-go binaries, nuh-uh | 10:12:03 |
| KFears (annoying) | We'll still need the installer | 10:12:09 |
| KFears (annoying) | But the part that handles installing the package will be so much simpler, it's very nice | 10:12:58 |
| K900 | In reply to @atemu12:matrix.org
Lix is more than a single binary Yes, but upgrading a single binary is a lot easier | 10:14:37 |
| KFears (annoying) | Currently, Lix installation part of the installer is straight up miserable, we bundle a tarball with like manually copied Nix store paths with Lix, glibc, aws-sdk-cpp, curl and so much more | 10:15:17 |
| KFears (annoying) | And we like do a whole backflip to set up Lix to manage itself with those store paths, which means we hard depend on nix upgrade-nix or doing even more crimes to upgrade Lix using the installer | 10:16:08 |
| KFears (annoying) | And the alternative (which has a submitted CL) is basically re-implementing parts of the substitution process in Rust by hand ("parts" because doing the whole thing is miserable) | 10:17:20 |
| KFears (annoying) | And it's like a +800 LoC diff | 10:17:32 |
| KFears (annoying) | Compared to that, upgrading a static binary is just mv nix nix.old; curl <new-nix> -O nix | 10:18:45 |
| KFears (annoying) | Yeah, the more I think about it, the more I'm in favor of it, let's get binary releases and just drop the binary into like /nix/lix-binary or something, idk we'll figure it out | 10:20:49 |
| KFears (annoying) | might be a good time to merge all my silly little refactors too | 10:29:55 |
 ToxicFrog | Having been exposed to the innards of lix-installer, I am in favour of something that lets us prune big chunks of it. | 14:08:24 |
| ToxicFrog | (I also need to go back and clean up my risc-v patches and upstream them. In my copious free time. Sigh.) | 14:08:40 |
| KFears (annoying) | In reply to @toxicfrog:ancilla.ca
Having been exposed to the innards of lix-installer, I am in favour of something that lets us prune big chunks of it. Yeah, this is something I'm interested of as well | 14:09:31 |
| KFears (annoying) | This is the CL I'm most excited for
https://gerrit.lix.systems/c/lix-installer/+/2063 | 14:10:01 |
| KFears (annoying) | The whole "plan" thing is very annoying and bleeds into pretty much every code path for no reason | 14:10:37 |
| KFears (annoying) | * The whole "receipt" thing is very annoying and bleeds into pretty much every code path for no reason | 14:10:44 |
| ToxicFrog | Ooo | 14:11:10 |
