cloudripper

I agree.

Also, this is the kind of crystal clear thinking and analysis that we need more of (and why I come to HN). Thank you for cutting though the BS and highlighting the underlying lessons.

Nix is a language, package manager, and OS. This post discusses NixOS.

While docker-compose allows you to compose your containers with a yaml/Dockerfiles, NixOS allows you to compose the system that all of your containers run on (from userspace down to kernel selection/configs, file system, etc), as well as your containers - all in a declarative .nix file. That .nix file can be used to spin up any number of identitically configured systems.

It's also reproducible, in that you can specify the sources (refined to a specific commit if you prefer) for any and all packages on the system - and build them with Nix within a sandboxed environment protecting dependencies and env configurations (Nix is also a powerful build system).

Given the extensive infrastructure you and others are building around flakes in the Nix ecosystem, despite flakes still being experimental, what does the roadmap look like for your efforts, and more broadly for officially establishing flakes??

There's a couple reasons for that.

First, for my initial attempt at the project I wanted to make as close of an adaptation from LFS guidance to Nix that I could. While I did sprinkle in some custom kernel configurations (from BLFS guidance), I otherwise tried to make a direct adaption from the book. The LFS guidance for the kernel build uses `make menuconfig`. That requires user interaction which, as far as I am aware, is not feasible in a Nix derivation (and really wouldn't make sense to achieve reproducibility as far as I understand the term). So I used `make defconfig` within the derivation and attempted to sed the kernel .config to achieve a matching config to that of LFS guidance (coupled with a few sprinkles of custom configs). In retrospect, I don't like how that block currently flows and would like to make it a bit cleaner and easier to declare configuration preferences.

Second, my approach with the entire project was to limit external inputs to the derivations with the goal of trying to be as reproducible as I could. If I recall correctly, the only external inputs used in the whole project were the sources and patches provided by the LFS project. That said, I hadn't considered that it might be a lot simpler to set it up in a "Bring Your Own Config" kind of way. I will stew on that more and would definitely be open to more thoughts on either and/or another approach.

Fair questions. If the question is "why did I need to chmod those files", the answer is that permissions modifications in the mkderivation build environment are not propagated to the build output. The quick and dirty solution I came up with was to make a chmod wrapper that logged the calls so that I could apply them after the entire build completed.

For why I did not chmod the directories - that is something I should probably do when I get time again (cleaning up permissions handling more broadly). In my case at the time, I had the logs from the wrappers and did a quick filter before directly adding them to the script as a last hurdle to having a bootable machine after a month-long grind.

The kernel config handling needs a good amount of attention too. I have a cleaner approach to that in mind that I haven't had the opportunity to work on.

It will likely be December before I am able to invest much more time into it, but definitely open to any input generally.

Thanks for the input. A couple of folks suggested that recently as well. Once I can clear up some bandwidth, I do intend to follow through on that. It gave me a huge appreciation for Nix as a build system, and I would love to share that if it were helpful to others.