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.

Edit: include note on PBMs

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.

0: https://www.reuters.com/legal/litigation/goodrx-pbms-accused...

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

https://nixos-and-flakes.thiscute.world/ is also an excellent resource.

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.

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.

[0]: https://github.com/cloudripper/NixLFS

I thought it was intended as more of a pun on questionable displays of human intelligence.

In California, you can get a license plate with your call sign. That's kind of cool, right? Maybe moreso if you have a punny vanity call sign.

As an experienced, very poor climber myself, I enjoy the process of problem solving. However, knowing many experienced, very good climbers - studying beta is how many of them excel. As an aside, the term beta also came from the use of beta tapes by climbers to record themselves climbing so they could study the minutiae of their movement to find improvements. In higher levels of bouldering especially, a nuanced and firm understanding of beta is everything - so careful analysis of your movement can help identify areas of improvement.

I believe this is consistent with most elite (or elite-aspiring) athletes from many sports.

While I personally enjoy the problem-solving aspect of climbing (when I rarely do get out), I absolutely see the value in this project (and other climbing apps that thrive on beta sharing)

Porkbun is a clean option.

I recently fell into the Linux from Scratch rabbithole. The extra unexpected fun came while attempting to build LFS from within NixOS (my daily driver, which I only had a basic proficiency in). I quickly realized the challenges of following the LFS project's guidance, due in large part to how the Nix store is implemented. So I fell down another rabbithole of learning derivations and the Nix language - which took me a good way though building the LFS toolchain within Nix's intended sandbox. However, achieving FHS-compliance became another issue as I attempted to build essential LFS system tools within a chroot-like environment, but sought to do so in roughly the same declarative/reproducible manner as Nix's ideal. After a few lost hairs, I discovered the wonders of Nix's FHS build environment/bubblewrap implementation. A few hoop-jumps later, handling permissions and migrating to the final build partition, the project was complete with a mostly declarative, mostly reproducible, functional, minimal, bootable LFS build.

What sticks with me most through this experience is the brilliance of the open-source community (and a special satisfaction with now being able to say "I use nix btw")

I appreciate stories like this as a reminder that it is never too late to make a change in your life that is right for you. Some folks stick to their comforts and avoid such a big life change out of fear - but somethings the temporary discomfort can lead to greater fulfillment in the long-run.

Whether your coming from or going to lorry driving - or any other job role, keep telling your story and maybe your path will be an inspiration for someone going through their own jaded, burn-out experience.

Not sure if this applies to your situation, but I believe you can avoid a full rebuild by modularizing the flake.nix derivations into stages (calling a separate *.nix for each stage in my case). That is how it appears to be working for me on a project (I am building a cc toolchain without pkgscross).

I pass the output of each stage of a toolchain as a dependency to the next stage. By chaining the stages, changes made to a single stage only require a rebuild of each succeeding stage. The final stage is the default of the flake, so you can easy get the complete package.

In addition, I can debug along the toolchain by entering a single stage env with nix develop <stage>

Not sure if this is the most optimal way, but it appears to work in modularizing the rebuild.(using 23.11)

I use nix btw.

I totally agree. It (nix and nixos) is/are such a pain so often. But, wow... when you get things to work it is glorious.

Quickly and easily syncing system/user/application configurations across multiple devices is incredible. The declarative approach means that the often laborious effort it takes me to get things to work pays off when I finally figure it out and realize I never have to do that again - and since it's declarative, I now have a documented functional configuration/example to grow and expand from.

My current project is to learn Nix development environments by building "Linux from Scatch" from Nix. I am making progress slowly, but every success is cemented and replicatable.

LLMs definitely help distill the sparse/scattered documentation, but I am finding a good amount of grit is still required.

All in all, I am very much enjoying Nix and hope to utilize it more in my homelab.

I think the community building component is the most interesting here. How do projects rally the contributors necessary to take a complex, long-term, poorly documented project to the next level - versus them being turned away by the dire state of non-code things (looking at you NixOS)?

The positive side to tracking and a cell layer anecdote - cell layer forensics are often utilized in search and rescue contexts. I have seen this data accessed (through legal procedure in the US) and utilized to save lives of the missing and to provide closure to the families/friends of the missing.

Impedance mismatch and attenuation. The impedance difference between air and the piezoelectric elements of the transducer is too great - this will cause soundwaves to reflect on contact (and thus never leave the element). If some transducer innovation changed that variable, then attenuation would be the next hurdle.

In general a form of couplant (water, oil, some form of gel, etc) is necessary to eliminate air between the transducer and a material in order for soundwaves to pass.