fuse-overlayfs VS nix-config

Maybe something like this? https://github.com/containers/fuse-overlayfs

install static fuse-overlayfs by following "static build" section on https://github.com/containers/fuse-overlayfs

echo "Downloading fuse-overlayfs" mkdir -p /usr/local/bin curl -L https://github.com/containers/fuse-overlayfs/releases/latest/download/fuse-overlayfs-x86_64 > /usr/local/bin/fuse-overlayfs chmod +x /usr/local/bin/fuse-overlayfs

Just the other week I used Nix on my laptop to derive a PXE boot images, uploaded those to IPFS, and netbooted my server in another country over a public IPFS mirror. The initrd gets mounted as read-only overlayfs on boot. My configs are public: https://github.com/jhvst/nix-config

You should look into configuring your neovim with home-manager. This wraps the tools needed for various language servers in a way that solves your concern. Upside is that now you can also move the whole neovim configuration into servers etc., if you prefer that, just by importing your neovim configuration. I have done this in my configuration.

Plugging my own thing here, but I have been experimenting with a Nix configuration for gaming only. My configuration is here (for Nvidia, which does not work without tinkering as AMD does) : https://github.com/jhvst/nix-config/blob/main/nvidia.nix

First, this is a whole system specification. This means that executing this on Nix will build you a whole OS image. You can build the image if you have Nix by running the first line on file. You can also use Docker with the instruction on my README: https://github.com/jhvst/nix-config

Back to elaborating on the Nix file from the gaming perspective. First, we have the overlays. These are like patches to the packages, and really useful for gaming because it allows building important packages like mesa from the source tip. This is particularly useful when new games or GPUs are released. Same thing for wayland: Nvidia and its proprietary drivers need some patching, but it's possible to get wayland (and sway) to work this way.

Then, I have taken the reproducibility of Nix to a next step in my opinion, and made the system stateless. This means that it runs from the RAM. It is easy to create installation media like kernel, initrd, and rootfs because you have all the steps to create the distribution. This means that here, Nix works as a meta-distro like Gentoo, on top of which you develop your own. Running from the RAM means that theoretically, if you have a working config, and two people with different hardware runs it, then they should have the same experience. If you look at ProtonDB, you often find that some people claim that game X works on their machine with drivers and mesa of Y and Z, but there is no way to copy their configurations because it's certain that the user has made some stateful changes which they have forgotten hence left undocumented, which is the reason it works for them. If everyone would be using Nix, you could reproduce their system and possibly fix your own, but this is not tractable with most OSs.

If you like to test my changes, you can read more about my approach here: https://github.com/NixOS/nixpkgs/pull/203750

For testing I distribute Nvidia as documented here: https://github.com/jhvst/jhvst.github.io/blob/main/ramdisk.m...

However, I have developed it bit further: if you manage to get into an iPXE shell, you can write `boot -a http://boot.ponkila.com/menu.ipxe`, then select the second option which is Nvidia (proprietary drivers), and with some waiting you will get into a shell prompt to which you can write `sway --unsupported-gpu`, which will launch sway. Cmd+Enter opens a prompt to which you can write `steam`, which will open Steam. Then, you have to mount some drive on another shell with `mount`, and add this as a Steam library via Steam's UI. Then you can play games. I use this on AMD and I have been very happy.

You will need to have a DHCP server which has to be configured with ARM 64 bit file name option to point to the efi/boot/bootaa64.efi in the TFTP server alongside option called UEFI HTTPBoot URL which has to point to the RPI_EFI.d file from the ipxe project builds. Unfortunately, I have no idea how to apply the DHCP settings unless you happen to run pfSense, which has the option under DHCP server settings. If you manage to do this some other way, you can then add a file called autoexec.ipxe to the efi/boot folder. You can generate the autoexec.ipxe file by running the following script, for example: https://github.com/jhvst/nix-config/blob/main/minimal.nix (the command to run it is in the first line of the file).