27 ms·

What Is Nix?

• mehrdadn 6y ago
  I'm still confused. What is Nix? Is it an OS, or a package manager? From the looks of it it's a package manager that I should be able to use it on any POSIX system, but I doubt that's the case?
  • yjftsjthsd-h 6y ago
    > From the looks of it it's a package manager that I should be able to use it on any POSIX system, but I doubt that's the case? No, that's basically true. It's fully supported on Linux and Darwin, assorted BSD support is underdeveloped but in scope.
  • statenjason 6y ago
    What is Nix? Nix is a powerful package manager for Linux and other Unix systems that makes package management reliable and reproducible. It provides atomic upgrades and rollbacks, side-by-side installation of multiple versions of a package, multi-user package management and easy setup of build environments. What is NixOS? NixOS is a Linux distribution with a unique approach to package and configuration management. Built on top of the Nix package manager, it is completely declarative, makes upgrading systems reliable, and has many other advantages. [1]: https://nixos.org/ https://nixos.org/
    • mehrdadn 6y ago
      Thanks, but that makes me wonder how that's even possible given that distros make their own modifications? Do people port each distro's packages to Nix then? Are they kept up-to-date? Or does it automatically translate from apt/pacman/etc. databases somehow? Or does it just basically install vanilla packages on all distro?
      • throwaway894345 6y ago
        Yeah, there is a giant repo of package definitions at https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs. Those definitions tell nix how to build everything from the ground up.
      • tathougies 6y ago
        > how that's even possible given that distros make their own modifications? Own modifications to what? All the packages in nixpkgs depend only on other packages in nixpkgs. If you install nix on an ubuntu system and then install a package from nixpkgs, then that package won't use any ubuntu libraries.
        • mehrdadn 6y ago
          > Own modifications to what? To the packages. e.g. I believe Ubuntu modifies Python so that sudo pip install uses /usr/local instead of /usr. Lots of other patches and backports I'm not necessarily aware of. That's basically what makes Ubuntu Ubuntu, otherwise it'd be more like Arch. So how does Nix deal with this? Do you get the value-add from your distro or do you basically end up with pseudo-Arch wherever you start?
          • fwip 6y ago
            If you install python through nix, you get the nix version. If you install python through apt, you get the ubuntu version.
            • mehrdadn 6y ago
              I get that part. I'm asking what the Nix version is like. Is it like the Ubuntu version with all the patches and backports and everything, or is it like the Arch (i.e. basically original unmodified) version?
              • catern 6y ago
                Nix packages are typically close to upstream, but low-level packages sometimes have patches to make them more reproducible and deterministic, so that they work better with Nix's efforts for determinism and purely-functional packaging. Nix packages are created from scratch, not copied from another distro. Nix is typically one of the most up-to-date distros: https://repology.org/ https://repology.org/
  • leadingthenet 6y ago
    It’s a package manager that underlies NixOS. It can also be run under any other Linux distro, and macOS.
    • X6S1x6Okd1st 6y ago
      And of course Windows Subsystem for Linux
  • kdtsh 6y ago
    Nix is a package manager. NixOS is an OS which includes the Nix package manager. My understanding is that a feature of Nix is you can declare an OS (I.e. declare the collection of configurations and software etc for an OS) which Nix will process to provide you with an OS called NixOS.
    • prox 6y ago
      So it processes the config file (and thus all needed packages) one time or does it process it every time you boot?
      • heisenzombie 6y ago
        You type nixos-rebuild switch and it builds you an entire OS and drops you into it. It also makes the new OS the default on startup. Because it's all purely declarative, your old OS is still there. If things go wrong then you can just pop back to it, either in the command line with: nixos-rebuild switch --rollback Or when you reboot, the previous 'generations' of your operating system show up in GRUB, so just choose an older one to boot.
        • prox 6y ago
          Thanksfor your comment.This is very interesting for my Raspberry Pi. The ability kit it out according to function is great.
      • takeda 6y ago
        Whenever you run `nixos-rebuild switch` a symlink is created for `/run/current-system` which is the current system. That's what is used on every boot until another change (you also have an option in boot loader to boot into prior versions (it is just a symlink))
  • pjkundert 6y ago
    POSIX (eg. Linux), Mac and Windows. Yes, it is magnificent. Immutable, deterministic software on all 3 major platforms. Combined with cached build artifacts, builds and their outputs (including complete target system updates/upgrades) are blisteringly fast, cryptographically secure and completely deterministic. EDIT: Sorry, yes; Windows only via WSL, not natively on Windows proper.
    • mehrdadn 6y ago
      Windows? You're kidding me! Where do I see Windows support? On their website I only see Mac and Linux.
      • exdsq 6y ago
        You can use it on WSL1 and WSL2 but you can't use it natively on Windows. I used it on WSL2 just this afternoon and it was seamless but that makes sense because WSL2 is basically just a Linux VM anyway.
        • _hl_ 6y ago
          Although I don't see why it wouldn't work on Windows natively. Sure, it would probably need a complete reimplementation to replace all the POSIX stuff with Windows stuff, but fundamentally it ought to be possible?
          • exdsq 6y ago
            Sure in theory but there are a few open bugs: https://github.com/NixOS/nix/issues/2651 https://github.com/NixOS/nix/issues/2651 https://github.com/NixOS/nix/issues/2292 https://github.com/NixOS/nix/issues/2292 https://github.com/NixOS/nix/issues/1203 https://github.com/NixOS/nix/issues/1203 There's a locking issue with SQLite and the Sandbox has some namespace issues where Linux and Windows behave differently. I don't know how eager they are to make it work on Windows either, but at least WSL works :)
          • matthewbauer 6y ago
  • lmickh 6y ago
    It is pretty easy to be confused. Especially since it is also a language yet all the other replies at the time have writing have failed to mention that. While I like the project as a whole, their naming is horrible. Just wait until you get into `nix-env` vs `nix-shell` etc...
    • mehrdadn 6y ago
      Thanks, yeah. Conceptually I'm having a hard time wrapping my head around it since package managers are so tightly tied to an OS... I feel like surely I can't just use it in place of (say) apt or pacman without causing problems? And I haven't even gotten to the language/shell/etc. as you mention...
      • lmickh 6y ago
        You use the language to define the configuration, packages, and etc. NixOS isn't so much an OS configured by a package manager as much as it is an OS + package manager that you can configure with the Nix language. Then there is also lot of tooling to hid all of the symlink magic. It is very deep rabbit hole. Most of the quick touch examples will basically look like magic.
      • solarkraft 6y ago
        You're right that using 2 traditional package managers in the same environment will cause problems almost immediately, since both will want to control the same resources. This is less so with Nix, as it mostly operates on its own folder called nix-store, the binaries in which are then symbolically linked to. It is actually designed to be able to be used this way. I know people are using it on Mac OS and I intend to install more and more packages through it to later possibly transition to NixOS.
      • saurik 6y ago
        Package managers are not tied to the OS. Essentially your fundamental misunderstanding here, from reading your comments, is that you are expecting a package manager on Ubuntu to manage "Ubuntu's packages", when the packages belong to a repository as accessed by a package manager, and "Ubuntu" doesn't really exist: "Ubuntu bionic" is merely "a bunch of deb packages that you can install from a particular repository using apt", while "CentOS 7" is merely "a bunch of rpm packages that you can install from a particular repository using yum". You can add Ubuntu eoan or even Debian stretch repositories to your APT configuration on Ubuntu bionic, and install those packages... now, the naming and compatibility of dependencies might be different as you get further and further from what you were "supposed" to be using, but they will download and install (at worst an installation script will be missing a dependency and the package will be left "half installed", which is a technical APT term). You can also install rpm on Ubuntu: it is even in the Ubuntu bionic repository. Now, what happens if you install an rpm file using it? It might very well overwrite something from a package you installed by apt, and neither might notice that happened. But you can do it. You can install yum (this will require manual install as I don't think yum is available from any common Ubuntu repositories) and then give it a CentOS 7 repository and install all the packages and what you will be left with will be approximately CentOS 7 (with some detritus from Ubuntu). So on any system apt is managing deb packages and yum is managing rpm packages and where those packages come from is just some configuration, so you can install apt on CentOS 7 and use it to install packages from Debian stretch. You can't use apt on CentOS to manage CentOS packages as apt doesn't do that (though maybe you could teach it an "rpm method" or something but rpm's version numbering and dependency management aren't really the same so this is now just a confusing digression to avoid "technically you could" responses: yes, but then you are coding that yourself). The only real exception to all of this is the kernel, but not even always as the kernel is kind of a file, but the way it is configured in the master boot record could be different... but like, you might have some distribution local kernel patches that their tools rely on for some reason, and upgrading libc on a running system is fraught with peril even when you aren't doing something insane this, so like: don't do this, but know it works. I routinely thereby create a little folder on a Debian/Ubuntu box in which I can chroot to install a little world of an entirely different set of packages from a different package manager maintained by a different vendor as provided for some random specific version of their distribution. (Alternatively, rpm supports an argument to set the system root.) In that world there are no conflicts, as you made a folder for it. When you install packages from apt or yum, usually they assume they could go in /. That is going to maximize conflicts unless you do the chroot. Nix has chosen to package their stuff not like that, and so you can install their packages on any other environment without it conflicting or overwriting. So no, you don't "use it in place of apt" to manage Ubuntu packages, but maybe Nic and Ubuntu have chosen to both package the same thing you want (this is hopefully common as both are hopefully quite complete) and so you might "use it in place of apt" because you don't want to install an Ubuntu package, you want to install a Nix package instead. And as Nix packages go to special folders automatically, it doesn't damage your Ubuntu install.
  • exdsq 6y ago
    One really cool thing about NixOS is you declare the OS just like you might a DockerFile, and you can choose which configuration file you use at booting time. This lets you install applications just during up-time (to try out a new tool), add it to the configuration file if you like it, and roll back to the version before if it breaks something. Versions are declarative too (PSql == X.X.X) and upgrades/downgrades are set there too. If I want to share an environment with someone I can just share the configuration file minus the secrets.
    • enriquto 6y ago
      > One really cool thing about NixOS is you declare the OS just like you might a DockerFile, But DockerFiles have a really terse, self-evident, trivial to read language. It is obvious what a given DockerFile means even if it's the first one you see. For nix; well, I have seen a few nix files and each one leaves me more confused than the last. Can anybody point me to good examples of beautiful, single-file, complete, self-contained terse nix examples that describe a few simple systems? Everything that I seem to find are small fragments of stuff.
      • throwaway894345 6y ago
        This is because Nix needs to express a lot more so builds are reproducible and incremental. Docker doesn’t care about these things.
        • enriquto 6y ago
          Even if Docker doesn't really care about this, the DockerFiles themselves can also describe a reproducible process, and they are certainly "incremental" due to caching (not sure of what you mean by "incremental"). Does nix power merit such a big compromise against simplicity and readability?
          • progval 6y ago
            Because Dockerfiles delegate all the complexity to a package manager (apt, apk, ...), which has its own languages (eg. debian/rules for apt). Using Docker without any package manager doing this job would be a completely different story. And btw, you can also use Nix to build docker images. For example, here is what would be the equivalent of a Dockerfile but with Nix: https://nixos.org/nixpkgs/manual/#ex-dockerTools-buildImage https://nixos.org/nixpkgs/manual/#ex-dockerTools-buildImage > the DockerFiles themselves can also describe a reproducible process It's trickier. You need to pin all versions of all packages you use, even indirect dependencies.
  • deleted 6y ago
    [deleted]
  • tel 6y ago
    It's kind of a mess. Nix is a collection of tools and systems that together form a highly reproducible build system. Nix is also a declarative, largely pure and lazy programming language that you use to design and specify the different build outputs for the Nix build system. Nixpkgs is, more or less, the only project written using Nix (and a lot of shell). It's a collection of many thousands of "derivations", many of the things you'd expect to be able to fetch from brew or apt. Each derivation encodes the steps to use Nix (the build system) to construct that output. NixOS is a Linux distribution built atop Nix, Nix, and Nixpkgs. The basic claim to fame here is "totally declarative system setup" where you write all of the configuration for your system in Nix, using Nixpkgs and some other NixOS specific tooling and libraries, and then "build" the entire system with high repeatability. Then there are a few other related projects such as Hydra (a CI server and binary cache builder—most of the time you don't build with Nix, just download the proper thing from the cache) and NixOps (an extension to NixOS which provisions whole fleets of servers declaratively). Finally, you don't need to run NixOS in order to benefit from Nix. Nix and Nixpkgs are (largely) compatible with MacOS and Linux. That means you can install Nix onto your existing MacOS or Linux system and use it a lot like you'd use brew or apt. That said, the premiere Nix experience is always NixOS.
    • mehrdadn 6y ago
      Thanks! So let's say I start installing Nix packages. What distro's packages would they end up most similar to? Say, maybe Arch (which mostly leaves things unmodified)? Does that mean you basically end up with Arch no matter which distro you're on?
      • catern 6y ago
        Trying to put it politely, but your question seems a bit confused. Arch is not the only distro that strives for minimal modifications on upstream packages. In fact, most distributions work that way - it's Debian and its derivatives that's the outlier, and these days, even Debian rarely patches upstream packages. There is much more to distributions than what patches they apply to their packages. The package manger they use, their default configurations, their compiler toolchain, their C library, their init system, their stance on software freedom, etc etc - much more than just what patches they apply to their packages. But, yes, Nix packages are mostly close to upstream, with occasional patches to improve determinism and reproducibility.
  • gnulinux 6y ago
    > From the looks of it it's a package manager that I should be able to use it on any POSIX system, but I doubt that's the case? That's exactly the case. It works by installing apps per user and not globally, so they're put into your home directory.
  • mossity 6y ago
    I started reading this thinking Nix was a programming language, became very confused when it started talking about files and an object database.
    • bb010g 6y ago
      Smalltalk has object databases, as images.
  • choward 6y ago
    > What is Nix? It's everything you could ever ask for and more. On a more serious note, I get the question though. This article isn't very compelling. NixOS is a linux distribution that allows you to specify your system in a declarative way. This means instead of running imperative bash commands like "apt-get git". You declare that you want git installed with something like environment.systemPackages = [ git ... ]; This may not sound that interesting you but it makes your system reproducible. So you have some plain text files that describe you entire system. You can check these into git or whatever. If you reinstall and use the same configuration as before you will be back at the same state so it makes no sense to do a reinstall of the entire OS. If you want to upgrade NixOS versions it doesn't really make sense to do a complete reinstall also. Rollbacks are also built in in case you make a mistake you can quickly go back. Your previous "generations" are shown in the boot menu if you restart your computer. NixOS also can run virtualized environments like docker, vms, etc. With docker it can be used run docker containers and startup. It also has it's own concept of containers which can be thought of like docker containers except they run NixOS so you specify them the exact same way as any other NixOS configuration. Unlike docker, it allows you to share packages between containers and the host system while also having isolation. Nix packages are packages like in most other package managers. It's also relatively easy to create your own packages. You can use NixOS configuration to install packages or use it on it's own as a non-root user to install nix packages while on other OSes to for example replace homebrew on Mac OSX. It also allows you to install multiple versions of the same package. You can also us it build docker images so you don't actually need a Dockerfile and you can install the docker images which get saved to the nix store. You manage them just like another package. That's right, this means you can both build and run docker images without actually using docker. NixOps is a tool for deploying NixOS to multiple computers. It builds everything on the host and copies it to the nodes. If two of your nodes use the same package it's only downloaded once. This means no configuring an apt-cache or something like that if you don't want all your machines downloading their own copies of everything. It also allows you to provision and deploy to the cloud. It basically replaces terraform, cloudformation, etc. Nix is the language used to configure NixOS and NixOps as well as to create packages that can be installed. Nix files themselves don't do anything. They just build a configuration object. You can almost thing of them as glorified JSON generators that generate the configuration which the respective nix tool uses to get whatever job done it needs to. Now don't get me wrong, the learning curve is very steep but once you learn it you "get it" and realize how it all ties together and it starts to make perfect sense. I left a lot out here (like development) but It basically solves every need I have programming, infrastructure, and computers in general and I won't go back to anything else.
  • aaronjanse 6y ago
    Nix is a package builder & manager that creates reproducible build environments. Using the Nix language, you specify what the build environment should look like ($PATH, what should be in the build folder, etc). Nix then calls a program of your choice to do the actual building. Just like Nix lets you specify a build environment using the Nix language, NixOS lets you specify, using the Nix language, what you want your operating system to look like (systemd services, $PATH, etc). You should be able to use Nix, the package builder & manager, on any POSIX system afaik.
  • takeda 6y ago
    Nix really is a purely functional, lazily evaluated language that is great at expressing dependencies in your project. You can think of it as a make on steroids, but it is much more than that. Because the language expresses what to build from a known state (i.e. nothing is installed) together with its purely functional properties, means that for the same input (source code, dependencies, configuration options, system architecture etc) it supposed to always generate the same output. Nix can be think of as package manager, and its nix-env command (which BTW is discouraged from Nix purist to use[1]) behaves like a package manager, but IMO it's more of a build system. After the author of Nix wrote his thesis he mentioned that the language can describe an entire operating system. That's how NixOS happened. You can have a single configuration file that describes what needs to be installed on your OS how configured etc. The great thing is that you can take such configuration file, and recreate another machine with it configured exactly as you want it. No need for chef/salt/ansible etc. It actually has an edge over these tools, for example if you tell that specific package needs to to be installed, and than later you remove the package from the config, nix will remove that package as well (with chef/salt/ansible, you would need to add a state that's uninstalling the package), another benefit is that all changes are atomic, you either have your changes applied or nothing is changed, there's nothing in between (this makes things like replacing X11 with Wayland, or KDE with Gnome just another change, that you can always revert). It's a very powerful tool, and the more I use the more amazing it seems. It shows that if you target specific problems the right way a lot of common headaches are eliminated. [1] it's advisable to never install packages by hand using nix-env, since that adds mutability to your system, instead you should use nix-shell (another great tool) to temporarily make specific application available, use the global configuration.nix to install packages globally on the system, or use home-manager extension which allows you to configure each home directory (that means what dot files do, but also each user can have their individual packages, and goes further, for example you can even control what extensions firefox should have installed)
    • bb010g 6y ago
      home-manager is wonderful. I haven't used nix-env in years.
  • Gaelan 6y ago
    Nix is a package manager, and nixpkgs is its "official package respositry." Both of those pieces should work on any (decently popular) POSIX system. NixOS is a Linux distribution that uses Nix in place of apt or yum or what-have-you, and uses nix to allow the entire system to be configured declaatively.
• siscia 6y ago
  Really looking forward for knowing how Shopify use nix and what problem the find with it. I was advocating for it in my organisation but eventually we decided for a different technologies...
  • lmickh 6y ago
    Burke Libbey has a few talks that are available on YouTube including a presentation at NixCon about the work he is doing at Shopify. I would highly recommend checking them out if you are interested in Nix.
    • Rafert 6y ago
      Link to that presentation: https://www.youtube.com/watch?v=rYzjKCIqUVk https://www.youtube.com/watch?v=rYzjKCIqUVk
    • burke 6y ago
      Hi! Yes, and here's the link to my recent Nixology playlist: https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4...
      • takeda 6y ago
        This is great, thank you. Can you provide more information about setting a build infrastructure in an organization. Particularly how to set up a shared cache so if one user builds something it is available to others?
      • elbear 6y ago
        Hey! At the end of your article you mentioned you're hiring. Are the positions remote? If yes, how can I get in touch?
        • burke 6y ago
          Yes, we’re hiring! You may have seen the news today that we’re all in on remote now. Send an email to burke.libbey@shopify.com, I’m as good a point of contact as any for Nix stuff.
• smabie 6y ago
  I have always wanted to try Nix, but not sure how installing software from source outside the package system works. With Arch Linux, it's pretty easy to create an AUR package if it doesn't exist, or simply install it outside the package system. Is it easy to create Nix packages (based on the features of Nix, I'm guessing no)? What about if you don't feel like creating a package?
  • burke 6y ago
    I think it's about as easy as creating AUR packages most of the time, especially after the first one or two. You can create them in a more ad-hoc way than you probably expect. For example, this video shows an example of creating a totally-legitimately-real package: https://www.youtube.com/watch?v=1nU_hR2kod4 https://www.youtube.com/watch?v=1nU_hR2kod4 -- some of the follow-ups in the channel also show a little more work with that simple derivation ("package" in de-nixified terms)
  • abathur 6y ago
    You can use Nix on your existing OS with no obligation to install all packages with it. On macOS, I use Nix for most things, but I still use homebrew for a few things and occasionally download+install.
  • roblabla 6y ago
    Creating nix packages is actually pretty easy once you get the hang of it. Maybe a tiny bit more involved than AUR packages since it's a new language and all, but it's not that much more difficult. When I was using nixos on my desktop machine, I made packages for my own personal tools, so it integrated in the system. It's also very easy to customize a package to suit your needs, and in fact makes for a very nice system to hack on open source projects. You can mostly setup an override in your $HOME to make a package's source come from your local disk, and when you install the package it will compile locally instead of getting a prebuilt binary. If you don't go through their packaging system... It's really easy to end up in a mess. There are ways to simulate a "normal" linux from within nixos, essentially making a chroot in which the various libraries are in their normal locations (achieved through an overlay filesystem). I believe that's what they do to run the Steam client. I assume (though never tried) you could use this to run other binaries without packaging. But then... what's the point?
• ninetax 6y ago
  We're doing a project right now to try to migrate to using nix for our python code that runs on a raspberry pi. It's been great in many areas, but pretty annoying when something doesn't work. You have to dig deep to fix errors. Of course we're trying to get numpy to cross compile from x86 to armv7 which involves cross compiling gfortran to get blas... so I guess a few bugs [1] are expected. Otherwise I've been really impressed. https://github.com/NixOS/nixpkgs/issues/88449 https://github.com/NixOS/nixpkgs/issues/88449
  • tomberek 6y ago
    Cross-compiling is finicky in any ecosystem, things like numpy especially so. When working on armv7 projects, I got a few TinkerBoards and ran the builds native. The first one took a while, but i just kept my binary cache up to date and normal CI/CD builds were fast. I'd also push core builds to https://arm.cachix.org https://arm.cachix.org. I haven't updated it recently, but I am considering doing that again.
• genr8 6y ago
  Stumbled upon NixOS yesterday and today its frontpage, 1st link. Same thing happened with OpenBSD the day before. Whats tomorrow, Qubes? I wonder what the chances of coincidence are if I investigate one new OS per day. https://www.foxypossibilities.com/2018/02/04/running-matrix-synapse-on-nixos/ https://www.foxypossibilities.com/2018/02/04/running-matrix-... https://en.wikipedia.org/wiki/NixOS https://en.wikipedia.org/wiki/NixOS
  • brianyu8 6y ago
    Post a link about it tomorrow and maybe your prediction will come true ;)
    • nemosaltat 6y ago
      Baader–Meinhof strikes again: >Once something has been noticed then every instance of that thing is noticed https://en.m.wikipedia.org/wiki/List_of_cognitive_biases#Frequency_illusion https://en.m.wikipedia.org/wiki/List_of_cognitive_biases#Fre...
  • Ericson2314 6y ago
    No tomorrow could be BSD and Nix https://github.com/NixOS/nixpkgs/pull/82131 https://github.com/NixOS/nixpkgs/pull/82131
    • takeda 6y ago
      Oh nice, thanks for doing the work.
• LockAndLol 6y ago
  This article suffers from the same problem every nix article I read suffers from: it dives in too deep from the get go. When you sit somebody down in front of a computer for the first time in their life, you're not going to explain what it is composed of, what happens in when your mouse button is clicked and why Windows vs Mac vs Linux is a thing. Please, first tell me what nix is, provide me with a few commands to get me started, make a few comparisons to what the audience should reasonably know, and then make this your second or even third article on the subject.
  • burke 6y ago
    That's kind of the approach I took in this playlist: https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4... However, there is really an important and subtle set of concepts to grasp in order to actually understand Nix, and not just mess around with a package manager tool incidentally built with it. It's fine to not understand them, but they are what this article tries to explain.
    • bradly 6y ago
      FWIW... I read this article as someone who doesn't know what Nix is. Like no idea at all besides the name sounding familiar. After reading the first few paragraphs I feel I'm not the target audience for the article, which it totally fine, but based on the title of the post, I assumed I was.
      • burke 6y ago
        Yeah, it was a last-minute title change that I now regret.
        • bradly 6y ago
          Yeah, that's tough :( On the bright side... sounds like the community (or at least me) would really be into another article as a primer.
    • 6y ago
• tomberek 6y ago
  Nix is a powerful package manager. I can confidently compile and run multiple incompatible versions of software simultaneously. I can build projects from years ago. I can package large projects from different ecosystems (python 2/3, c/c++, go, javascript) and be confident they will not interfere with each other. I can try bleeding edge software with no risk to it interfering with my system. It is faster and less hassle than juggling various Docker containers and VMs. It protects me from dependency hell. But overall: it makes me more productive. It is my secret weapon to manage the complexity of software development.
  • downerending 6y ago
    As an example, what's minimally required to run two different versions of program-x from the command line. Can I do something like this easily? cat-8.22 /etc/passwd | cat-8.3 -A
    • abathur 6y ago
      First: It depends on what you mean by "easily" General installs from Nixpkgs aren't going to be highly-idiomatic. You can install two different versions of coreutils, but one of them is still always going to be first on your PATH. So, if you want to specify the version in each command like this, you'll have to override the expressions to write a version number into the name of each binary. (But, yes, they're both on your PATH. If by "easily" you mean you could run `type -a` and pick the correct full path for each and then run them in a pipeline like this--yes.) I guess you could also build the path of each into an environment variable, or maybe create a wrapper for each with the version name included. Second: This is an awkward example because people rarely use multiple versions of coreutils concurrently, so there's just one version at a time in a current version of Nixpkgs. It'd be easy to put more than one python or ruby or postgresql in the same expression--things people are more likely to need (and thus multiple recent versions are all available at once)--but you'll (probably) have to work a little harder to do something like coreutils. (i.e., copy in a complete expression for each, or pull each version from two different commits in Nixpkgs. Nix makes it fairly simple to override an existing expression to change something like the version/commit used, but it breaks down if there are substantive changes in what's required to build them. Given the nearly 4 years between the early 2010 release of 8.3 and the late 2013 release of 8.22, I'd be surprised if they'll build with the same expression.
• magnusmorton 6y ago
  I feel someone should say something about guix here. I don’t have anything worth saying about either though
  • k__ 6y ago
    Nix and Guix are the next generation of package management. Nix is more idiosyncratic, since Guix usies S-expression syntax. Also, Guix is free software, with everything that entails.
  • ubadair 6y ago
    I spent a couple weeks casually studying about both, and finally hitched my wagon to Guix. The careful separation of free and non-free software is incredibly refreshing. I appreciate the emphasis on building packages from source. The docs are great and so is the Guile language. It didn't take me long to get a bootable USB with proprietary drivers and mainline kernel, even though I thought this would be much more difficult.
  • rixed 6y ago
    Anecdote about the subjective difference between using both: I've used nix and nixos on and off since the early versions, but it never really clicked with me, and every time I want to write or just read nix expressions I have to reread lots of documentation like I'm starting from scratch again, whereas I would probably still be able to write a debian package from memory alone despite many years of lack of practice. This leave me with the impression that nix has to be a full time job. In another hand, I gave guix a try recently and was really surprised by how easily all the pieces fell together "naturally". Also guix being a smaller community, it might counter intuitively be moving faster (due to less care for not breaking things or less bureaucracy, depending on your views). Indeed, another issue I have with nix is how jammed their input queue of PRs is.
    • bb010g 6y ago
      I'd say the PR quite is less bureaucracy and more a high number of packages with not enough hands to process them all.
• starpilot 6y ago
  Talks to the Raccoon server, I believe.
• austinl 6y ago
  We're using Nix where I work as well, and while I can say it was not the most user-friendly to set up, once we got it in place it has reliably worked for the last two years. We used to have a long and flaky shell script which set up the development environment for new engineers and CI machines (for iOS development on macOS, specifically). Now we have a very simple script which just installs nix and runs alls builds through the nix-shell. This makes builds on local machines and CI very easily reproducible. It also means that when dependencies change, we just update our nix config, and the new dependencies will automatically be fetched for all of our engineers and CI machines — no need to manually re-run the setup script. This is my favorite part of Nix — you can do `nix-shell --run "<some command>"`, and it will make sure you have all of the correct dependencies (downloading if necessary), then run the command with those exact dependencies. This is especially magical when engineers working on other platforms have conflicting dependencies — a problem we no longer need to worry about.
  • takeda 6y ago
    You can use Nix on MacOS X and with nix you don't need brew. I used it for few years that way. If you use nix-darwin + home-manager you can also configure your mac the way you would NixOS. Amazing tools that discovered not long ago (they aren't specific to os x) is: niv - makes pinning to specific repos/versions in repos much easier which helps with reproducibility, especially pinning of nixpkgs version which is now controlled in your source code. direnv + lorri - you no longer need to invoke nix-shell just cd the directory and all tooling you need for your project is suddenly available which is AWESOME. Here's an example of using them together with packaging a python project[1] if you have lorri and direnv installed and cd to the directory, not only you have the right python version installed but also all dependencies and even the "hello" command becomes available, as if you installed it through `pip -e .` [1] https://github.com/takeda/example_python_project https://github.com/takeda/example_python_project
    • fiddlerwoaroof 6y ago
      This is only sort of true: I’ve found that Nix on a Mac is great except that about 10% of the derivations just don’t work: some are excluded explicitly as broken and some just fail in strange ways and need lots of debugging.
• squid_demon 6y ago
  "All software exists in a graph of dependencies." And some of these graphs consist of a single node. Junk the jank!
  • Gaelan 6y ago
    I mean, if you count the compiler/interpreter (which nix does), realistically that's a bare minimum of two.
    • takeda 6y ago
      Nix comes with its own glibc, so that's 3, although I guess while it is not the default you could compile statically.
      • Gaelan 6y ago
        If you compile statically, you've got musl, which is still a (build-time) dependency.
        • takeda 6y ago
          There's a confusion between build and runtime dependencies. From Nix point of view. Even if you compile statically your code still depends on libc, it's just that you include the libc in the resulting binary. With Nix all dependencies are listed for your application. Because if no compiled version is available in binary cache, Nix will get a compiler and build one. This is actually awesome, imagine there's a program in nixpkgs that you want to use, but you want to have it linked with different libraries. For example pgbouncer[1] can be linked with different DNS resolvers, which have their strengths and weaknesses (currently it is linked with c-ares which probably is what most people want, but until version 1.10 that wasn't true) you can override the derivation and use different dependency. Nix will build on the fly the new version that does do what you want, and this is awesome. [1] https://www.pgbouncer.org/install.html https://www.pgbouncer.org/install.html
      • squid_demon 6y ago
• jariel 6y ago
  I loathe to be so critical, but I have no idea what this is. I'm sorry to say but this is a bad article - either that - or nix itself is a mishmash of things impossible to explain. I just see red flags everywhere. If it's 'A' - then maybe take some time to do a high-level introduction and some context. - 'Everything depends on something else' - really? Most 'installed software' doesn't depend on a whole lot else. Does the author really mean server software? Development environment? - "The easiest place to start is the Nix Store. Once you've installed Nix, you'll wind up with a directory at /nix/store," No! That's not easy, because what he&& is Nix, why and how would I install it, and what is the 'nix store'? Starting to explain something by introducing a whole bunch of other unknowns without description or context is going in the wrong direction. - "This directory, /nix/store, is a kind of Graph Database. Each entry (each file or directory directly under /nix/store) is a Node in that Graph Database, and the relationships between them constitute Edges." WHAT? We are now 3 layers deep in a rabbit hole of unexplained things. - " Nix guarantees that the contents of a Node doesn't change after it's been created." What is a Node? If the issue is 'B' - i.e. the inherent overlap of technologies that Nix makes it hard to explain ... well maybe it could be broken up. Take a minute to give some context for what Nix is, the kinds of people that use it, what problems it solves, and then have some exceedingly basic introductory examples so that people have a frame of reference for what you are talking about. Then you can step by step, go into the weeds.
  • tazjin 6y ago
    > Most 'installed software' doesn't depend on a whole lot else. Try this: Pick some random binaries on your system and run 'ldd' on them.
  • yakshaving_jgt 6y ago
    > - 'Everything depends on something else' - really? Yes. Really. > Most 'installed software' doesn't depend on a whole lot else. Yes it does. Your ignorance of this fact does not make this any less a fact. > Does the author really mean server software? Development environment? All of it.
    • jariel 6y ago
• whiddershins 6y ago
  I haven’t worked through the entire text but I absolutely love the manner of explaining. I often feel when I’m reading an explanation the author is reluctant to really break something down to the essentials and ELI5 ... which ironically can be conceptualized as the most intellectual way to understand something. Please explain it from as close to first principles as possible. Assume as little as possible. Maybe it is because the author thinks it is an intrinsically hard concept (as per the intro). Or maybe this person is just kinda awesome at explaining stuff.
• nilkn 6y ago
  This article is a good explanation of how nix works at a high level, and I'm excited to see nix getting some really prominent support, but for some reason it never tells you what the point of all of this is, so I think many folks might feel turned off by it. In other words, I don't believe it ever compellingly answers the question that constitutes its title. The word "package" doesn't even appear until near the end of the article! This is probably a second or third article to read about nix rather than the very first thing that exposes you to it. The point of nix is just to create completely reproducible builds and package management, including support for multiple versions of packages side-by-size with no issues. It's sort of a next-generation package management system that tries to avoid most of the pitfalls that OS package managers have fumbled with up to this point. It's really that simple. "nix" as a term refers to a system of multiple components that work together to achieve that goal. There's the package manager itself (called Nix), the language that build instructions are written in (also called Nix), an existing ecosystem of predefined packages (called nixpkgs), and an optional Linux distro that uses Nix the package manager as its package manager (called NixOS).
  • inetknght 6y ago
    So... statically compiled executables? Wasn't that tried long ago and it was determined that the user should be able to choose when to upgrade dependencies, such as if a dependency needs an out-of-band update to work on the localhost OS?
    • smilliken 6y ago
      Your criticism misses the mark because nix users have the ability to update a dependency and rebuild all of the dependees. With nix, I can update openssl in one place and be sure that everything that depends on it gets re-evaluated. How can I be confident that everything is linking the patched openssl I want when I'm using aptitude, pip, npm, docker, etc?
      • ComodoHacker 6y ago
        But what if they're using different versions of OpenSSL?
• dangoljames 6y ago
  Really it's kind of a minimalist linux distro with the capacity to coexist harmonically and/or parasitically with another operating system. Don't try to say 'oh it's like arch' or 'yeah it's a bit like Ubuntu', because no, it isn't, and by design. It seems that as much as design meant to go a particular way, there it went. It does pretty well directly on the hardware, but seems to want to live (like it is) in a container, though that might just be it's style ;) it certainly seems to be convenient for containers. It has a certain otaku appeal and ninjatsu stealth. I'll probably like it a lot some day soon but at the moment it just screams 'exotic' in my ears while I'm asleep at night. This probably isn't helping so I'll just stop now.
  • jchw 6y ago
    > It has a certain otaku appeal and ninjatsu stealth. I'll probably like it a lot some day soon but at the moment it just screams 'exotic' in my ears while I'm asleep at night. I’m trying to refute this characterization, but I am sitting in front of my desktop with an anime background in SwayWM on NixOS. Is there something I don’t know about correlations between seemingly unrelated hobbies?
    • eeh 6y ago
      NixOS, Emacs, Haskell, tiling window managers. They're a clique in the tech world. I think a unifying theme is to have a small foundation that the user can develop within. Going a bit further on my soapbox, you might also be into philosophy, anime, election reform, baduk, and math. Is the underlying personality trait systemizing/stubbornness, wanting to break everything down, and rebuild it according to defined principles? http://dreamsongs.com/RiseOfWorseIsBetter.html http://dreamsongs.com/RiseOfWorseIsBetter.html would call this approach the MIT style of design. @nntaleb might suggest they overestimate their principles and their ability to enact their principles, and call them IYIs. :) (This comment itself is my admission of being an IYI.)
