5 ms·

If you just want someone to shoot you straight: Documentation and naming conventions for Nix are absolute shit across the board. This will get downvotes, and p

• bsnnkv 4y ago
  That last sentence is so true. I'm all in on Nix and I couldn't elevator pitch it if my life depended on it.
  • kadoban 4y ago
    "A completely repeatable setup all the way down."
  • tomrod 4y ago
    Completely repeatable setup. Like Docker, but works.
    • SuperSandro2000 4y ago
      Docker is not repeatable. If I try to build the same Dockerfile in 12 months then I likely do not get the same output and it wouldn't be surprising if it does not build at all.
      • tomrod 4y ago
        Correct and agreed, hence my "but works" portion of the comment! The notion of portability is Docker's bread and butter. With proper version pinning you _might_ get lucky with repeatability too. Most people anticipate repeatability to be part of portability, but it really is a distinct notion.
      • pxc 4y ago
        This fits with the usual definition of repeatable. Repeatable means that you can run the same steps, but if the steps are non-deterministic, repeating them doesn't guarantee the same result. > it wouldn't be surprising if it does not build at all. This part is a stronger point, and it's true. When you repeat something and what you get is not just a different version or variation but something with totally different or broken behavior, that seems bigger than an ordinary failure of reproducibility.
  • darthrupert 4y ago
    Uber- I mean Haskell for operating systems. Like Ansible but more bdsm. Linux not making you feel superior anymore? Try Nix!
  • SuperSandro2000 4y ago
    NixOS is a reproducible, customizable, programmable and adaptable Linux distribution.
  • JamesSwift 4y ago
    - Nixpkgs: Content-addressed reproducible package manager. No collisions because of the content-addressed part. - NixOS: Full OS that says "what if we did the same for the whole OS"
  • pxc 4y ago
    Here's one: Nix solves what Docker merely works around. The secret of Nix is the application of the common wisdom of memory management discipline in modern programming language design to the process of building and distributing software. The payoff is, as with garbage collection in the original case, and immense leap in safety, productivity, and maintainability for software build and deployment systems. Concretely, Nix and the ecosystem of tools built upon it and each other mean: - configuration management that never drifts - upgrades that can always be rolled back in seconds - servers that don't accrue cruft - software whose bill of materials comes for free - an end to version conflicts - packages which can always be bundled into a minimal container image in seconds - build artifacts which turn out the same no matter where or when you build them - software running as-needed, even locally, without having to be installed or manually cleaned up - a single, simple language capable of defining your entire stack, from building individual assets to managing cloud infrastructure to deploying service-oriented systems - an end to 'works on my machine' bullshit in their development environments *without* the inefficiencies of virtualization— even on macOS - user-mode package management for supercomputers and mainframes - the ability to boot into yesterday's workstation with two keystrokes at boot time - a time machine for running obsolete software which can't build on modern systems - a time capsule for software research being conducted today - the largest, most up-to-date package collection in the world and much more. The benefits and applications and extensions of Nix are so startlingly vast and diverse because ultimately, the Nix ecosystem is not an iteration on a tool— it's a renaissance. You should join it and start shedding obsolete problems.
• preisschild 4y ago
  > OS is actually called Nix Not true. The distro is called `NixOS`. The package manager and it's language is called `Nix`. I do agree that the learning curve is extremely steep.
  • tomrod 4y ago
    That's not a learning curve, that's a brick wall. Maybe call the package manager something catchy like "pacman" or "update_software_from_repos" :)
    • kaba0 4y ago
      Well, there is a model change as well, traditional package manager doesn’t make as much sense for Nix.
• chriswarbo 4y ago
  > Language is called Nix Yep; that's a bummer. The manual calls it the "Nix expression language", and some people refer to it as "nixlang" (similar to Gophers saying "golang") > OS is actually called Nix Nope, it's always NixOS; 100% of the time. In fact, the naming confusion goes the other way in this case, since the whole project (Nix, NixOS, etc.) lives on the domain nixos.org, and the GitHub account NixOS! > package manager is called Nix The commands are called Nix; but I personally find the idea of "package manager" just complicates things. Nix is more of a build tool, like Make; internally, it uses "derivation" to refer to anything from a text file to an entire OS. An application, like a music player, may involve many derivations (e.g. a derivation for its source code, a couple of derivations containing patches, a derivation for an interpreter with the required libraries, etc.); indeed the "actual program" in our $PATH is often just a script which invokes some other binary defined via a different derivation ;)
  • SuperSandro2000 4y ago
    > some people refer to it as "nixlang" more commonly just nix language or you know it out of context
  • JamesSwift 4y ago
    I always refer to nix on mac as "nix package manager" to disambiguate. It seems to be the common way to do so.
• SuperSandro2000 4y ago
  > naming conventions for Nix are absolute shit across the board No, not really. They are not consistent for every part and not every package is up to date with everything but if you get the gist you can easily guess things. If things are really weird we can always rename them.
