| 15 Jun 2023 |
 @uep:matrix.org | yeah, all it can point to is the blank at that point | 16:27:32 |
 @elvishjerricco:matrix.org | It's not uncommon to have more expensive, redundant computations in the message field, since it's lazily evaluated. Sometimes people throw in calculations that would error if the assertion isn't false | 16:28:23 |
| @uep:matrix.org | fair | 16:28:55 |
| @elvishjerricco:matrix.org | So the message can calculate which mountpoints are busted | 16:28:57 |
| @uep:matrix.org | i'll look into this later, when it's not 02.30 | 16:29:33 |
| @uep:matrix.org | it's probably enough to just have "must not start with /" in the message | 16:31:24 |
 @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
lol yea it'd probably be helpful for testing it https://gist.github.com/lilyinstarlight/0597b656045ed7042fd200d0f0e9879f | 16:58:59 |
 K900 (deprecated) | Sadness | 17:18:35 |
| K900 (deprecated) | I still can't get amdgpu to not modeset on my desktop | 17:18:45 |
| K900 (deprecated) | It's triple monitors though | 17:18:49 |
| K900 (deprecated) | I get it | 17:18:50 |
| K900 (deprecated) | It's hard | 17:18:51 |
| @elvishjerricco:matrix.org | I still have no idea what modesetting really means | 17:19:39 |
| K900 (deprecated) | It just means switching the display mode | 17:20:04 |
| K900 (deprecated) | Like, ideally you'd want to maintain the same display mode from power on to desktop, and have all the boot stages realize it was set correctly by firmware and not touch it after | 17:20:42 |
| @lily:lily.flowers | Just nomodeset on the kernel cmdline, easy (/s) | 17:38:36 |
| @lily:lily.flowers | In reply to @k900:conduit.0upti.me
It's triple monitors though Same models or no? | 17:40:28 |
| K900 (deprecated) | That would be too easy lmao | 17:40:37 |
| @elvishjerricco:matrix.org | Anyone mind tossing a review at this? https://github.com/NixOS/nixpkgs/pull/237154 | 18:45:16 |
| @elvishjerricco:matrix.org | Lily Foster: Well, the plymouth update didn't end up improving the inexplicable 5-10 seconds that it takes for plymouth to start up in initrd. But I can at least say everything works as expected on my desktop! | 18:56:38 |
| @elvishjerricco:matrix.org | i am curious about that gist you linked though, so I'm going to mess with that for a minute | 18:57:00 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
Lily Foster: Well, the plymouth update didn't end up improving the inexplicable 5-10 seconds that it takes for plymouth to start up in initrd. But I can at least say everything works as expected on my desktop! 5-10 seconds to start up? In systemd-initrd? | 19:20:15 |
| @lily:lily.flowers | I've not seen that... | 19:20:20 |
| @lily:lily.flowers | I might ask you to share logs | 19:20:29 |
| @elvishjerricco:matrix.org | Lily Foster: Yea, plymouth has always taken about 6 seconds to get started and show a password prompt for me. Logs have indicated that basically nothing happens in the interim | 19:21:27 |
| @lily:lily.flowers | Would you mind nabbing logs with plymouth:debug on the kernel cmdline sometime? | 19:21:50 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
Anyone mind tossing a review at this? https://github.com/NixOS/nixpkgs/pull/237154 Any reason this was done as an import within the same file? | 19:24:54 |
| @elvishjerricco:matrix.org | In reply to @lily:lily.flowers
Any reason this was done as an import within the same file? I didn't really see another clean way to do it, without threading an isInitrd function parameter through the whole mkOption hierarchy or something like that | 19:34:51 |
| @elvishjerricco:matrix.org | In reply to @lily:lily.flowers
Any reason this was done as an import within the same file? * I didn't really see another clean way to do it, without threading an isInitrd function parameter through the whole commonOptions hierarchy or something like that | 19:35:03 |
| @elvishjerricco:matrix.org | since it's changing the default of an existing option | 19:35:15 |