• johndoe42377 6y ago
  A messy pile of unnecessary, redundant abstractions which "solves" nonexistent problem. Stable interfaces (the main principle behind literally everything in nature) and semantic versioning will do the job. systemd-like cancer. And, of course, look, ma, I am so smart.
• nana- 6y ago
  What is nix?
  • yakshaving_jgt 6y ago
    Read the article and you might find out.
    • aidenn0 6y ago
      Probably not.
• dtrailin 6y ago
  This sounds similar to BuildXL[1] (originally called Domino) which Microsoft uses to build Windows has been in use 6 years. It does this sandboxing using Detours on Windows which intercepts system calls and allows you to described packages in a language called DScript. I think you need something like this if you don't use a system like Bazel that keeps build dependencies well isolated. Even then the system you use can leak into the build. 1. https://github.com/microsoft/BuildXL https://github.com/microsoft/BuildXL
• alphachloride 6y ago
  After reading the article, I am still asking the same question: What is Nix? Edit: from their website https://nixos.org/ https://nixos.org/: > Nix is a powerful package manager for Linux and other Unix systems that makes package management reliable and reproducible. It provides atomic upgrades and rollbacks, side-by-side installation of multiple versions of a package, multi-user package management and easy setup of build environments.
• bsima 6y ago
  A lot of misunderstanding and overexplaining in these comments. The reality is that Nix is a complex system of many parts, under active development, and yet is perhaps the best infrastructure we have for creating deterministic, hermetic, reproducible builds. I've worked on one of the largest Nix systems and it saves our entire dev team hours. Everything is only built once, on a large set of specialized remote builders, then shared among all of our devs, CI, and deployment infrastructure. Perhaps this is common in FAANG, but Nix enables this even for small teams and individual developers. If thats something you would like to learn more about but are having trouble getting started, I'm happy to help. Email is in my bio. We could setup a call or chat session or whatever.
  • takeda 6y ago
    This is what I'm personally looking for, are there some kind of tutorials how to configure nix in an organization to do CI/CD best practices etc.
