| 2 Jun 2024 |
 K900 | https://github.com/antirez/linenoise/commits/master/ | 16:47:36 |
 aloisw | Even editline does not look as bad if you take "alive" as the metric. | 16:48:45 |
 ⚠️ eldritch horrors operating in this area ⚠️ | editline doesn't properly however | 16:49:49 |
| aloisw | (or readline, or libedit) | 16:50:49 |
| K900 | readline is GPL | 16:51:45 |
 Qyriad | In reply to@aloisw:kde.org
The maintenance state does not really inspire confidence (last release has a too many zeroes and then development stopped). The creator died. If we take it up we will probably just maintain it for ourselves | 16:57:43 |
| aloisw set a profile picture. | 18:01:38 |
| aloisw changed their profile picture. | 18:23:50 |
 jade_ | In reply to @aloisw:kde.org
The maintenance state does not really inspire confidence (last release has a too many zeroes and then development stopped). the maintainer Died | 20:01:18 |
| jade_ | i think we should just fork it and not worry about it | 20:02:56 |
| jade_ | because the thing is, these types of libs also don't need a lot of changes, and we wind up reading enough editline sources from it being fucked that we might as well just maintain a lib we actually like | 20:03:29 |
 @irenes:matrix.org | the main thing I'll say about readline-style libraries is run a fuzzer on them, there's a lot of Unicode corner cases | 20:38:44 |
| @irenes:matrix.org | but as far as adopting a project with a dead maintainer goes, yeah if it's useful to us, I say go for it | 20:39:01 |
| @irenes:matrix.org | (notice how I show great restraint and don't ask you to wait for my readline-esque library which will be ready for basic use at some point in the next five years) | 20:39:42 |
| @irenes:matrix.org | (assuming I survive etc lol) | 20:39:55 |
| ⚠️ eldritch horrors operating in this area ⚠️ | In reply to @irenes:matrix.org
(assuming I survive etc lol) readline-esque libraries as the opposite to life insurance? | 20:40:30 |
| ⚠️ eldritch horrors operating in this area ⚠️ | honest question: why should we support, in lix itself, store relocation via chroot as is done now (ie, single-user instances placing the store in eg ~/.nix-store but substituting/building for it being at /nix/store and "fixing" that at runtime with linux namespace fuckery)
we'd argue this should be a "just pam_mount it" type deal | 20:51:16 |
| @irenes:matrix.org | In reply to@pennae:matrix.eno.space
readline-esque libraries as the opposite to life insurance? hehe | 21:07:36 |
| @irenes:matrix.org | if pam_mount will let rpath and schebangs say /nix/store in them, then I personally don't see a need for one over the other | 21:08:13 |
| @irenes:matrix.org | chroot is the more general mechanism I think? it allows more than one of those to coexist | 21:08:28 |
| @irenes:matrix.org | but I don't know the details of pam_mount | 21:08:34 |
| @irenes:matrix.org | I can definitely think of cases involving testing or bring-up of other machines where I'd want more than one store, though it's ALMOST never needed | 21:09:02 |
| ⚠️ eldritch horrors operating in this area ⚠️ | you can combine pam_mount and pam_namespace to do what the chroot helper thing does, but for an entire user session | 21:11:24 |
| @irenes:matrix.org | oh neat! | 21:11:51 |
| @irenes:matrix.org | hm | 21:11:54 |
| @irenes:matrix.org | should it be tied to user sessions? | 21:11:58 |
| ⚠️ eldritch horrors operating in this area ⚠️ | this is just unnecessary complexity that is rarely if ever used, and only supported on linux to begin with | 21:11:59 |
| @irenes:matrix.org | isn't being able to do it per-invocation more flexible? | 21:12:09 |
| ⚠️ eldritch horrors operating in this area ⚠️ | In reply to @irenes:matrix.org
should it be tied to user sessions? it doesn't hurt since every session gets the same mounts anyway | 21:12:16 |
| ⚠️ eldritch horrors operating in this area ⚠️ | In reply to @irenes:matrix.org
isn't being able to do it per-invocation more flexible? not if the setup is always the same | 21:12:27 |
