| 21 Feb 2023 |
 K900 | We could have a small shim at /sbin/init in the installer that detects whether it's running as PID1 or not | 08:45:35 |
 Arson Copperflame | The installer would need to have /sbin/init anyway to work with native systemd. I don't even think it's that cursed - we just check if it's invoked | 08:48:02 |
| Arson Copperflame | Now that I think about it, there's a potential race condition here | 08:48:49 |
| K900 | We can always boot the installer in non-native-systemd and rebuild later | 08:49:02 |
| K900 | And now I'm starting to wonder how small we can make the installer if we just include a Nix and let it bootstrap from there | 08:50:00 |
| Arson Copperflame | I don't know how easy that would be though. But it might work, and if it does, we'd finally not have gigantic artifacts on every CI run | 08:52:48 |
| K900 | I don't see why it wouldn't work conceptually | 08:53:30 |
| K900 | But we'll need our own nixos-generate-config equivalent and such | 08:54:01 |
| Arson Copperflame | All we need is a working nix and our config files, including the default configuration.nix (with one version for legacy and one for native). Then we can just build the toplevel derivation, run result/bin/switch-to-configuration boot and then hand off to systemd or syschdemd | 08:56:45 |
| K900 | We probably want to power off the VM | 08:57:23 |
| K900 | In case we're switching to native systemd | 08:57:30 |
| Arson Copperflame | I'd just do all of that in init then, to be honest. So the installer always has systemd set to enabled, and detects whether or not it's been started as init or as a shell. It can then select the appropriate config template and hand off to the correct implementation once it's finished | 08:59:45 |
| Arson Copperflame | I know, that won't have any log output, but Windows users are used to staring at black screens telling them that it's "Getting Ready" or something, lol | 09:01:13 |
| K900 | The problem with that is that it'll be invoked as both an init and a shell | 09:01:19 |
| K900 | If it's the same thing | 09:01:32 |
| Arson Copperflame | We could add a generous timeout if it's in a shell so that if it's also started as init it will do something like print "Please wait while we're setting up your brand new NixOS experience (tm)" or cat dmesg | 09:03:08 |
| K900 | I was actually thinking the other way around | 09:03:33 |
| K900 | If it's started as init, just have it do nothing | 09:03:44 |
| K900 | And maybe set a flag | 09:03:48 |
| K900 | And if it's started as a shell, we can do interactive stuff | 09:03:59 |
| K900 | Kinda | 09:04:00 |
| Arson Copperflame | It could touch some file, and once the file is deleted it resumes to systemd. But then we'd still need to find out if it has been started ad all | 09:04:42 |
| K900 | I have an even more cursed idea | 09:05:30 |
| K900 | We can just call wsl.exe --version over interop | 09:05:39 |
| K900 | And know the version number | 09:05:48 |
| Arson Copperflame | I was thinking about that as well, but I don't think the output of that is stable. They completely changed it when switching to the store version and it's translated to the Windows display language, which might give us new and exciting encoding problems | 09:08:15 |
| K900 | There's also the obvious version of "just ask" | 09:08:53 |
| K900 | But that might confuse people | 09:09:02 |
| Arson Copperflame | In reply to @k900:0upti.me
There's also the obvious version of "just ask" That sounds like some preventable bug reports | 09:10:17 |
| Arson Copperflame | Could we just find out what executable PID 1 currently is? | 09:11:46 |
