[tomalaci]

I had quite a rollercoaster going from Windows 10 to Arch to Windows and then settling on NixOS. Main reason being able to do clean package/program setup and centralize, version-control my configuration.

My main issue with Arch was that after installing and trying stuff it left OS dirty even after package removal. This might be because I had some things built and installed through AUR (e.g. latest mpv releases that sometimes broke). Eventually I went back to latest Windows 11 build wanting easy no-bs setup.

Of course, then MS decides to shove down half baked AI integration that somehow used half my RAM and randomly slowed my CPU. I am guessing it was busy indexing, searching or security-scanning something.

Got increasingly annoyed by Microslop and tried NixOS. Bumpy ride initially but after committing for few weeks I am finally settling on it be the last OS I need.

[wrxd]

I also really like that Nix (both on NixOS or as a package manager for Linux/macOS) can temporarily fetch packages with `nix shell` removing entirely the need to install something I am just trying out or something I know I am not going to need on a regular basis.

Similarly the integration of flakes/devshells and direnv is great to create reproducible development environments. Everything I need and at the correct versions are automatically setup as soon as I `cd` into a project directory.

[rrvsh]

https://github.com/nix-community/comma

[synoptik]

Project README.md Install instructions: List of software to install and what those packages are called on different distributions: Just kidding, it just works.

[pmarreck]

> My main issue with Arch was that after installing and trying stuff it left OS dirty even after package removal

Yeah, that's literally a problem with every single OS that is not NixOS (or, shoutout, Guix, or the other Nix-based variants).

That's also why I am sticking with NixOS. Been at least 5 years now- it's wonderful having a reliable LINUX system as my daily driver (or one of them).

And you can reboot into any old configuration! Even more insurance against fuckups!

> I am finally settling on it be the last OS I need

Same here. As soon as I got everything set up just how I like it in a declarative, reproducible fashion, I had this feeling of... "OK, this is great. I can't see a reason to ever leave this."

[CrimsonCape]

Not a Nix user yet, so i'm wondering if you can describe a little more about the "reproducibility" aspect which implies that you are often "reproducing" stuff. What needs reproducing? What is a basic daily-driver use case for whatever we are "reproducing"?

[pmarreck]

The entire system configuration is one file or a small set of files. If you copy it to a different machine, you can "run" it and get pretty much the same machine. If you screw up the config, the system tells you before it even tries to apply it. If something breaks while applying it (which is rare), NOTHING is broken because the entire system still points at the old instance, since cutover is atomic. This is already different from pretty much every other system out there. And if you reboot and things are STILL messed up, you can boot into a previously-known-good instance and repair things from there, without using a bootable USB key.

The builds are deterministic, unlike on any other linux or other OS, because Nix basically captures a closure of all the possible inputs to a build, which means that the build always "sees" the same things, which means it always builds the same way. Once you grok this, doing it any other way will seem insane.

Truth be told I think I only appreciated it more after having used (and bricked) other Linux distros simply by "installing the wrong thing". This is what i mean by "daily driver". You need something reliable AND reconfigurable for that; NixOS (or nix-darwin on Mac) offers both.

[kmarc]

https://github.com/CyberShadow/aconfmgr

Aconfmgr is a good solution (practical trade-off for me). When it feel like "my OS must be dirty at this point", then I spend a couple minutes with this and I'm back to the clean state.

I don't do this more then twice a year, so if you insist on an always clean system, YMMV

[spacington]

I'm borderline motivated putting Ubuntu onto my parents computers.

Win11 was frustrating ...

[beastman82]

Chrome OS Flex has worked out nicely for my mother-in-law's potato

[shevy-java]

> installed through AUR (e.g. latest mpv releases that sometimes broke)

On my home system I'd do this to switch to a new mpv release:

"gitty mpv"

(This is my alias to check out the latest mpv sources, from github, via git clone URL_HERE.)

Scripts repackage mpv into .tar.xz after this git clone step.

Then I do:

"clangy mpv"

clangy is my alias to compile via clang from llvm; and the specific instructions would be found in my COOKBOOKS_DIRECTORY aka recipes (similar to homebrew, but in .yml files), where all information is gathered from mpv.yml then.

One setting there is:

   prefix: f

This means "non-traditional prefix", aka "AppDir" prefix. AppDir prefix is how GoboLinux installs software, e. g. in /Programs/Mpv/22.06.2026/ (I keep the dd.mm.yyyy notation, but this can be toggled; on my home system I use /home/Programs/ though rather than /Programs/ for historic reasons, and also as I want to backup my /home/ directory, including all programs).

So the above would, via clang, compile mpv from source (if the git clone worked), into the AppDir prefix. Then it would simply create symlinks and so some more processing, so /usr/bin/mpv would point at /home/Programs/Mpv/Current/bin/mpv, and Current is a Symlink to the current version in use. I can keep old entries of mpv under /home/Programs/Mpv/ so switching is trivial. And cleaning up is also trivial, I remove e. g. an old mpv version there, then call one post-removal script (or I simply pass the name of it, but I find it easier to work via the commandline in two steps here). The benefit of the above is that, for instance compared to your "latest mpv release sometimes broke", this would not affect me, the old mpv versions would work still, and there can not be any outside installation other than the versioned AppDir.

Right now my /home/Programs/ has 499 entries. I'll eventually have all programs there, and work, then I'll switch to a completely custom LFS/BLFS. Right now my base system is manjaro, which works very well as a base system, even though it uses systemd. /lib/ is a symlink on manjaro by default towards /usr/lib/ and so forth. I find this works so much better than e. g. debian.

> Got increasingly annoyed by Microslop and tried NixOS. Bumpy ride initially but after committing for few weeks I am finally settling on it be the last OS I need.

Not disagreeing at all, but imo the issue you had with AUR is one that by design could be completely avoided. I am not saying this is your fault, mind you; just pointing out that this may be an assumption by both AUR as well as you, since your expectation is to trust the package manager. Here, my input would be the question whether a package manager would be necessary in the first place or not (I still have scripts to handle that, mind you, but the assumptions made via AUR may be wrong in many areas, including not offering versioned AppDirs by default. I don't understand why all package managers do not offer versioned AppDirs; it would solve so many issues).

I should add that some programs are harder to install from source, but mpv works very well; ffmpeg too, surprisingly enough. LLVM/clang is a bit harder to setup, and by far the worst offender is firefox. Mozilla should be ashamed of mozconfig for life.

[paisawalla]

God bless Hacker News, where "just start building your own package management system, like I did" is an earnest comment, including a sketched out implementation.

(I'm admiring this, not mocking it)

[rrvsh]

You might be interested to note that what you have written is basically the same paradigm that Nix uses, except with a content addressable store in /nix that the binaries are compiled from source to. All packages (read: binaries, libraries, configuration files) are symlinked from the store to wherever they are needed e.g. PATH, another package's environment, etc.