Upstreaming plan

[RaitoBezarius]

Hi there, I stumbled on the paper, very cool, have you considered upstreaming parts of your work in nixpkgs? Can I help you do so?

[NiklasGollenstede]

Hi! Thanks for our interest!
I would quite much like to make our work practically available to others. That could mean upstreaming features (to nixpkgs or nix), but it could also mean to just spin them out into individual flake repos (first).

For example, even though we don't mention it in the paper, a significant effort leading up to our work was creating an automated NixOS installer, which we could use to try out various partitioning and filesystem schemes.
While I already used it in some other projects, I just recently spun the installer out into its own project: nixos-intaller. I would be very interested in getting feedback on that (usefulness, limitations, technical approach, ...), before potentially upsteaming it into nixpkgs. ((I have not yet adjusted reUpNix to use that new installer repo.))

Past that, I think it is best to start by identifying aspects of reUpNix that might make sense to make more reusable:

• Installation Minification (stripping parts of NixOS to make the dependency closure smaller): This should really become part of nixpkgs. It is already in a separate module split over several options. Most of these options could much better be implemented by modifying existing modules in nixpkgs, though (in some cases they already do force-override existing modules (see makeNixpkgsModuleConfigOptional, overrideNixpkgsModule, and the nixpkgs-* patches).
• Bootloader: The (fixed/hermetic) Nix-built bootloader configuration makes sense ony of you can update (/replace) it. I think the failure-atomic updating by replacing the GPT to switch between duplicated partition tables is really cool, but it would be recklessly fragile to ever do that manually. So this has a pretty hard dependency on (something like) the fully automated nixos-intaller (because that reliably and repeatably does the partitioning (in Nix)).
• OCI Integration: While I like the idea of using Nix to directly include OCI images and launching them via systemd-nspawn (and it has storage and probably also runtime benefits), we are unfortunately quite far from a production-worthy, drop-in solution.
• Differential Updating: I know that other people have been and are looking into making Nix update transmission more efficient. I think the unique thing of reUpNix's approach is that we want the update target to be as passive as possible, with an external (smart) "master" updater that does all the work. This also means though that our approach (as it is now) is not applicable for Nix updates in general (where usually the target runs Nix and pulls updates from a (rather) "dumb" source.
  The current implementation (nix store send) is as part of (/patch to) Nix. Given the limited scope, I am not sure whether that is the best long-term place for it.
  I think that the approach (pushing the difference between two root components) is the most appropriate for embedded systems (methodologically) and can be very efficient, but to actually use it, it would take someone to clean up the code (there are a lot of experimental options in the current implementation), use a better implementation of bsdiff (or an alternative), and write/update the receiving side.

So, yeah. There are definitely some things that would make sense to upstream in one way or another, but it looks to me that some of it will be quite a bit of work. I'll have to see how much time I can spend on it. So any help would certainly be appreciated!