NixOS – Purely Functional Linux Distribution

it just fixes problems most people dont have.

same with kubernetes i guess. such a great experience if you don't have to host it yourself

https://old.reddit.com/r/NixOS/comments/64xyd7/nix_package_m...

Another problem is that the documentation for individual functions is nonexistant. If you want to know how a particular function works, you have to go to the nixpkgs repo in github and try to guess about where the function's definition would live in the massive directory structure, and once you find the definition you care about, you have to read the source code (in Nix expression language--if you're not well acquainted, good luck: the docs are pretty terse and hard to Google for as previously mentioned) which likely references other functions, and since imports don't seem to correspond with the directory structure, you're back to guessing where the symbol you're looking for actually lives. The problem is exacerbated by the dynamically-typed nature of the expression language; other dynamically typed languages at least tell you what type of arguments they expect, but since these definitions aren't annotated at all, you're left guessing. Documentation would do wonders for the project, especially if it's autogenerated like other languages and put in an HTML format so we aren't left hunting around the nixpkgs repo.

What Nix strives to be seems promising, but it's really hard to even evaluate the core ideas for all of the usability issues.

I'm thinking something like a blog post where someone patches the Linux kernel, does a `nix-build | cachix push` and then show how another naive user might do `cachix use && nix-build` and get a magic no-op build. Maybe just a slightly more fleshed out example under the "What" section of the Cachix homepage.

For the non-Nix/NixOS folks, it's an impressive demo, and I suspect even for Nix-folks, it's impressive for hiding all of the signing/upload complexity.

For others reading this comment, Nix + Cachix means that no two people on your team should ever need to spend CPU cycles building two copies of the same binary, or the same docker image, or the same VM image, etc, assuming all of the inputs are the same. It's so cool, I'm so happy to keep seeing people finding out about Nix and NixOS. I feel like what Kubernetes did to application development, Nix does to operating system, toolchain, and application development, and configuration management.

[1]: https://github.com/colemickens/nixcfg/blob/master/utils/azur...

EDIT: follow-up: It look like less than 2 minutes to start pushing to my new Cachix repo. Excellent job with this, it's going to be hard to motivate myself to keep maintaining my scripts with this being so easy.

A simple example: I wanted to build FFMPEG, but with non-free libraries enabled (which is not the default). Rather than edit "ffmpeg-full" in the nixpkgs repo, I just overrode it:

    # default.nix (in some project directory; call "nix build -f ." to run it)
    with nixpkgs;
    {
      my-ffmpeg =
        let overrides = {
        nonfreeLicensing = true;
        fdkaacExtlib = true;
        ffplayProgram = false;
        qtFaststartProgram = false;
      };
      attrs = {
        name="my-ffmpeg-" + ffmpeg.version;
      };
    in
      ffmpeg-full.override overrides // attrs;
    }

2. This will take a bit

First with the naive, as-described nix there are two options:

* For updates to propagate through all the build servers takes a day or two, so you can just be insecure for 48 hours

* Or, you can always build your packages yourself by setting your update channel to just be the head of the nix repository, but now you won't get binary caches for anything that has had its source updated since the last build. This actually works better than you might think, but is still a no-go for most people.

Both of those suck, so there is something called replaceDependency[1] that lets you define a package in terms of the already built-package and a new version of the library. This lets you quickly get a security update in a shared-library out to multiple slow-to-build packages quickly.

1: https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp... The existing way is to use replaceDependency(), which takes an input as an already built package and as an output the same binary but with different RPATHs for the shared objects. This however is just stopgap, as other approaches are being discussed. Since I'm not running a server, I haven't followed it as closely as I perhaps should

They don't. NixOS does not have a concept of a released, stable distribution and therefore does not provide security patches backported to it.

You have to keep rolling forward with every new upstream release of the packages you use.

Perhaps it's OK for some people's desktops but most server environments rely or stable distributions with LTS support.

Security updates are indeed sometimes slow to arrive, for the reasons that aidenn0 already described. However! One thing that's particularly interesting about the security update process for NixOS, is that it's an open collaborative effort: https://github.com/NixOS/nixpkgs/issues/23334

More eyeballs are definitely needed for handling security issues, especially since LWN stopped doing their reports, but the process itself is definitely one that has significant potential.

I like home-manager: https://github.com/rycee/home-manager

Adoption does not and has never followed from technical superiority. The tech industry today would be almost unrecognizable if it did.

If it's anything like Haskell, then here's how this goes: there are going to be some problems for which NixOS is not only the best solution but the only reasonably viable solution. For all other problems, it will be inconvenient.

