nix-config VS silverblue-nix

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).

On silverblue, you just follow this guide and it uses a systemd service that uses the command chattr to make / immutable (temporary) but not the reclusive directories (that means only / not the contents inside the directories) by doing chattr -i / creates /nix and /var/lib/nix mkdir /nix mkdir /var/lib/nix then it bind mounts it mount --bind /var/lib/nix /nix then it uses chattr again to make / immutable again chattr +i / . The problem with microos is that the chattr command can't change atributes on the / directory. But is there like a way to have a /nix subvolume like how there is writable /var and /home subvolumes? Like how can you make it not part of the immutable part. you can go into the transactional update shell and type mkdir /nix and /nix is there but is not writable. Is there a way to make a subvolume and mount it as /nix and have it readable and writable?

agreed with that I only install drivers, distrobox, and qemu/virt manager on the immutable part and everything else is done with either flatpak, containers, or nix (it works on silverblue quite well. there is a guide for it)

fedora silverblue is good if you want a reliable system. you can also get traditional package management by using containers from distrobox or toolbox or you can use nix on silverblue

I find it quite useful for silverblue. I can install packages user wide or system wide without the need to layer packages. It gives me a mutable eviroment while keeping the core system safe. Proot isn't available for fedora but it is available with nix so I can have proot system wide with nix which is not possible with podman. Applications with nix start way faster than starting a podman container. It is quite useful. only downside is that you need to set SELinux to permissive (which really isn't an issue for me) there is a guide for installing nix on silverblue too.

Installing nix, you would have to disable selinux and if you use silverblue, you have to do these extra steps. it would be nice if all you got to do is type sudo dnf install nix (or sudo rpm-ostree install nix if you are on silverblue) and it would automaticly add selinux policies and automaticly have the .desktop files in ~/.nix-profile/share/applications or ~/nix/var/nix/profiles/default/share/applications for system wide automaticly show up in the DE launcher and also have sudo work with nix better. it should also work for workstation and silverblue too.

maybe install it on toolbox, distrobox, or even nix if you want to install something that isn't a flatpak. nix is good for installing other terminals, shells, and fetch programs so I don't need to layer. it also supports user wide and system wide packages. only downside is that you need to disable selinux.

you should give nix on silverbluea try

here is a guide to install it on silverblue https://gitlab.com/ahayzen/silverblue-nix

the nice thing is you can install nix package manager on other distros. it is very useful to use different shells and using neofetch without layering on silverblue. there is a guide for it

Never mind traditional package managers... you plug it in right, you can run Nix on Silverblue!

https://gitlab.com/ahayzen/silverblue-nix

NixOS people will prefer NixOS, but Silverblue seems like a nice complement to Nix if you need an FHS base system and want to retain some Nix-ish features like rollbacks and atomic upgrades.