• yachtman 6y ago
  A company I worked at embraced nix. Beforehand I was a big docker fan and had few issues with it (yes there were occasionally caching issues and damn it docker figure out the issue with hyperkit on mac os, but largely its a productive tool). From an outside perspective nix just felt like alot more work, and nearly no one (except the people that set it up) could ever get it to work. So basically the entire build process for the core of the system was something that literally no one in the company wanted to touch. I'm sure if I was an insider on the tool I would appreciate the added stability you get on the backend, but at face value it seemed like it just made builds unapproachable on the front end. I'm happily back to using docker and haven't looked back.
  • takeda 6y ago
    Out of curiosity, any reason why you didn't want to understand it? You spent time learning docker, why this was different?
• steve76 6y ago
  Revenge for Watergate. YOU ... ... ... NIX! Get it?
• phissenschaft 6y ago
  Wondering if folks would prefer spack (https://spack.io/ https://spack.io/) given its heavy adoption in the HPC community.
• juskrey 6y ago
  For me nix(OS) began from much simpler upside: now I never forget that handmade one line tweak somewhere out there - all Linux system goes in one nice config.
• zelly 6y ago
  I like the idea of Nix. It's definitely the future of package management and build systems. But it's solving a problem we knew how to solve in the 80s: dependency hell is solved by statically linking everything. In fact in the Windows world it's still like this. If you need OpenSSL, for example, it should be in your source tree and compiled in the same build pipeline as your application.
  • casept 6y ago
    Static linking is unfortunately broken for many projects though, primarily because every C/C++ dependency has a slightly different incantation to make it work. It also doesn't address the problem of languages which expect dependencies to be files on the filesystem, like python or ruby.
• sandGorgon 6y ago
  is there still relevance for this way of building in the world of Docker - especially with Packer and LinuxKit ? Packer allows us to create highly repeatable OS builds with all the right configuration and packaging. For example, this is AWS official Packer build for their EKS AMIs - https://github.com/awslabs/amazon-eks-ami https://github.com/awslabs/amazon-eks-ami
  • casept 6y ago
    Docker kind of sucks for development though, because you need to reinstall all your devtools into the container and have to wire up your IDE to support docker. With nix, you just write a shell.nix, run nix-shell and can then use your regular tools in that environment. Also, nix builds are far more reproducible than packer builds. With nix, you get an environment that is guaranteed to be identical down to the hash of every single file as long as you use the same version of nixpkgs. Packer and similar imperative tools typically install whatever version is the latest in the distro repo, and building the image 2 months apart will grant you different artifacts without investing a lot of effort into pinning everything.
• voppe 6y ago
  The only takeaway I get from this article is... Why is Nix? And from skimming along the comments, both on HN and on Disqus, there's a lot of confused people trying to understand/describe the difference between Nix and Docker, because although the article described how Nix works in a very technical way, it didn't explain what it can be actually used for.
  • rcxdude 6y ago
    It's a package manager written in such a way as to properly solve the problems with existing package managers which docker patches over. It uses deterministic builds and careful isolation of dependencies to ensure that the environment it creates is the same each time, and that you can have packages which depend on conflicting versions of another package installed at the same time. The entire OS is accurately described by a config file, and this can be reproduced exactly using just that file. In contrast to traditional package managers: handles conflicting dependencies, state is tracked through editing the config file, not a serial of install/uninstall commands which mutate the state of the system. Config files of installed packages are also controlled through nix config. In constrast to docker: properly reproducable (Docker will re-run the same commands in the Dockerfile, but there's no guarantee you'll get the same result. For example, basically any package installation from a traditional package manager you run in the Dockerfile will not reproduce when run later because newer versions of packages will be installed), also more efficient in terms of space usage. However, AFAIK it does not namespace networking and so on (nixOS has its own containers system which does do this however).
  • Shoue 6y ago
    Here are my favourite use-cases: * automatically installing all project libraries and dependencies so you can build your project without having to apt install a bunch of stuff first. This is done through direnv/lorri, so when you cd into the project directory, direnv uses nix to install everything automatically. Very quick onboarding and also no need to keep up with the various company projects' deps. * building docker images with intentional layering so deltas remain small is a breeze: buildLayeredImage. * with home-manager I can ensure my dotfiles have all their dependencies so vim plugins and whatnot just work. It also means I get the same nice home environment on _any_ Linux distro I choose. * Same as above except for my entire system with NixOS. * Shipping packages with specific config defaults _only_ for your project directory so you don't have to worry about making everyone configure something is also a breeze with Nix package overlays and overrides. * You can even have Nix modules for your VPN connection and the like so co-workers can import that into their home-manager or NixOS configuration, and if it changes so does your system/home config next time you build it.
• cerved 6y ago
  I don't understand what problem it solves
• Tomte 6y ago
  Is Nix only handling the build part (with configure flags etc.) or is it also used to configure services, for example? I'm not versed in devops/provisioning etc., but say, I had a NixOS system with some server software (mail server, DNS server, whatever). Would I still want to use Chef/Puppet/Ansible, or is that included in the Nix ecosystem?
  • casept 6y ago
    NixOS exposes config options as variables you can set in your configuration.nix file. Also, external config management tools generally interact poorly with nixOS, because they assume a system which is managed imperatively.
  • myguidingstar 6y ago
    yes, it's included. Nix config files will automatically generate and run services. There's also Nixops which is a tool to push these config to remote machines ie cloud vms.
• seddona 6y ago
  We use Nix for all our developer tooling at CircuitHub. It's not the easiest thing to get into - but once you do - it solves so many problems! Great to see a large company like Shopify get in on this.
• diegobernardes 6y ago
  Too bad that Nix don't work with fish shell
  • Shoue 6y ago
    I'm using Nix and Fish and have been for a year or two now. I remember some issues initially but NixOS and home-manager have boolean options to enable Fish and it Just Works nowadays.
• ajb 6y ago
  I really wish nix was the solution, but I'm not sure it is. I currently don't install anything on my base system, but do it via docker. Looking through my dockerfiles, currently I have stuff installed via: * apt * apt preceded by apt-key add * wget/curl * pip & pip3 * git clone * go get * npm install * snap And that's even though I try to avoid esoteric package managers as much as possible. (For example, there was some package recently where the recommended method was brew for linux, and another that wanted to be installed via conda. There's just so much stuff out there that insists on using some random packaging system. docker, even though it's a bit flaky, abstracts that away.
  • myguidingstar 6y ago
    nix is the solution. It's totally different from any random packager you've seen. It goes the reversed direction of abstracting dependencies away: it makes dependencies explicit (and reproducible!)
    • ajb 6y ago
      I get it, but my point is that unless it can cope with packages that aren't in the ecosystem, it will just add another variant rather than solving the problem, as per https://xkcd.com/927/ https://xkcd.com/927/ It reminds me a lot of http://www.vestasys.org/ http://www.vestasys.org/
      • Ericson2314 6y ago
        Nix at this point is almost 20 years old, and we have 10,000s of packages. If that meme wants you to blame something, it should be Docker. (First of all, it's younger. There's big tons of effort with Docker and yet nothing is reproducible, and DPKG, APT and all their ilk can't even be deprecated but instead are used awkwardly within the Docker ecosystem.)
• edbentley 6y ago
  Hearing about Nix couldn’t have come at a better time. Having just got a new Mac, seems like the perfect time to try a fresh Nix-only setup.
  • myguidingstar 6y ago
    from now on every new machines will be easily replicated with configs from older machines: copy the config file over, type one command and let nix does the rest
• sigrlami 6y ago
  Nix is a cool ecosystem but getting builds quite expensive on conventional CI/CD system. One can reduce costs by running custom Hydra CI instance but I would love it to be a bit better. Working with private stuff is a mess and requires deep knowledge of the system, hard for newcomers to pick up. Also, NixOps super cool extension to manage a fleet of instances.
• temptemptemp111 6y ago
  Darch > NixOS
• aabbcc1241 6y ago
  It looks similar to "npm with ipfs/docker (layer-fs)". My initial guess is it may use more disk space like snap. Because it requires exact version of dependency. Unlike in npm/pnpm that access wide range of dependency version as long as it satisfy the server version.
• 1MachineElf 6y ago
  Nix seems wonderful, but I have one question: If nixos.org and github.com disappeared tomorrow, are users sufficiently enabled to keep the project going, or are those two single points of failure?