| 22 Aug 2024 |
 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 |
| K900 | With a lot of lazy evaluation and mutual recursion | 09:41:22 |
| K900 | And a not great GC | 09:41:26 |
| ElvishJerricco | I was going to say that the only reasonable way to use nix for these things would be to build bootable images for them on another machine, but even then you won't be building nixos images. 256M is a stretch for a nixos image, and 64M just almost certainly won't work | 09:42:59 |
| ElvishJerricco | you want an actual embedded OS, and nixos itself just isn't suited for that | 09:43:33 |
