The Arch wiki is pretty distro-agnostic (barring package names and pacman specific stuff). I’ve been distro-hopping for past decade and I’ve always used it as a reference for setting things up.

Yeah true, whenever I have problems with some packages like Wayland and its alternative Xorg tools or games, its Arch wiki that helps extremely to fix or understand the situation. Its like many experiences are combined and written in a simple language everyone can easily understand.

On Ubuntu for example, everything feels like its hardcoded, not the standard and its just not even documented. And the wiki has minimal info about the packages.

Fully agreed- I experimented with it around November of last year and absolutely love the idea of it, but the documentation just isn’t there. At the time I found nothing explaining flakes in a clear and concise manner so I had no idea how to use them or add them into my configs. People online kept saying to port the rest of my configuration to flakes but all of the examples online were complex and there was no simple example to build off of. I ended up settling for Universal Blue since it just uses OCI containers and I don’t need a PhD to have a pseudo-declarative environment in it, but would love to revisit NixOS if the documentation ever gets better.

Yeah if your knew to nix its even hard to figure out how to install a simple package.

I think NixOS needs an approachable installer or config builder

The Nix package manager got ported to OpenBSD, so that part of NixOS must be excellent.

NixOS needs what is IMO the killer feature of Arch: the wiki.

NixOS has a killer feature which obviates a wiki for most such purposes: NixOS options. They document themselves!

You don’t need to look up a wiki on how to install and enable i.e. paperless and all the other services it depends on, you simply set services.paperless.enable and NixOS configures everything for you internally.

The option tells you roughly what it does internally and the other options provide pointers for things you might want to tweak about it. The services.paperless.extraConfig option for example tells you how to configure it (pointing to upstream documentation in this case) and even gives an example on what you might want to do.

Another example is how to install Steam. In Arch, the wiki must tell you all the manual steps required to enable multilib, install the steam package, install 32bit dependencies, yada yada.

In NixOS, you simply set programs.steam.enable = true;. Off to your games.
You wanna customise the Steam package to add additional flags, pass env vars or add additional packages your weird Linux-native indie game needs? programs.steam.package tells you how to do that right in the place where you do it.
While you’re looking for steam, you might also come across hardware.steam-hardware.enable which you need to set in order to make your Valve Index and Steam Controller work properly.
You wanna start Steam in a gamescope session right from the display-manager? programs.steam.gamescopeSession does it for you. No need to copy paste some snippet that you’ll instantly forget about and maybe breaks in a few months. programs.steam.gamescopeSession is maintained upstream by NixOS, so if it breaks, someone will go and fix that and nobody needs to adjust any of their copy-pasta because they’ll just update as they always do and it just starts working again.

None of this is perfect yet and the quality of documentation of NixOS options really varies but I think you get the idea here. I already rarely look at the NixOS wiki to configure my system because the system configuration tells me what I need to do already and this will only get better as options get refined.

the promise of being every bit as hackable as Arch

I don’t think it makes that promise and I don’t think it’s true.

NixOS is about doing things “properly”; applying software engineering to software environment management.

Whipping up a quick hack is much more complicated and time intensive on NixOS than doing so on Arch because it’s way more abstract. You can’t just quickly replace some binary with your own compiled one, you need to use NixOS’ systems to wire in the binary and build it with Nix to begin with.

Maintaining a system (even one with terrible hacks) is much simpler in NixOS however.

These are pretty good points.

The fake excitement sounds like a YouTube influencer acting, but maybe it’s AI. Either way it’s crap.

Not sure, but either way the article is crap.

I use Arch btw.

That’s the main crux with NixOS, it does a lot of stuff in the background for you that in my opinion you should know why it’s being done the way it is. As such I consider Arch a good distro for a beginner who wants to learn the inner workings of Linux, while NixOS is a better-engineered distribution that takes care of the system for you. Arch’s goal is to be simple for the maintainers which means it’s very close to what one might consider a “standard Linux”, and its wiki is mostly a documentation of exactly that.

😄 🤣 😂

I use a reproducible, declarative and reliable system btw.

I also use flakes btw.

this distribution allows you to have multiple versions of the same library to work with different programs at the same time, correct?

