| 20 Feb 2023 |
 Arson Copperflame | We could just build two installers 🤷
nixos-wsl-installer.tar.gz and nixos-wsl-installer-legacy.tar.gz | 22:53:55 |
| 21 Feb 2023 |
|  ythakur joined the room. | 08:28:47 |
 K900 | n | 08:44:23 |
| K900 | * Not sure I like that | 08:44:28 |
| K900 | Would get people even more confuse | 08:44:37 |
| K900 | * Would get people even more confused | 08:44:39 |
| K900 | I have a kind of cursed idea | 08:44:54 |
| 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 |
