| 22 Aug 2024 |
 ElvishJerricco | imagine if we were so lucky that it would do legacy PC boot or uefi | 09:32:05 |
| ElvishJerricco | almost certainly it's something completely different and specific to the vendor | 09:32:16 |
| ElvishJerricco | e.g. the rpi ships a firmware partition, and the board knows to boot a start4.elf file from there, and that file knows how to look at config files on the firmware partition to find a raw binary image to load and execute | 09:33:15 |
 theelevated | just download the image and load nix to it. if the vendor is nice the config file is in the kernel and the firmware and device drivers are on github (thank god) | 09:34:14 |
| theelevated | saves the reverse engineering efforts | 09:35:05 |
 K900 | There is no "UEFI" or "legacy" on those boards | 09:35:05 |
| K900 | It's very bespoke | 09:35:07 |
| K900 | And very likely going to make no sense | 09:35:13 |
| K900 | And NixOS requires Perl at runtime unless you want to dip into extremely experimental options | 09:35:35 |
| K900 | And probably also Python | 09:35:41 |
| K900 | So if you really want a system you can rice to be as "bloat free" as possible, you're probably not looking at the right thing | 09:36:01 |
| theelevated | In reply to @k900:0upti.me
And NixOS requires Perl at runtime unless you want to dip into extremely experimental options os or package manager? | 09:36:55 |
| K900 | OS | 09:37:02 |
| ElvishJerricco | you're not going to get nix to work as a package manager at all on 256M of ram | 09:37:16 |
| ElvishJerricco | the best you'll do is use nix on another machine to build an image file you can boot | 09:37:26 |
| ElvishJerricco | but nixpkgs causes nix evaluation to take quite large amounts of ram for even basic things | 09:37:45 |
| theelevated | In reply to @elvishjerricco:matrix.org
you're not going to get nix to work as a package manager at all on 256M of ram i have the 64 mb version :> | 09:38:21 |
| ElvishJerricco | and even if you avoid eval'ing with copying NAR closures around, even importing NARs is pretty memory-intensive with Nix (though this has gotten better than it used to be) | 09:38:42 |
| ElvishJerricco | * and even if you avoid eval'ing withbycopying NAR closures around, even importing NARs is pretty memory-intensive with Nix (though this has gotten better than it used to be) | 09:38:48 |
| ElvishJerricco | * and even if you avoid eval'ing by copying NAR closures around, even importing NARs is pretty memory-intensive with Nix (though this has gotten better than it used to be) | 09:38:52 |
| theelevated | In reply to @k900:0upti.me
OS if we only patch the image and load the nix package manager | 09:39:10 |
| theelevated | could work?? | 09:39:14 |
| ElvishJerricco | again, there is no way to use it as a package manager on so little ram | 09:39:30 |
| K900 | Quite literally doing ANY operation with Nix requires ~2GB of RAM | 09:39:48 |
| theelevated | aint it just some c++ code like stated on the github? https://github.com/NixOS/nix | 09:40:20 |
| ElvishJerricco | is C++ somehow incapable of using significant amounts of memory? | 09:40:35 |
| theelevated | how can that clog up 2gb+ ?? | 09:40:37 |
| K900 | By evaluating a giant monorepo of package definitions | 09:40:56 |
| ElvishJerricco | programming languages don't determine how much memory is going to be used | 09:40:56 |
| K900 | Written in a bespoke language that the "some c++ code" is an implementation of | 09:41:09 |