That is correct. You can even have programs from entirely different releases running on the same system without conflicting with another; one with i.e. glibc 3.34 and one with 3.37 for example. Or even wilder setups with some packages using musl, other glibc and others yet being built statically.

Does this mean that each program downloads all its dependencies independently?

Each program references all of its (exact) dependencies. Nix then looks at the program and its references and builds a tree of dependencies.
Then it tries to “realise” these dependencies (make them, well, real), possibly by substituting (downloading) them from a binary cache or automatically building them on your machine if they’re not available in any configured cache.

However, if some package with the same exact version already exists in the Nix store, no action will be taken. Why should it, it’s already there.
For example, if you were in an empty world and built an environment with hello and coreutils in it, they’d both depend on glibc. If both came from the same revision of Nixpkgs, chances are that they depend on the exact same version of glibc.
What Nix would do here is fetch 1x glibc, 1x hello and 1x coreutils.

Note however that you don’t need to manage any of this. You just say “I want hello and coreutils”. Nix takes care of getting the correct dependencies in place but they won’t be in your immediate environment. When you then say that your environment should no longer contain hello, it does that. At this point hello will still exist in the Nix store but it won’t be in your PATH any longer, so it’s not polluting any shared state; it just sits there on disk and the worst it could do is waste disk space. It’s not “installed” in the same sense as what it’d mean to have an unused dependencies installed on an FHS system.
In order to reclaim disk space from unused Nix store paths, you can simply run a garbage collection. You don’t need to care about that one specific hello store path here though, you just say “remove all unused store paths for me, thanks” and Nix removes it along with all other unnecessary paths. In NixOS, you can even have that ran periodically for you.
(Note that this is distinct from autoremove and the like; those “clean up” the shared state and free up disk space. In NixOS, these are separate processes and dependencies which you don’t explicitly declare are never in the shared state to begin with.)

You see, while this could be seen as “bloat”, it has none of the negative consequences bloat has on other systems such as more packages for you to manually manage, more binaries in your PATH or weird interactions of other programs. It’s just easily managed disk space and disk space is honestly quite cheap.

Yeah. I feel the same way. I remember NPM (nodejs) had this exact issue and you would end up having so many duplicate packages.

I believe shared dependencies are not duplicated.

Not exactly. If one package needs foo as a dependency, and another package also needs foo, it won’t download a second copy.

But if another package needs, say, an older version of foo, it can download the older version of foo and you’ll have two foo packages.

This is possible because Nix packages have hashes to differentiate between them, so any package can ask for the exact version of foo it needs instead of asking for foo in general and hoping the version it gets isn’t incompatible.

Pretty sure this is also different from other containerized package managers, like Flatpaks or Snaps, which I believe throw all the dependencies in with their packages so each package has exactly what it needs in its container, and which is obviously going to be much more bloated than having shared dependencies. As far as I know Nix on the other hand doesn’t get any more bloated than other distros (keep in mind that regular distros like Arch will still sometimes have multiple versions of a package, for example Python).

Each version of a library (or any package) will only exist once, and things are garbage collected when not referenced.

Tbh i would not mind the extra bloat if it meant i get stability.

No.

But Arch supports around 14,000 packages and any branch of Nix has around 100,000 stable and 100,000 unstable packages.

I’m assuming you mean the ability to run an AUR-helper and automagically install from PKGBUILDs; in which case, the answer is no. IMHO, lack of AUR access isn’t as big of a deal as it used to be since Flatpak covers a good portion of what I have downloaded from the AUR in the past.

You can thank Flatpak for that. Dependency hell is real, especially on Debian, which ships old libraries. If you stick to default repos, you’re unlikely to directly run into dependency issues, but once you install a program manually or from another repo, it’s another story.

One example you may not have noticed, but which is a direct consequence of dependency hell, and a serious security issue, is for Firefox on Debian 11: it took around 6 months after it was EOL for Debian to update Firefox ESR. Twice (in other words, every single Firefox update on Debian 11).

There were similar issues for Chromium.

Source: https://www.phoronix.com/news/Web-Browser-Packages-Debian (same thing happened the year after, at least for Firefox, I don’t know about Chromium).

Add Guix to this.