• mananaysiempre 4y ago
  > That being said a lot of smart people here and in my peer group swear it's the truth, despite none being able to elevator pitch it. OK, I’ll bite. Nix is a build system. NixOS is a Linux source distro built on top of it (cf Gentoo, gittup, BSDs). Except you won’t need to build anything. Nix builds (should) execute in an isolated environment, thus the build artifacts are (ideally) bit-for-bit identical no matter where they were built. This means you can have a shared artifact cache (cf Bazel). Now for the clever part: in a distro, such an artifact cache is the same thing as a binary repo. Thus you are in fact using a (somewhat disk-space-hungry) binary distro until you want to patch something, at which point it transparently reverts to a source one (up to and including rebootstrapping the system compiler if you wish). That’s the gist, but there are some more goodies on top of that. First, none of this really requires a NixOS-only world. Thus, as an intermediate step, there’s Nixpkgs: a ports-like collection of packages that runs on conventional Linux and macOS systems (*BSD support is possible but has bitrotted). To maintain isolation in such an environment, all binaries it builds refer to dynamic libraries by build hash rather than load whatever’s present, and are usually wrapped to ensure other parts of the ambient environment don’t leak through. But once you’ve done that, more or less the only thing remaining to have a “gimme a shell with P, Q, and R in it” command is to point PATH to the right build directories. Hermetic build environments (cf virtualenv) for any supported language, user-scoped rootless package installs, good stuff. Second, what NixOS adds on top of that (apart from a kernel) is a system for building system configurations out of Nix-language descriptions. It’s a bit clunky, like all config generators, but once you commit to maintaining all of your /etc that way a full rollback of (the NixOS-managed part of) the system is a single GRUB selection away. There are also things like “run a QEMU with this system config inside”, “build a Docker-compatible image with this system config inside”, etc. Finally, as to how this works, Nix the build language is really simple, it’s JSON + (pure) functions + laziness + a build recipe type. Usually you just generate some shell or Perl or whatever scripts and stuff them into the recipe, so for Nixpkgs it’s honestly a bit overkill, but NixOS uses it to define a rather clever system with options that (if defined) set values of other options that ... all the way to the options that define the raw content of each file in /etc, with rules for merging option values if you wish (cf CUE, Dhall). If your mental model of your system is more abstract than the configuration of each individual service, it’s not hard to write it down as Nix code that defines some new NixOS options, then define your system—or several—in terms of those options. Bad parts: Apart from the build system as such, the CLI includes support for a lot of the idioms I mentioned above, so the separation may not look that clean. (This is not helped by the fact that a complete CLI overhaul is in progress, with old commands like nix-build and nix-env being superceded by a single new one, nix. The nixos-* ones are separate for now.) The language is perhaps a bit too minimal and lacks a standard library, so Nixpkgs ends up containing that as well, without much in the way of documentation. You will have to refer to the source there. The library is mostly simple list and mapping utilities, so it’s not difficult, but figuring out whether the thing you want is in it or not can be frustrating, and the API won’t win any beauty contests. It can be slow.
• colordrops 4y ago
  Sounds like they aren't very smart if they can't elevator pitch it. Perfectly reproducible OS with easy rollbacks. OS never gets crufty, no need to reinstall every release version or two. Single configuration language for all apps and system components. Composable and shareble config modules at any level of abstraction, e.g. you can piece together many git repos to custom roll your OS. Isolated dependencies for every package, meaning no dependency hell (similar to docker). You can have multiple versions of everything running live. Ability to run temporary environments using the same config language. Current OSes are like VAX or TRS-80 in comparison. Nix-likes are the future.
  • kaba0 4y ago
    My Litmus test for package managers is the ability to install gnome, switch it out for kde and back. (Or starting with kde). One should be able to do that without accumulating garbage (packages that are no longer used, config files, etc), but so far only NixOS passes it (and I didn’t try but assume Guix).
• Ixiaus 4y ago
  Nix the language enables you to write explicit build recipes that can be reproducibly built with good integrity guarantees and granular and distinct knowledge of the build-time dependencies and the run-time dependencies (so you only ever transmit closures that have what they need to execute). Nix the set of tools gives you convenient command line tools that can: evaluate Nix language expressions, build recipes, analyze build-time or run-time dependency graphs of a recipe, give you ephemeral shells with the packages you want in scope but not installed "globally", package management tools to install packages globally, and recipe diffing tools so you can see how recipes changed. Nix the package manager is a convenient, gigantic, community effort to explicitly describe how to (reproducibly) build almost all of the OSS software that users need and it comes with a substitution cache so that most recipe build products are easily substituted when installing, so you don't have to build. Even if you don't use Nix, nixpkgs is still impressive because you have the most explicit documentation for how to build a piece of software from source and all of its dependencies than anywhere else on the internet, it usually rivals project author's in its specificity, explicitness, and clarity. NixOS the Linux distribution combines all of this together with a convenient configuration module system and generally good defaults to give you an operating system that is declaratively specified from your etc hosts file all the way down to the recipe for building the kernel, a rich and granular dependency graph, reproducible OS configuration builds, and diffs between closures. My biggest gripe with Nix is the lack of static types. This was the originator's biggest mistake that Nix will be living with for a very long time to come. Static types would have helped bring the learning curve down IMHO and made it easier to document and less frustrating to debug. That being said, the overall properties of Nix, nixpkgs, and NixOS far outweigh the pain points in my six years of production experience with it and for what we care about: auditability, reproducibility, explicitness, efficiency, and integrity.
• pmarreck 4y ago
  "Derivation": A per-package lockfile (that is, a merkle tree of dependencies with the hash of their binaries plus the hashes of any deeper dependencies... think git with its commit hashes) that is computed at runtime when that particular binary is installed or updated. This ensures that it will always run with the exact versions of the things it depends on, and upgrades to sub-dependencies (like glibc, or openssl, etc. etc.) won't suddenly break things, because multiple versions of those can now exist in parallel, since its "name" (with regards to the nix store) is not just the canonical name but the canonical name concatenated with its "commit hash" (as it were, using git language) so basically, when you install something with nix, it's specified all the way down to the bare metal (except for perhaps the kernel)
• pxc 4y ago
  This is mean, but it's not so blatantly false that it's worthy of downvoting. Nix and Nixpkgs are messy, evolved things with a lot of history and quirks. They're also very powerful tools that can change the way you even approach computers. If you stick with them long enough, they may inspire you to extend and leverage them in creative ways... continuing the process of messy evolution. :)