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

Thank you for the articulation of the issue and your experience dealing with it. Were you aware of the articulated issue (the absence of collaboration) while you were there? Or did it only become clear in retrospect? I imagine in an environment like this it would be easy to get lost in the feeling of being undervalued and disrespected, without being clear of the source/cause of that feeling (unhealthy organizational culture).

Thanks for sharing. He makes the material very interesting and very accessible. I've fallen into another HN rabbithole..

Fortunately, I maintained a similar passing grade in maths/reading comprehension...

> officials found that the department couldn’t account for about 61 percent of its assets.

> McCord said the department has made progress toward a “clean” audit in the past year, but later added “we failed to get an ‘A.’...I would not say that we flunked.

Good to know that by US government standards, a 61% is an acceptable passing grade...

> They are testing the world.

I like this a lot. That is so true. Personal anecdote:

When I got my first car as a teenager (a cheap, used, beat-up sedan), I would often take it out to 'play', ehm, 'test the world'. I lived in a rural area and would drive random, remote backroads for hours with no maps (and no cell phones at the time). I would try to see if I could get lost. I never succeeded. I was always able to eventually find my way, while I was simultaneously building spatial awareness and a general sense of direction that accompanies me to this day. The winter time gave me the best 'testing' environment. I would drive these backroads when they were icey and very slick. When I had certainty there was no traffic anywhere near, I would see how I handled my car when I lost control. A few rotations later, after spinning uncontrollably, I was able to regain steering and was able to navigate out of the problem.

Risky? Sure. Useful skills? Yes. Would my parents have stressed out knowing what I was doing, definitely. I'd like to think I'm a much better driver today because of it and have gotten myself out of some potentially consequential accidents because of my awareness of how a vehicle handles when out of control.

Many people learn from doing - many kids especially. Being raised in proverbial padded rooms may mask very beneficial learning that corresponds to the real consequences of life that we will inevitably face in adulthood. There will always be risk by letting our kids loose a bit more, and thats probably the scariest of things for many parents..

I agree. I would also position that for some, it may be less a case of 'attention deficit' and more 'attention prudent'. There is way too much garbage content out there and information overload can easily lead to processing overload. Not speaking to the very real medical conditions out there but to societal generalizations - I place a very high personal value on my time and have little tolerance for wasting it on content I feel is uninspired and/or lacking depth or any sense of meaning to me.

Then there is the issue of there being a high quantity of such damn good quality content out there (curses, HN). In that case, its just too much to ingest while working to maintain other forms of focus in life.

Interesting to see both the Minnesota House of Representatives and State Senate using the ccTLD of Mongolia.

[0] https://www.house.mn

[1] https://www.senate.mn

The source for the article is the Climate Change Institute at University of Maine [0].

The Institute's Climate Reanalyzer also has some visual data of historical daily sea surface temps that is referenced quite a bit these days.

Data only stretches back to the late 70s/early 80s, but many of the hottest trending years are within the last decade.

[0] https://climatereanalyzer.org/clim/t2_daily/

[1] https://climatereanalyzer.org/clim/sst_daily/

I'm a big fan of QuantAQ. Speaking from a PM10 perspective, your monitors perform on-par with high-cost regulatory monitors in a much smaller package and far lower cost. I also love the open API. That said, I would love to see a locally-hosted variety for environments where LTE/cloud is not accessible/preferred.

Thank you for sharing more about AirGradient and its origins. I appreciate the impact-driven mission. I will checkout the details of your co-location program and may have a few sites that would be a good fit.