I believe you. Do you believe me?

> At that point, NixOS just clicked and I'm far more productive with 30+ hosts than I used to be with 1-2.

There’s not much room for improvement in my own productivity here. The amount of time I spend maintaining these hosts is not large to begin with.

> This sounds like you're branching into territory that can no longer be reasonably framed as NixOS vs. Debian (or other distro of choice).

I was never talking about NixOS in the first place!

“Rebuild everything in one command and have it work” is not something that I’m chasing after and I am skeptical that it would work anyway. Maybe there is something I’m missing, but when I update the software, the updates come with changes and it’s possible that things break. My goals are to keep reasonably up to date and to be able to fix things quickly if they do break.

Regarding Nix complaints:

Package maintenance is kind of a crapshoot. Maybe your package is in nixpkgs, maybe there is a flake for it, maybe you find something that is actively updated, maybe not. Maybe there is a package but half the features are turned off because the maintainer didn’t bother. Maybe there is a package but half the features are turned off on macOS for unknown reasons. What I want is just to know what level of distro-level maintenance the package has, including its transitive dependencies.

Docs are just kinda bad. Fragmented across different sites. Docs teaching you Nix forwards or backwards, or teaching old Nix, or teaching Nix with flakes, or teaching you Nix for end-users or developers or package maintainers, or Nix on Mac or NixOS. A surprising number of broken links. What I want is one site, with a little drop-down menu to select the version I am using. What I have is hours spent on the NixOS Discord trying to figure out how to do basic stuff.

There could be similar issues with NSS but I think more people are ready to bypass NSS altogether.

Meanwhile, my company is using Nix for everything heavily internally. Everyone gets their dependencies via Nix unless you are like using PAM or something.

Reminds me of Bazel, in the way that it gets adopted by companies with developer support teams (because it solves real problems) but feels frustrating for us ordinary folk. Nixpkgs is kind of a critical part of “ordinary folk” and with the core team disbanding, I feel like my personal moves away from Nix (for projects) are proving correct.

After reading these articles go by so often, it feels like what I actually can’t keep up with is the bond market. To paraphrase Trotsky, you may not be interested in the bond market, but the bond market is interested in you. I want to be able to read the signals at the bottom of this article, and divine some kind of prediction that can guide me… I don’t know, to choose whether I should buy a house or change the investment strategy in my retirement fund or something. But I’m just seeing all these signals go by, waiting for the story to be written, which only happens when the dust settles.

I guess I’ll go back to not understanding AI, instead of not understanding the bond market.

Yes, it’s hard to predict markets. Because anybody who can successfully predict markets, does so, makes money, and changes the market so their predictions lose their edge.

Time series forecasts are a lot easier if you are forecasting, say, disk use in your servers or whatnot. (By “easy” I mean you can do a simple prediction and get useful insights.)

So I would say that any easy answer like “this would not compile” would just be a guess, because you would want to know more of the particulars in order to answer this question.

I know that this is kind of a non-answer, but if you want to write a kernel in Rust you have to figure out boundaries for where unsafe {} are. In a kernel, there are probably large chunks of unsafe {} and the Rust compiler prevents certain bugs outside unsafe {} assuming there aren’t bugs inside unsafe {} that would prevent the type checker from doing its job correctly.