[mirap]

Can someone explain what is NixOS designed for? (ELI5 please)

[mightybyte]

NixOS is a Linux distro built around the Nix package system. Nix is built around the idea of immutability. It makes all packages immutable by giving them their own directory identified by a hash that is derived from ALL of that package's dependencies. This has a number of desirable properties:

* It makes it trivial to have multiple versions of the same package installed at the same time and allows you to switch between them at will.

* It is trivial to roll back your system after a failed upgrade. Difficult system recovers after you upgrade to a new unstable version are a thing of the past.

* Non-privileged users can install software completely securely.

* Projects packaged with nix have the best possible build reproducibility because nix accounts for ALL of your dependencies all the way down to the lowest level system libraries, compilers, etc.

[nextos]

Reproducibility.

In a nutshell, it's a purely functional Linux distribution. That means all changes you make to your system are non-destructive. For example, you can always roll back to a previous OS state, which is represented by a hash computed from all packages installed, and all options you've set. In turn, package hashes are computed from the package sources and all inputs (buildtime and runtime package dependencies).

[glhaynes]

I feel like one day this will be how all OSes work and we'll look back and wonder how we ever found the old way acceptable.

[swoorup]

Then another 10 years later, we'll think this is all too complicated and reinvent the wheel/simplicity.

[corysama]

Besides reproducibility, I like it as a nooby Linux user because I can add and remove packages willy nilly with complete confidence that my machine is in a clean, reliable, understandable state. I can even set up conflicting package arrangements and flip between them with a single, fast command.

[pxc]

Yep! I think this point is sometimes underemphasized as NixOS has some rough edges and its users tend to get carried away and geek out about how it works.

But it's a great platform for fearless experimentation, because it's so easy to revert any change you later decide was undesired.

[adamtulinius]

We migrated from Debian+Ansible to NixOS to easier be able to ensure consistency across servers. Rolling back and forth is really easy for most things.

It's also the most convenient system I ever worked with for creating custom packages, which is lucky, because NixOS does have fewer pages compared to other distributions.

[pxc]

To supplement and illustrate your claim about NixOS being easy to package for, I'd like to share an example:

I've been using NixOS more or less exclusively for ~2.5 years now. Whenever I want to run software on NixOS which is not already in Nixpkgs, I package it (if I want it bad enough). This week, for example, I packaged KSmoothDock so that I could try it out.

This is the whole thing:

    { mkDerivation, lib, fetchFromGitHub
    , cmake, extra-cmake-modules
    , plasma-framework, kwindowsystem }:

    let
      version = "5.9";
    in

    mkDerivation {
      name = "ksmoothdock-${version}";
      src = (fetchFromGitHub {
        owner = "dangvd";
        repo = "ksmoothdock";
        rev = "v${version}";
        sha256 = "1fbghyd079xk4q5na8msna5zkfg85c4ksyfqy524v2pm96dyl2dr";
      } + "/src");

      nativeBuildInputs = [
        cmake
        extra-cmake-modules
      ];

      buildInputs = [
        plasma-framework
        kwindowsystem
      ];

      postPatch = ''
        substituteInPlace CMakeLists.txt \
          --replace /usr/share/ share/
      '';

    }

It didn't feel like much work and I think it only took a few minutes. In this case, I was able to base the package definition on another 3rd-party dock for Plasma, so it was even easier than usual to get started. I just copied the other package and changed the package name and location of the source code, and everything worked. I then cleaned up by consulting the README for the project and removing as many extraneous dependencies as possible, and smoothed over a quirk, which was pretty painless.

Once you get a feel for the docs (and the Nixpkgs source, just because it's a treasure trove of examples), packaging for/with Nixpkgs is usually pretty easy, and the results pretty readable.

I should also add that the range of packages already included also seems to me to have improved a great deal over the years that I've been using NixOS. And I think once NixOS gains support for Snap packages and Flatpaks (the latter is in the works and has been making good progress recently), it will become a much more viable desktop OS for those unwilling or unable to deal with packaging the odd missing application.

[buovjaga]

> NixOS does have fewer packages compared to other distributions

It's not bad, though: https://repology.org/repository/nix_stable

Haskell and R packages will be added soon to give a more complete picture.

[adamtulinius]

You're right, it's not bad, but chances are one will need to do a bit of packaging work if using NixOS for many different or complicated things.

But as I said, it's all in all really nice to work with Nix.

[hollerith]

>It's also the most convenient system I ever worked with for creating custom packages

Is Arch Build System one of the systems you've ever worked with? (I found ABS very convenient.)

[Nullabillity]

Coming from Arch I love NixOS for two reasons:

- No separate AUR that some packages are arbitrarily located in

- Not having to care about binary packages: they are just transparently downloaded and used if available

Pacaur makes the AUR a bit more palatable, but you still notice the split.

[adamtulinius]

Nope, I haven't. Last time I ran Arch as my personal OS, a normal update bricked the system after a week. :P

My experience is mostly with deb and rpm before Nix.

[majewsky]

When was that? I think I had stuff like this when first looking into Arch ~8 years ago. It's now been my daily driver for about 6 years, and I haven't had my system bricked. I have had a few updates that broke stuff, which could be solved through a downgrade, but no bricking.

So maybe the Arch maintainers got more disciplined, or maybe I just got better at not breaking things. Probably both.

[paride5745]

You really do not want to use Arch for production, enterprise systems.

[hollerith]

OK, but I still want an answer to my question -- to help me decide what distro to choose for personal use.

(I already get that the design of NixOS prevents the system's ending up in an incoherent state, which will happen on Arch eventually if you wait long enough between upgrades.)

[vertex-four]

I've developed packages for ABS before, and it's nice. What nix's model gets you is (a) largely avoiding complex bash scripts, and (b) a pile of tools for working with packages that you don't want to install semi-irreversibly. nix-shell, for example, will put you in a shell inside the build environment, and you can run the build steps yourself and see what the outcomes are. nix-build will build a piece of software and create a symlink to the output, but not install it into your user's package namespace.

One of the nice things is that you can install many things without having to sudo - the build is run by a daemon and sandboxed. nix-shell can also be used to create a shell in which a given package set is installed - you can use that to use a piece of software as a one-off or create a development environment that doesn't pollute your general system. Tools like home-manager[0] can help with managing your home directory in a similar way to NixOS's management of your system, too - I have redis and postgres installed using home-manager to run as my own user on demand under systemctl.

[0] https://github.com/rycee/home-manager

[rakoo]

Imagine any single change in your system configuration (packages, configuration, startup scripts, whatever) is loaded into a source version control as you move forward.

If something fails, you can always rollback to a previous revision, and since everything is there, you know your whole system will be working.

If you want to reproduce your system, you can copy the whole content and "checkout" the relevant revision on the new system. Because the hash is the same, every single bit underneath will be the same.

[k__]

Reproducible OS setups.

Like Docker, but it uses install scripts instead of layered images.

[aidenn0]

And it does a lot more work to prevent you from shooting yourself in the foot.

Docker scripts that e.g. clone a remote and build from the HEAD are not reproducible. Another example would be downloading fancysoftware-latest.tgz

Nixos will have you either pull from a specific git commit, or will hash the sources, so the default behavior is reproducible.

[agumonkey]

and an actual solid language instead of a sequence of whatever