| 18 Aug 2025 |
 emily | merge queues would be very nice | 15:36:55 |
| emily | having two stacks that you have to babysit the rebase ordering of to get the tests happy to merge is tedious | 15:37:10 |
| emily | does the Snix thing for that not work well? | 15:37:16 |
 raitobezarius (DECT: 7248) | It has bugs and it would take much more energy to take care of these bugs or cleanup after a massive disaster in production | 15:37:36 |
| raitobezarius (DECT: 7248) | So until I have a window of opportunity for removing this painpoint, manual and tedious is fine as I have a bird view of everything and I know my way through all the ecosystem easily | 15:38:27 |
| raitobezarius (DECT: 7248) | The only problem are well, these situations :) | 15:38:32 |
| raitobezarius (DECT: 7248) | * The only problems are well, these situations :) | 15:38:35 |
| raitobezarius (DECT: 7248) | In reply to @raitobezarius:matrix.org
It has bugs and it would take much more energy to take care of these bugs or cleanup after a massive disaster in production (which are not a virtual problem, they happened.) | 15:40:38 |
| raitobezarius (DECT: 7248) | emily i verified what i wanted on cl/3852 | 15:43:19 |
| raitobezarius (DECT: 7248) | emily also consider abandoning the alternative path at this point | 15:43:47 |
| raitobezarius (DECT: 7248) | it confuse me always when i encounter while looking at the relation chain | 15:43:56 |
| raitobezarius (DECT: 7248) | (we can always un-abandon it if needed) | 15:44:02 |
| emily | 3869 you mean? can do when I get back to the stack. possibly later today. still have some thoughts I need to post about 3870 (but I've been running it and it's been fine) | 15:56:01 |
| emily | need to get the reproducibility stuff sent out to Nixpkgs but hopefully I will get to that part of the backlog today | 15:56:30 |
| raitobezarius (DECT: 7248) | dw | 17:47:03 |
| raitobezarius (DECT: 7248) | emily does https://git.lix.systems/lix-project/lix/issues/966#issue-14037 ring a bell to you? | 22:34:58 |
| raitobezarius (DECT: 7248) | sounds like something related to the range we just merged | 22:35:06 |
| raitobezarius (DECT: 7248) | it's a no sandboxing case so… | 22:35:12 |
| raitobezarius (DECT: 7248) | actually, the range is larger | 22:35:48 |
| emily | what's the tests right after the ones reported | 22:41:55 |
| emily | the flake ones are really slow but I guess not hours slow | 22:42:04 |
| raitobezarius (DECT: 7248) | obviously this would be too easy if the ordering was consistent | 22:43:51 |
| raitobezarius (DECT: 7248) | i don't know | 22:43:57 |
| raitobezarius (DECT: 7248) | asking more info | 22:44:26 |
| 19 Aug 2025 |
 Kira | hi! i noticed that libsodium, one of the crypto libraries needed for lix, is lead by someone who thinks that vibe coding is an effective way of building software: https://www.reddit.com/r/vibecoding/comments/1kmptbo/my_first_significant_100_vibecoded_project.
i don't know that much about libsodium, but just that fact that lix relies on a crypto library managed by one person already makes me nervous.
it looks like it was added to support ed25519 signing keys in 2015 for binary caches (https://git.lix.systems/lix-project/lix/commit/e0def5bc4b41ad09ce3f188bf522814ef3389e1f), but it looks like openssl supports them now too. would it be worth it to replace it with openssl and drop the dependency? | 01:42:40 |
| Kira | (i was mainly looking into jedisct1 because i was looking more into who works on dnscrypt-proxy2, but also noticed he maintains libsodium) | 01:46:47 |
| Kira | * (i was mainly looking into jedisct1 because i was looking more into who works on dnscrypt-proxy2, but also noticed he built & maintains libsodium) | 01:48:49 |
| emily | it would take an awful lot of vibe coding to get libsodium down to OpenSSL code quality tbh | 03:05:46 |
| Kira | lol well i was mainly just thinking openssl would be the most obvious alternative choice since it's already used for hashing - and it seems redundant to rely on two different crypto libraries | 03:19:52 |
| Kira | * lol well i was mainly just thinking openssl would be the most obvious alternative since it's already used for hashing - and it seems redundant to rely on two different crypto libraries | 03:21:56 |
