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.
In the US, insurance companies and Pharmacy Benefit Managers (PBMs)[0] are the biggest threat to smaller, independent pharmacies. Even if your neighborhood has a Mom and Pop pharmacy (a rarity, as you suggest), if most insurance providers do not provide coverage for that pharmacy I doubt many folks will go there. Instead they would go further across town or use online services - driving independent pharmacies out of business.
On the side of the PBMs influence, the consumer might not see a difference in the price in order for the indie pharmacy to stay competitive, but the cost of medicine for indie pharmacy can be much higher than the corporate pharmacy - meaning they make no money on a sale and in some cases actually lose money. (I recently learned that in some cases, specifically with GoodRx, indie pharmacies can be forced to pay the PBM when a customer uses a PBM discount card at their pharmacy - so the consumer pays the PBM and the pharmacy pays the PBM)
Large corporate pharmacies have the strength and power to influence insurance providers and PBMs - and some even control them. That in my mind is the bigger issue in the US.
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??
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.
I gave LFS a go earlier this year. I learned a lot through the process - but I definitely went outside the guardrails. I use NixOS as my daily driver and found myself curious of whether I could complete LFS using a "Nix" approach. I was only a basic Nix user at that time and that choice made a difficult process much more difficult. However, the declarative nature of Nix meant that I had clear notes of every step of my process - and if something didn't work, I could backtrack and troubleshoot to find the root of the cause. The end result is here [0].
My understanding of Linux, of bootstrapping, cross-compilation, and Nix has grown tremendously as a result of the time I took on this project - and I still go back and reference the work from time to time. When I get some time to revisit the Nix-based LFS project, there are quite a few things I would like to clean-up, including setting kernel configs and handling post-build permissions.
Nix-complexities aside, I highly recommend LFS if you like to understand how things work and don't mind a little suffering along the way.
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.