nix-config VS 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).

> https://github.com/NixOS/nix/pull/9911#issuecomment-19252073...

As we covered in my last post, NixOS is a amazing Linux distribution for creating stable and declared environments. Now while this is amazing for a desktop setup, it is also perfect for a home-server or home-lab.

(Nix itself is slowly chugging along with Windows via MinGW - https://discourse.nixos.org/t/nix-on-windows/1113/108 and https://github.com/NixOS/nix/issues/1320 , for example.)

Nix is a cross-platform package manager. It uses the nix programming language. Nix and NixOs are often used in the same context, but while the first is a package manager, the latter is a linux distribution based on nix.

Today I want to talk to you about Nixos. What is it? Nixos is a declarative and reproducible OS, partly taking the words used on their own page. What does that mean?

Software developers often want to customize:

1. their home environments: for packages (some reach for brew on MacOS) and configurations (dotfiles, and some reach for stow).

2. their development shells: for build dependencies (compilers, SDKs, libraries), tools (LSP, linters, formatters, debuggers), and services (runtime, database). Some reach for devcontainers here.

3. or even their operating systems: for development, for CI, for deployment, or for personal use.

Nix provision all of the above in the same language, with Nixpkgs, NixOS, home-manager, and devShells such as https://devenv.sh/. What's more, Nix is (https://nixos.org/):

- reproducible: what works on your dev machine also works in CI in prod,

- declarative: you version control and review your configurations and infrastructure as code, at a reasonable level of abstraction,

- reliable: all changes are atomic with easy roll back.

Hopping from one distro to another with a different package manager might require some time to adapt. Using a package manager that can be installed on most distro is one way to help you get to work faster. Flatpak is one of them; other alternative are Snap, Nix or Homebrew. Flatpak is a good starter, and if you have a bunch of free time, I suggest trying Nix.

- it reduces bloat, because you can generate an environment or OS image with only the software needed to run a specific program or service

My guess is that a big efficiency gain would come from the second point, because you don't waste CPU on code that you don't use.

Does this make sense? Has anyone explored this?

[0]: https://nixos.org

1) Setting up the development environment - I currently use devcontainers for most things, but may also dig into nix -> isolated, portable, repeatable development environment 2) Exploring Echo - understand routing, requests, response, etc. 3) Incorporate Templ - integration with Echo, template composition, etc. 4) Integrating TailwindCSS - config for use with Echo/Templ, development cycle, deployment, etc. 5) Add in HTMX - endpoints, template structure, concepts, etc. 6) hyperscript for interactivity - client side interactivity

"Your greatest challenge lies ahead -- and downwards..."

Oh, wait a second, my bad, that's the quote on the box cover for Zork I: (

https://upload.wikimedia.org/wikipedia/en/a/ac/Zork_I_box_ar...

https://en.wikipedia.org/wiki/Zork

)

What you really wanted was a link to where you could download Nix/NixOS -- and/or learn more about it!

Here ya go!

https://nixos.org/

"Your greatest challenge lies ahead -- and downwards..."

:-) :-)

I say all of the above in the spirit of humor -- and as a NixOS user and fan!

(But yes, there is a learning curve to it, so yes, learning Nix/NixOS could be a challenge!)

((But you're a bright person, you have Google and ChatGPT to assist you, and you like challenges!))