| 25 Mar 2023 |
 7c6f434c | Not sure how well NixOS module system would work for sharing eval caches between non-identical systems
| 12:51:22 |
 matthewcroughan - nix.how | Yeah me neither, I'm just thinking there are no limitations and what the design would look like without limitations | 12:51:41 |
| 7c6f434c | I mean, I don't like NixOS modules for any of the other reasons either… | 12:51:59 |
| matthewcroughan - nix.how | to me, the perfect setup is nix running everywhere for every purpose, to keep everything isomorphic | 12:52:00 |
| 7c6f434c | I kind of want enough RAM to run Nix evaluation on almost everything, that's true… | 12:52:52 |
| 7c6f434c | But for many purposes I am mostly fine with Nix-on-whatever | 12:53:15 |
| 7c6f434c | (Assuming a somewhat clueless but not too malicious and already platform-adapted carrier system) | 12:53:53 |
| matthewcroughan - nix.how | In reply to @7c6f434c:nitro.chat
I kind of want enough RAM to run Nix evaluation on almost everything, that's true… No I mean sharing eval cache would prevent that from being a problem, optionally | 12:56:19 |
| matthewcroughan - nix.how | there are ways we can keep it isomorphic just by messing around with caches and stuff, and fix these problems just like that | 12:56:39 |
| 7c6f434c | If you give up on «actually can eval anywhere», I won't call Nix the ideal setup. Maybe looking at what Guix did, noticing it is still not the best direction, and designing a new Nix-like-tolerable-on-low-RAM without giving up on data-crunching-completeness… | 12:58:39 |
| matthewcroughan - nix.how | I quite like the idea of hosting the top level closures somewhere like latest.mysytem.com and then having systemd pull it down on a regular basis and activate it | 13:01:24 |
| 7c6f434c | (I am not saying I have a coherent vision how it would be, not yet) | 13:01:26 |
| matthewcroughan - nix.how | There's no nix involved in that | 13:01:29 |
| 7c6f434c | Well, without Nix usable for configuration… | 13:01:42 |
| 7c6f434c | I guess the next level is a cheap subscription service where you can fine-tune your system and add the closure to the update service… Given Nix deduplication, it won't scale too badly | 13:03:45 |
| matthewcroughan - nix.how | I don't really get it, you can self host all this super easy | 13:04:59 |
| matthewcroughan - nix.how | The webroot of the system closure is one line of nix | 13:05:17 |
| matthewcroughan - nix.how | https://github.com/MatthewCroughan/nixcfg/blob/master/hosts/hetznix/modules/androidUpdate.nix#L8 | 13:05:38 |
| 7c6f434c | Well, if you wanted to sell devices pre-flashed! | 13:05:39 |
| matthewcroughan - nix.how | Like here's how I do the same for my robotnix device | 13:05:45 |
| 7c6f434c | You kind of want people to be able to use it without having touched Nix on Aarch64 yet | 13:06:00 |
| matthewcroughan - nix.how | In reply to @7c6f434c:nitro.chat
Well, if you wanted to sell devices pre-flashed! If you're suggesting that we do devices with secure boot, with our keys loaded and stuff, that would be cool | 13:06:14 |
| 7c6f434c | I guess sourcing Aarch64 with non-malicious Secure Boot is maybe doable but surely a pain | 13:06:57 |
| matthewcroughan - nix.how | And we'd provide a service where you give us closures and we deploy as long as you have mobile-nixos.updater.enable = true and a URL pointed at update.mobile-nixos.org, yeah.. | 13:07:03 |
| 7c6f434c | Nah-nah-nah! You give us configurations and we add it to the list of closures to provide in cache | 13:07:44 |
| 7c6f434c | User has an option to not think in terms of building on the target arch | 13:08:11 |
| matthewcroughan - nix.how | So you even build it too? That's cool | 13:08:52 |
| 7c6f434c | I mean, I myself currently optimise for evaluating on my devices then just pulling from Hydra | 13:09:28 |
| 7c6f434c | (and then I try to trim the base system and install stuff I actually care about from Nix, without bothering with the low-level installs outside my laptop) | 13:10:26 |
|  @valconius:matrix.org joined the room. | 23:43:48 |
