I would separate NixOS from other immutable distros. NixOS is really about giving you blank slate and letting you fully configure it.

You do that configuration using a static config language that is able to be far more idempotent than Andible. It’s also able to define packages that are well contained and don’t require dynamic linking setup by manually installing other packages.

Immutable distros, on the other hand, really have no advantage to your setup and will probably feel more restrictive. The main use I see for them is for someone new or lazy that wants to get a working system up and running quickly.

My first guess would be emulation for apps that do not run on aarm by default.

A lot of OSS devs don’t want to spend time supporting a closed architecture. Especially some of the more privacy and openness focused apps that you’re running.

My favorite example of how idempotent NixOS is has to do with the DE. If you've ever looked at switching from gnome to KDE, or the other way around, most distros suggest to just re-install because each DE leaves so much cruft around and it's so hard to remove everything in a safe manner.

With NixOS, you just change one line in your config, and the DE is cleanly swapped.

I wasn't trying to go into typing as much as using structs or objects when working with known data attributes. Sorry that it was a bit misleading.

The original actually went into using trees, sets, heaps, tries, etc., but it felt way too... ranty. After writing all that out, I realized that most of those other cases come up really infrequently, and that my biggest gripe was about not using structs or other pre-defined key container types. I thought it would be better to keep things short and focused.

Maybe I should re-write and publish a data structures edition.

I love the addition of dataclass. Makes refactoring such a breeze. If you need to extract some function, boom, you already have a class that you’re using everywhere.

I’ve worked on dev tooling in a fairly large company. Especially for cyber security, do not get a Mac. A lot of the tools are just different enough on a Mac that they will make your life much harder.

That's a super interesting idea. I will have to give that a shot!

Right now I just use flatpak for all my gaming needs and shared things like browsers, slack, etc.

I’ve used pine64 boards for this. They have a few more options and are always available.

I would say it’s actually easier in many cases. Nix has really fantastic packaging tooling. You do have to learn a bit of the nix language, however (not become an expert).

The issue comes when trying to build from source. In most other distros, ou just follow the readme. In nix, you have to package it.

Yeah that's totally fair. It's definitely far from perfect. Although, I do like that it provides at least some level of isolation.

Yes! That would be the best. We should have access to our hardware. And just like most things you want to keep around for a long time (e.g. cars) you will have to tinker with it to keep it running smoothly into old age.

Seriously though, I recently posted an article there and literally half the replies were obvious ChatGPT bots summarizing the article.

You could also run Gentoo on it. Quite a few people are running it successfully: https://wiki.gentoo.org/wiki/User:Jared/Gentoo_On_An_M1_Mac

Alacritty is also the terminal that feels small and focused enough for me. Too many other terminals try to do everything like session management, etc.

I use it to share environments with a small team. Just have distrobox specific Docker files and we can all spin up the same distrobox environment locally.

We end up having a different base docker file (e.g. our distrobox one has editors and stuff), but we all share the same project specific docker file. That same project specific file gets used in CI/CD and deployment, but with a minimal base. So all in all, I would say it's even better than Vagrant because we run the same system in production.

Yeah it does. I actually use nix as my base OS on one machine. But when I need to work on a project that will never be packaged with nix, and I need all the dependencies, it really becomes impossible to just use nix.

Nix makes an amazing bas OS, however.

Already has that. And if you use flakes, you can fully lock down your package versions that way the install is 100% identical on every machine no matter when you run it.

No, I fully understand it. But if you build the whole system where every package is isolated, none of the packages interfere with each other, and every package is tested across a wide array of architectures, you can just as safely put together your ideal OS setup and don't have to deal with being locked into very simple and bare system.

The right place for immutable OSes is if you're using it as a server for container workloads, where you will never customize the base system. Or if you never want to customize your system. Yes, you can customize the system image, but it breaks all the guarantees that the images gives you because the packages themselves are not isolated and by bumping a wrong dependency for a custom packages you can still break the whole system.

Definitely. That's a great way to run different option together.

I was just using the DE as an example to demonstrate how cleanly NixOS can add and remove packages. The clean removal of packages with lots of configs is something that most distros struggle with.

Your summary of the language is spot on. I still hope that more distros take inspiration from the declarative config and try to move in the direction, or nix supports a better language in the future. I think that ultimately that's what the average linux user would want. The ability to still customize in a safe manner. Silverblue, and others, are and will remain a great option for the new or indifferent user.

On your point about the transient phase, nix actually does that by default already. It installs everything at a separate path and then flips over in one go. You can even pick the mode, either try to do a live switch as you describe, or on boot. I don't know if I see many benefits to images there.

I am at a second place now that uses NixOS in a corporate setting, and it is much easier than maintaining the CoreOS images, or similar. I've had some many broken builds of CoreOS images because something goes wrong between the custom packages and the base CoreOS images, I would rather just run an Ansible script at this point. Also, you end up using the exact same test suite for NixOS images as for your other images, so the same guarantees end up being met.