Is it though? I deploy applications (a mix of Python, node and C++) for which the vast majority of the dependencies are missing, misconfigured or out of date in nixpkg. Sure I could volunteer to maintain dozens of nix packages but the fact remains that forcing all of your deps through a single packaging system is risky. NixOS in particular encourages you to buy into the ecosystem 100% or not at all. That's a big ask, even for small organizations.

Compare that to Docker where your can build your app on top of any base image and use/develop/deploy that artifact from many different environments. I can distribute and build my dependencies in whatever way is appropriate for my application, my team and collaborators can hack on that image from their chosen OS, and the application can be built deterministically and deployed anywhere that can run a docker daemon. No lock-in required: the dev host OS, deployed host OS and container OS are managed independently. Docker is not as "pure" as NixOS but it works under the real-world constraints of heterogeneous environments.

Of course everything would be better if we could all agree on one package manager and one OS and one programming language for that matter. But we can't, so the clear winner is the technology that can leverage this homogeneity into a uniform build artifact (containers). Technologies that require package-level homogeneity across an organization in order to succeed are fighting an uphill battle.

One reason it hasn't gotten much traction yet might be because the perceived benefit is too low to convert existing systems: You can upgrade in place, downgrade, manage a whole fleet easily etc, but the people with these problems already have (bad) solutions for those in place.

So there's a lot of inertia, and uptake has to come from new installations.

I too managed a Chef based infrastructure, and it was terrible. I don't like it when simple deploys break a production system because of a missing comma in some config file. With NixOS/NixOps, many issues that Chef has just don't exist.

This also has the advantage that you can use the exact same distribution that the instructions for said package mention. (If the thing you want to compile has instructions for Ubuntu 16.04 no problem just use the docker image for that)

For anything that you want to use on a regular basis, creating a nix package is pretty easy most of the time. If you only want to build a newer version of a package directly from git, you can even copy the package for the stable version and just overwrite the src in many cases.

Regarding software that works on NixOS but not on other distros I think it's usually the other way around: by testing your software on NixOS you uncover issues that would have made your software less portable (hidden dependencies, hardcoded path assumptions, ...)

For such cases I like Docker because it lets you easily create little mini-Ubuntus and do whatever you want there.

    $ nix-shell -A hello

This is OK for development cycles (`make && make test`, things like that) but not for the long term. Most of the time incremental development works just fine this way, though, especially for software you're writing or developing yourself. You just run your commands inside a `nix-shell` instead.

If you want to use a Git repository for something, most of the time you can just 'override' a packages source code input to a new version. In Nix, even source code is actually an 'input' (a parameter) to a build script (a function), so you can just provide a new copy of the source code (pass a different parameter to the function) and rebuild. Of course, someones Git repository may have changed in ways that make the old build script incompatible. You can similarly override/update the build script, and there are a number of mechanisms to do this.

> My concern is that it would be more difficult to install software that doesn't have a nix package built (in particular, from git repo trunks)

This is true and in reality most Nix users are package authors. You will probably find things that are not packaged and you will have to author them. Occasionally, a package may not have some feature enabled (maintainers generally decide these things on their own when it comes to optional features), so you may have to fix it.

Updating/custom source code versions isn't as much of a problem though. Once the Nix expression for some software is authored just pointing/updating the source repository is normally enough to do it.

> and also more difficult to have confidence that the software I write would work on other Linux distros

IME, if your software can work correctly on NixOS with little modification (or extremely perverted build scripts), it will almost certainly work fine anywhere else. In particular as long as your build system obeys "standard rules" like supporting PREFIX and respecting things like `pkg-config`, not hardcoding binary paths everywhere but detecting them, it will normally work just fine. cmake, autotools, pypi, etc all have pretty usable solutions for the extremely common cases. Nix can often quickly unveil assumptions in your build step that would previously be masked (for example, I cannot count the amount of READMEs that have 'apt-get' instructions for build prerequisites, which do not actually account for all the necessary dependencies.)

Realistically I have authored dozens of packages and the ones that cause the most pain are ones that have complex, bespoke build systems with a lot of assumptions built in, or that don't actually specify all the dependencies they think they do, and silently get things wrong. Think packages like OpenJDK, Mono, any web browser, etc etc. Other things occasionally require some bespoke patching to get cleaner integration, even if the build system itself is otherwise nice enough (such as PostgreSQL or Linux itself.)

> In practice NixOS users find these to be significant issues? How do you deal with them?

They can be annoying, and I would say writing build expressions is sometimes a bit more difficult than I'd like -- but not enough to outweigh the actual advantages, which are otherwise tremendous.

Normally I just author packages and submit them upstream for cases like this. In the case where a fix for some issue seems reasonable to upstream I just submit it upstream like a traditional maintainer. Not everything falls into this category, though, so, like any maintainer, you might be on the hook for it.

