I liked Nix, because it worked very well to reproduce "the same system" every time. However, it became unmanageable and a huge time sink to constantly remake how I scripted together my nix flakes per the current/modern way of doing that. And then finding a repository of how someone else managed this on Github and rewriting my configuration again.

Nix ultimately made me feel like I was running Gentoo. Excellent build system, but I could not invest the time in learning ebuilds, and I could not invest the time in using Nix's language to manage its packages. It was just a huge time sink and baggage to maintain.

rpm-ostree is lowering the barrier to entry greatly to produce layered [open container] images that we can rebase off of. That is the future among all this atomic stuff. It would be entirely possible to /someday/ build a system with the nix toolset, then commit the image through rpm-ostree, and have others rebase from it. Best of both.

In the future, with immutable systems, it probably also means being able to have those very robust update systems in place like Chromebooks where you update and switch to partition B with the new image, while having the fallback on partition A. It would also probably make it easier to verify and sign these images for secure boot purposes so then enabling secure boot on Linux becomes easier/convenient, and the secure default.

I still think the Nix language is yet another language I don't see the value in. I'm not learning this, or becoming comfortable in this language, or convincing myself it's a comfortable language to use ...just to maintain my 2-3 laptops when I don't use Nix anywhere else.

Time sink. But a very solid system.

PS: I want them to layer everything on Fedora CoreOS. Make CoreOS the secure thin base, then create all these atomic "Spins" as a derivation of CoreOS.

I have also invested a hugely disproportionate amount of time in writing my Nix config. However, that is only because I found it fun to massively over-engineer everything and wanted to make my work easily usable for others.

That said, I could have gotten away with significantly less and I'm really not sure what you're referring to with having to remake your Flake. I'm not aware that the output schema changed over the last years. Could you provide an example of what caused you to rewrite your configuration?

I'm not doubting your experience, the documentation situation is not great and I could absolutely see someone getting stuck in a situation where they felt they needed to start over. I'd just like to know what the community could do to avoid these pitfalls.

I never got around to the flakes thing - if something isn't already in the repos nowadays, I lose interest quite quickly. It's really helped with just getting on with life instead of futzing around with settings. What does work, is rock solid.

I'm using nixos and I never really needed to "learn the language". I used the installer, which gave me sensible defaults, and now I just dump more and more stuff to my configuration.nix as I need it.

Their website contains plenty of examples to copy/paste and since the distro is already prett old, chatgpt can easily help too.

Ok so perhaps my config isn't the prettiest but who cares. It works and it's a record of what my system is.

I am also a nixos enjoyer but I have mixed feelings around the fact that I still don't really understand the configuration language.

I'm happy in the sense that its simple enough that I can install programs and do all the other usual desktop stuff with minimal knowledge. But I'm unhappy in the sense that when I started with nixos I wanted to replace docker and docker-compose. I still haven't accomplished that.

But all-in-all I'm very happy with Nixos for desktop use. No crashes, no bugs. Its the reason I was able to permanently drop Windows.

I know they're kind of experimental still, but I have personally found Nix Flakes a lot more fun to work with, at least once I sat down and actually learned about them. I feel the interface is more consistent, and it gives me the "replacing docker" experience with the ability to make devshells and ephemeral builds.

Granted, I'm not running Nixos on my main laptop, because I have had a hell of a time getting me 2020 Macbook to get Linux running stably, but I do use Nix as my sole package manager within MacOS, and I do run NixOS on my server and use Flakes heavily there.

I went down the rabbit hole and now feel comfortable claiming I do understand both the programming language and the NixOS module system, which is effectively an embedded DSL, as well as a decent chunk of the nixpkgs conventions.

And it certainly is a great feeling, but I'm not yet sure it's really "worth it". Of course the effect is great, but it was also an enormous amount of work to get there.

Generally speaking, you should never learn a language. You should use a language and let learning happen.

And every time your libc needs to be updated, almost every other package you have installed must be updated at the same time.

And if there's the slightest issue with the update, you can just reboot into the previous generation and continue working until you have time to figure it out later, or just wait until it's fixed!

Fedora atomic desktops have that property, too, without the wasteful property I just described.

Yes, there is a garbage collector to get rid of the old stuff you don't need anymore!

The existence of the garbage collector does not negate the wastefulness of updating every package on the system just because the hash of the C library has changed: even if all the old versions of the packages get garbage collected soon enough, it still wastes network and storage bandwidth to download all the new packages into /nix/store/.

NixOS has some good ideas, but also some seemingly boneheaded or impractical ones.

This is what allows you to have multiple versions of something and all its dependencies installed and not conflict with each other!

No it is not. That is my whole point: NixOS could have one without the other.

Consider modifying NixOS to remove the requirement that the long hex id in the name of a package in /nix/store/ is a cryptographic hash of (among other things) the hashes of every package the package depends on (thereby eliminating the need to upgrade every package on the system every time the libc packages is updated). I am pretty sure you can do that while retaining the property that it is easy to have multiple versions of something installed that don't conflict with each other. I have not actually done that (I have not actually modified NixOS in that way, then tested the result, e.g., by making it my daily driver for a while) which is why I'm using qualifiers like "I am pretty sure", but I'm confident enough it can be done that I consider it worth bringing up in online conversations about NixOS. The cryptographic hash gives you a guarantee that a binary package you got from the NixOS package servers has not been adulterated in some way on its way to you--a guarantee that you can check without your having to go through the trouble of building the package yourself, but IIUC that guarantee is not actually used anywhere to make the supply chain any more secure.

In general NixOS seems to be bad at security or not to care about security: for example https://news.ycombinator.com/item?id=36268776

Again there are good ideas in NixOS (including ideas that seem like they could be used to meaningfully increase security) and I hope anyone creating a new distro studies NixOS, but as a distro to be actually used in anger in the present day I am not impressed.

These look like great ideas, I look forward to trying out your branch! It's pretty easy with Nix, I'd just have to NIX_PATH=<path>/to/nixpkgs-hollerith/ nix-shell -p <some package> to try it out. Good luck!

You probably don't even need to reboot. Only once have I broken a generation badly enough I actually needed to reboot. And that was entirely my fault: I mis-configured PAM and couldn't sudo anymore to switch back.

I don't think it does hot patching the kernel?