| 25 Mar 2023 |
7c6f434c | In reply to @matthewcroughan:defenestrate.it running at low MHz always, to get the best possible battery Pretty sure that CPUs are designed to make this is not the best possible battery, but nothing has enough load control to make the design come true | 12:50:06 |
matthewcroughan - nix.how | 1cpu 512M memory | 12:50:08 |
7c6f434c | Uhm, let me count the ways 512MiB is not enough for nixos-rebuild | 12:50:30 |
matthewcroughan - nix.how | nix evaluation right? | 12:50:37 |
matthewcroughan - nix.how | It would be enough if we could share the eval cache, something I know is not secure at the moment | 12:50:49 |
matthewcroughan - nix.how | And that is a design proposal, to be able to share eval cache | 12:51:13 |
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 |