Example:

https://nixos.org/nix/manual/#ex-hello-nix

For any standard build tools (cmake, scons, whatever) it's just one extra line. Applying patches is one extra line. For a non-standard workflow, you can supply a shell script for each step (unpack, configure, build, install, &c.). so it's just however many lines that is.

I've had zero issue getting any source-based third party stuff running. Binaries are a pain, but that's always true if you aren't running the exact distro that the binary was built for.

I have a set of overlays for various packages and try to submit updates and improvements upstream. Having some experience with making packages for other package managers, I found making Nix derivations easier than RPM or deb packages and about as difficult as Arch PKGBUILDs. stdenv automates a lot of work, and when a package uses a standardized configuration/build system (autotools, cmake, cargo), most of the work is in finding/adding the dependencies.

I did some Haskell programming ~6-7 years ago, so the learning curve for the Nix language was probably less steep.

The primary difficulty I found is that not everything is documented equally well and you often have to poke through nixpkgs to find examples and/or good practices.

also more difficult to have confidence that the software I write would work on other Linux distros

I guess I have been lucky that I write work-related code mostly in Go and Rust, so building on other systems is never really a problem. But for C/C++ projects I would just compile in an Ubuntu container as well.

Interestingly, you can use Nix under other distros and even MacOS just fine, due to the way it isolates dependencies: https://nixos.org/nix/

https://godarch.com/

It supports Debian/Ubuntu/Arch/VoidLinux currently (Gentoo soon).

With Darch, your entire desktop is scripted and reproducible.

Here are my Arch recipes: https://github.com/pauldotknopf/darch-recipes

I find this to be a better middle-ground between <your favorite OS> and Nix.

It doesn't handle binary-only applications though (e.g. NoMachine, games, &c.). It has a couple of options to make those work, and it's almost always possible to get it to work natively, so if there's not already a nix expression for the app I want, I just take the expedient path of having a docker container with an ubuntu user-space, since pretty much all proprietary apps run on ubuntu.

Edit: apparently packages are distributed in binary by default, but if you customize options it’ll be compiled locally. My mistake.

NixOs is the amalgamation of 3 things: Nix, Nixpkgs, and the other bits it takes to make an os.

Nix is a programming language and a packaging tool. It allows packages to be programmed in a type safe way, then executed to install the actual libraries or binaries. This is the area of the system that I actually know the least about.

Nixpkgs is a large collection of packages for Nix. The community really has worked on this set of stuff like gangbusters, it's quite impressive how many things they've wired in from scratch. Each package specifies its dependencies, and the various options it accepts to tweak various options. A good example would be setting the data directory for the postgresql service.

NixOs combines the previous two items along with the other bits it takes to make an OS work. So they provide official installation instructions and media, configure how Nix is going to actually be run on NixOs (as compared to say, OSX), provide stable channels for various versions, etc. Basically all the regular things you expect out of a distro.

Personally, I'm not exactly sure if this is where Linux is going to go, but I think that this is how Linux would have been built if disk was much cheaper back in 1970ish. A lot of the regular problems of systems management are completely solved in NixOs.

Need two different versions of the same shared library? No worries, they can each have their own copy, and Nix will automatically make sure the correct one, specified by the hash of all the build flags, will be the one that's loaded into memory for said program.

Have a shared system? Great! Users can install userland programs without root privileges. Because items are inserted into the nix store idempotently and paths are not universal, I can install vim without any other users seeing that, and without root. The only thing that takes root privileges are services (e.g. Postgres), or installing programs for universal access.

Sadly this does come with some downsides. A lot of programs over the years have come to make very bad assumptions about program location, or the ability to modify the PATH variable. A good example of this issue is RVM, which for the life of me I could not get to work.

This means you can plug the sha from the ISO that you link to (nixos-graphical-18.09.776.6a3f5bcb061-x86_64-linux) and get this URL: https://github.com/NixOS/nixpkgs/commits/6a3f5bcb061

And the ISO URL from NixOS.org ([...]/nixos-graphical-18.09.1023.06fb0253afa-x86_64-linux.iso) leads us to https://github.com/NixOS/nixpkgs/commits/06fb0253afa

If you check both, you'll see they're both commits from the upstream `nixpkgs` repository, just a couple weeks apart. So it looks like your torrent is likely an old official ISO that could be upgraded in place the same way the newer ISO would need. (Note, I haven't confirmed that, someone could've uploaded a malicious file with a nice filename, etc. Don't take my word for it, etc.)

(edit: ah, and if I had to guess, the 776 and 1023 as part of the filename is probably the number of commits since the original 18.09 tag was created.)