17 ms·

What is Nix and why you should try it

461 points by vletrmx 9y ago

bfrog 9y ago
Nix is pretty cool but has some significant usability issues.
- philipov 9y ago
  Having never used Nix before, I would like to know what kind of usability issues it faces. For me, the biggest one is that I can't use it at clients running a Windows shop. That's a blocker.
  - nextos 9y ago
    I think biggest ones are i) nix command is a bit complex, but it's getting redesigned [1] & ii) nixpkg definitions sometimes contain a lot of cruft. I've found Guix and GuixSD, which are a GNU-blessed Guile Scheme-based reimplementation of Nix and NixOS, more aesthetically pleasing. Quite simple and elegant in fact. The major differences are that Guix DSLs are implemented on top of Scheme, whereas Nix uses a custom DSL. Furthermore, Guix avoids systemd and uses GNU herd instead. [1] https://github.com/NixOS/nix/issues/779 https://github.com/NixOS/nix/issues/779
    - jitl 9y ago
      Guix uses it’s own init system implemented in Scheme: Sheperd (https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/shepherd/) Herd/Hurd is a kernel, not an init system, although since systemd is Linux only, using a different kernel implies using a non-systemd init system.
      - agumonkey 9y ago
        Shepherd is not a kernel, Hurd is, and shepherd page mentions a relation, that dmd/shepherd was developped closely to Hurd but it not the same thing.
        nextos 9y ago
        Sure, I wrote herd not Hurd! herd is the commandname of Shepherd client: https://www.gnu.org/software/shepherd/manual/shepherd.html https://www.gnu.org/software/shepherd/manual/shepherd.html
        jitl 9y ago
        Ah — confusing as Herd is the second recursive acronym of Hurd... sorry to pedantic :-)
      - xelxebar 9y ago
        Nitpick---but while we're here---Hurd technically refers to the set of (microkernel) servers. The microkernel itself is Mach. In spirit, Mach and the Hurd servers together provide what the Linux kernel provides monolithically. Anyway... :)
    - gcoda 9y ago
      For my practical reasons I can not use pure GNU distributions, I am not aware of easy community way to re use packages for other distro or something hacky like that. Not everyone have brainpower and time to build custom packages for rare distro, it is a shame, I really like Guix. NixOS got some recepies for using not 100% libre software.
      - nextos 9y ago
        There are repos around packaging tons of non-free (mainly scientific) software for Guix.
      - tilpner 9y ago
        I was told guix has some support for importing normal Nix packages, but I don't know how well it works in practice. https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-import.html https://www.gnu.org/software/guix/manual/html_node/Invoking-...
      - jitl 9y ago
        This is also what keeps me away from Guix. I get that there are third-party repos with non-free software, but using a fringe package of a fringe packager is too far for me. There’s no good choice here: Nix package definitions and tools are inscrutable and user-hostile; and the alternative Guix is burden with GNU/free software zealotry and GPL. A somewhat comparable third option is Habitat, from Chef. It also has a pure build system, a package source, and pure, discrete environments. But it’s also got a bunch of service orchestration parts... Hopefully the Nix redesign will make the tools more palatable for mortals.
        nextos 9y ago
        What kind of non-free tools are you missing from Guix? The only notable omission is linux, as Guix is based on linux-libre instead. But changing this is a matter of 1 LOC.
        thomastjeffery 9y ago
        > But changing this is a matter of 1 LOC. And how difficult is it for a new user to find that line?
    - pmoriarty 9y ago
      One of the major turn-offs for me in regards to Nix was that it uses a ton of bash scripts. Guix's use of Scheme is a lot more elegant and powerful, and a lot less hacky than bash.
      - sly010 9y ago
        You could use nix the same way guix uses scheme. The lowest level operation in nix is not "run-this-bash-script" but "run- this-executable-with-these-arguments".
        davexunit 9y ago
        But even still you are mixing languages, so the problem remains. The issue is not that Nix uses Bash, but that Nix uses different languages for the host-side and build-side. AFAIK people aren't writing the build-side code in the Nix language, and I'm not sure if it even has the features necessary to do it. Guix unifies the different layers of code execution with a single language, and using a Lisp enabled that design. For a complete explanation of this design, see the "Code Staging in GNU Guix" paper: https://arxiv.org/abs/1709.00833 https://arxiv.org/abs/1709.00833
        thomastjeffery 9y ago
        > Nix uses different languages for the host-side and build-side. I'm not sure what you mean by that. Nix packages are Nix expressions.
        davexunit 9y ago
        Those package expressions have Bash snippets embedded in them that run on the build daemon. The daemon doesn't evaluate Nix code.
        thomastjeffery 9y ago
        How is that a problem?
    - k__ 9y ago
      When will the redesign be merged? It's over a year that I first read about Nix and they talked about the redesign.
      - grhmc 9y ago
        The redesign is merged and available via `nix-shell -p nixUnstable`. It isn't so much an issue of merging, but calling the new version stable. We're working on it. No definite timetable though.
        k__ 9y ago
        Ah, cool! Are there docs for the usage after "nix-shell -p nixUnstable"?
  - bfrog 9y ago
    Primarily from my perspective... the entire package repo acts as one enormous program. Which is both good and bad. Its not that easy imo to create ad hoc packages or packaging scripts
    - taktoa 9y ago
      I strongly disagree. Creating a Nix package is significantly easier than creating, e.g.: an Arch package, from my experience. packageOverrides is really nice too.
      - bfrog 9y ago
        Try packaging a postgres extension :-)
        taktoa 9y ago
        If you tell me which specific piece of software you tried to package, I can probably explain what is going on. I strongly suspect that it is either not Nix's fault, or an inherent tradeoff in packaging software (i.e.: not a design flaw, but simply a result of the correctness of package expressions being more tightly controlled in Nix than in other languages). The main exception to that statement that I've seen are cases where Nix works fine, but the Nix expression takes so long to build that iterating on it is very difficult. Luckily, there is a solution for that in the pipeline: "recursive Nix", which allows `nix-build` to be called _inside_ a Nix build sandbox, thus allowing safe memoization of things like `gcc`.
        ben0x539 9y ago
        What's the status of recursive nix / people's thinking about recursive nix?
  - zzzcpan 9y ago
    Discoverability is a problem everywhere in Nix, from configuration options to documentation. Which makes it necessary to learn its weird poorly implemented functional programming language and read code. Then there is performance, it's very slow and uses a lot of memory making it impossible to use on a 512 MB vm, for example. If you just want a solution for your packaging management needs - Nix is definitely not it. Nix is more like a thing to get inspired by to make a package manager.
    - philipov 9y ago
      That's nice to hear you say, because I am making a package manager, and I find nix inspiring :p I keep trying to convince myself that someone's already done it better, and there's no point, but then every solution I look at doesn't seem to be good enough.
      - jitl 9y ago
        Agreed, it’s an area where nothing is quite there. Take a look at Habitat - another not quite there option, but one with interesting ideas.
        philipov 9y ago
        What's the downside of Habitat?
        jitl 9y ago
        I don’t know anyone using it.
    - taktoa 9y ago
      > Then there is performance, it's very slow and uses a lot of memory making it impossible to use on a 512 MB vm, for example. No, this is just a side effect of the CLI user experience being garbage. `nix-env -i <regex>` is almost never what you want, because its semantics are to evaluate everything in nixpkgs, find the set of packages whose `name` attribute is matched by the given regex, and install all of the packages in that set modulo the equivalence relation generated by package `name` equality ignoring version numbers. Instead, you should use `nix-env -iA <channel>.<attribute-path>`, where `<channel>` is the name of a Nix channel (viewable via `nix-channel --list`, usually it is `nixos` or `nixpkgs`) and `<attribute-path>` is a valid attribute path in the nixpkgs package set (these can be discovered by running `nix-repl '<nixpkgs>'` and tab-completing).
  - mkl 9y ago
    It apparently works in WSL [1], so Windows needn't be an issue. [1] https://www.reddit.com/r/NixOS/comments/64xyd7/nix_package_manager_works_flawlessly_in_windows/ https://www.reddit.com/r/NixOS/comments/64xyd7/nix_package_m...
    - philipov 9y ago
      Do you use Windows 10 Creators Update on production? It needs to work on Windows Server 2012 or no dice. Maybe Nix will be an option in 5 years when companies upgrade their servers, but that's not an option now.
      - jitl 9y ago
        You could say the same thing about Windows: Windows just isn’t an option yet.... maybe in 5 years when WSL is performant and MSFT has open-sourced enough to not be a threat to more cautious companies.
        philipov 9y ago
        No, I don't think you can say that. The point is that I have clients that use linux, clients that use windows, and clients that use both windows and linux which need to talk to each other. I need a solution that can factor out the operating system into a module and build packages that will work for both the quants and the servers. I don't get to tell my clients what operating systems to use. I must provide solutions that work on whatever they're running.
        danharaj 9y ago
        Nix has facilities for creating Docker and Singularity containers from a nix expression, which lets you package up arbitrary environments. Does that satisfy your use-case? https://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools https://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools
- oconnore 9y ago
  * is pretty cool but has some issues.
jingwen 9y ago
On my macOS work machine, Nix has replaced Homebrew. The ability to switch between generations of your system state [1] when a new install goes awry is underrated, IMO. [1] https://nixos.org/nix/manual/#sec-profiles https://nixos.org/nix/manual/#sec-profiles
- pfranz 9y ago
  I really think the biggest roadblock is the command line interface[1]. To replace Homebrew you only need like 3 or 4 commands. Right now, that means 3 or 4 different nix commands with weird arguments. The way Nix is currently set up is great and make sense for the OS, but Homebrew has a much simpler use-case (single-user, all user land packages, very low barrier to entry). I can't wait until that ticket is addressed. [1] https://github.com/NixOS/nix/issues/779 https://github.com/NixOS/nix/issues/779
- j_s 9y ago
  Why not both? Does Homebrew conflict with Nix in such a way that only one is possible at a time? I can definitely see giving Nix priority for work-related development, but I would like to know if Homebrew can still fill in as a backup option.
  - pfranz 9y ago
    I've installed both without issue. It might be a headache long-term because of libs and installing things in both systems, etc. Just make sure you know which comes first in PATH.
distantsounds 9y ago
Gobolinux does something similar, and has been around for years: https://www.gobolinux.org/ https://www.gobolinux.org/
- taktoa 9y ago
  It "does something similar" in the sense that it doesn't obey the FHS. NixOS is otherwise a pretty radically different approach AFAIK.
- infinisil 9y ago
  Funnily enough, NixOS has had its initial release in the same year as Gobolinux, 2003. I'm not sure how Gobolinux organizes files exactly, but with NixOS, the hash in /nix/store/<hash>-packagename is produced by combining every input that might influence the package. By input I mean for example: - The source: git revision / source url / etc. - All dependencies, which means if a dependency of a dependency of this package changes, it gets a new hash - Build instructions, including build flags This wouldn't be possible with a more conventional file structure.
jf 9y ago
I'm very excited about Nix and the possibilities that it opens. If you want to learn more about Nix, I suggest starting with this excellent article on InfoQ: https://www.infoq.com/articles/configuration-management-with-nix https://www.infoq.com/articles/configuration-management-with... I also gave a talk about why I think Nix is so great: https://vimeo.com/album/4676161/video/223525975 https://vimeo.com/album/4676161/video/223525975 Finally, I highly recommend the PhD thesis that Nix is based on: https://nixos.org/~eelco/pubs/phd-thesis.pdf https://nixos.org/~eelco/pubs/phd-thesis.pdf
Jeaye 9y ago
I recently wrote about my experience using NixOS on my VPS [1]; it's truly a very different way of approaching systems administration and Nix is at the heart of it. While I think the Nix expression language has a negative impact on usability, Nix still ends up being a net gain for not only entire OSs, but also reproducible environments for packages on many other OSs. 1: https://blog.jeaye.com/2017/07/30/nixos-revisited/ https://blog.jeaye.com/2017/07/30/nixos-revisited/
- afarrell 9y ago
  Oooh! Thanks for linking this write-up. I've been thinking of playing around with Nix and basically only be able to do it on a VPS. Before I get started though, what things could I consider implicit prerequisites of running Nix? For example: I've never built a Debian or RPM package. Would I be better served gaining some background in OS package management before diving into this?
  - Filligree 9y ago
    Most of what you'd learn playing with other OSs, you'd need to unlrearn to work with Nix. So... nothing much really. Read the Nix Pills series, that'll teach you more than any amount of playing with non-Nix software.
    - afarrell 9y ago
      Thanks! https://nixos.org/nixos/nix-pills/ https://nixos.org/nixos/nix-pills/ for others
  - jitl 9y ago
    No: each package manager had its own strange rules and concepts. I’ve worked with deb packaging, and I wouldn’t say that experience transferred to working on Homebrew or Nix. You might as well start with what you want to use.
    - afarrell 9y ago
      This is good to know, though I continue to be sad that there isn't a general "design principles of package managers" knowledgebase.
zzzeek 9y ago
"To deal with this nix provides the nix-shell utility which constructs an environment on demand and runs a new shell based on that environment." I'm sure nix is cool but this sort of sounds like something we just end up using docker for these days (for better or worse).
- zzzcpan 9y ago
  Yes, Docker is a competing solution. Hopefully in the future we will see a better one, more nix-like.
  - Crespyl 9y ago
    Does Docker actually compete with Nix? It seems that Docker is more concerned with containment and Nix with packages. I would love to be able to use Nix to define my project+dependencies and Docker to run it. I'd be surprised if someone hasn't already made a baseline NixOS docker image to build off of.
ldlework 9y ago
I have recently started looking into Nix to solve the problem of dotfile deployment to new OSX workstations. When you get a new laptop, you clone your dotfiles, maybe symlink them to your home directory -- and then what? Nix solves this problem for me by coupling my dotfile deployment with the installation of the related software. The learning curve has been absolutely tremendous, however. That said, the support on Freenode has been some of the best I've encountered in more than a decade. https://nixos.org/nix/manual/#chap-package-management https://nixos.org/nix/manual/#chap-package-management https://rycee.net/posts/2017-07-02-manage-your-home-with-nix.html https://rycee.net/posts/2017-07-02-manage-your-home-with-nix...
- k__ 9y ago
  Nice. I started using macOS 5 months ago and it felt a bit as a step back coming from Linux. Does Nix work good with macOS?
  - jitl 9y ago
    Yep
  - kccqzy 9y ago
    I should mention that on High Sierra there’s a bug with kill(-1, ...) that sometimes causes Nix builds to lock up the whole system.
    - wmertens 9y ago
      Also, the OS X windowmanager has a memory leak and you have to resart every so often. Yesterday mine was 22GB and after restart <100MB… Nothing to do with Nix, just venting ;-)
      - tejasmanohar 9y ago
        you have to restart every so often I've never had that happen. Maybe things that don't have to do with Nix... really just don't have to do with Nix ;-)
amelius 9y ago
Python solves this problem with "virtualenv", where the user creates a virtual environment and installs all programs and libraries into that environment. The user can have multiple virtual environments, and it is easy to switch between environments.
- e12e 9y ago
  Up to a point. You can't install the c (etc) compiler in the venv, so you end up with some dependencies on the external system.
- pfranz 9y ago
  virtualenv solves virtual environment as much as pip solves OS package management. Not that it's not useful, but you see all over where you have little fiefdoms that work pretty well for their little ecosystem, but become a mess if you integrate stuff outside (virtualenv, rbenv or pip, npm, gem, rpm, apt or make, ant, scons, jam). A lot of these systems are just reimplementations tailored to language-X. Nix is pretty unique and clever. For example, you can effectively version control you virtual environment, it's at the OS level, and accommodates major languages and libraries (Python, Perl, Lua, Java, Go, Qt).
  - deleted 9y ago
    [deleted]
- philipov 9y ago
  venv doesn't even handle environment variables. Some environment that is :p
- davexunit 9y ago
  Every language has it's equivalent of virtualenv, and that's the problem: it only works for that language's tools and libraries. I don't use Nix, but I do hack on an alternative called GNU Guix sometimes, and I wrote a tool called 'guix environment' which is similar to virtualenv but applicable to any software. Having a generalized solution is much better than one virtualenv tool and package manager per programming language. In Nix the equivalent tool is called nix-shell.
dhruvio 9y ago
I can vouch for the immense improvement Nix has made to my software development process. I use NixOS on my desktop and laptop. At the OS-level, it gets a lot of things right: reproducible, immutable system configs; lightweight containers; devops with declarative configs. At a software project level, nix-shell is an indispensible tool. Compilers and interpreters aren't even part of my system-wide config; instead each project has it's own shell.nix file that installs all dependencies I need on the fly without polluting system state or virtualization. Nix is a god-send, and the developers that contribute to it are nothing short of awesome! The area that needs improvement is the documentation. Once you learn the Nix language, reading the source code is pretty helpful, but it would be nice to make it more approachable. For example, the nixpkgs repo has a bunch of Nix helper functions that are useful to developers when writing their own packages, but these functions' documentation is either buried in a long manual, or non-existent.
- vog 9y ago
  Naive question: Isn't all that also true for Guix? If so, why do your prefer Nix over Guix?
  - ben0x539 9y ago
    Why shouldn't one prefer the original over some rando's weakly motivated, niche NIH rehash, unless you're already victim to lisp-induced Stockholm syndrome?
    - roblabla 9y ago
      > some rando's This is a GNU-approved fork > weakly motivated Has lots of strong motivation, like a stricter stance on non-free software, the usage of a "real", more expressive language (Guile) instead of a niche, poorly undocumented DSL (Nix), use of GNU Shepherd instead of SystemD for the init system, among other > niche NIH rehash It shares most of the codebase with Nix, so to say it's NIH is missing the point. Nix improvements are shared with Guix, and Guix improvements are shared with Nix > unless you're already victim to lisp-induced stockholm syndrome Different lisp offer different syntaxes, features, and use-cases. That you cannot see it makes me think you didn't try too much, and are probably just trolling.
c3534l 9y ago
I'm gonna need a better reason to switch distros than that. I do think that is an improvement that needs to be adopted in the OS. But, I mean, it's not that much of a improvement over containers. I don't feel like it gives me, the user, that much more power over the OS and would be a feature that I would only use very rarely.
- infinisil 9y ago
  The blogpost just highlights one nice aspect of it, there's more though: - The really powerful NixOS module system, which let's you specify your system declaratively and rather simply: Which programs should be installed, what systemd services should run, use grub for booting, allow this ssh key to login to this user, enable the IPFS daemon, etc. All options (for the 17.09 release) are available here: https://nixos.org/nixos/options.html https://nixos.org/nixos/options.html - System generations: Upon changing an option in your system config, you run `nixos-rebuild switch` which will build, activate the new system and add it to the system generations. All of these are bootable from your bootloader! So if something breaks miserably, you can just rollback to a previous one that worked. New kernel breaks on your hardware? No problem, just roll back. - If you have a new nixos machine, you don't need to run a bunch of odd commands to have it set up. Since the config is declarative, everything you set up is right there, and all you need is a `nixos-rebuild switch` to make it work. - Wanna test some configuration but are too afraid to use your machine? Just build a VM with it by doing `nixos-rebuild build-vm`. Like with everything else with nix, this fetches all dependencies, no need to install them manually.
- throwaway34832 9y ago
  Have you tried Habitat.sh yet? I has similar goals to NixOS without needing to give up the OS of your choice.
- pfranz 9y ago
  Well, you don't have to use NixOS, you can just use NixPkgs either as a way to familiarize yourself or to manage a project--personally, I'm hoping after a few things get fixed I can replace Homebrew with it. Even though containers have had a lot of buzz and tooling built around them in the past few years, it's good to see how other approaches can solve similar problems with different pros and cons.
rhn_mk1 9y ago
My experience with Nix was a real pleasure, and a complete failure. I set out with the goal of building a development environment for a software I was working on. I thought - Nix sounds like a better Docker, where it's possible to choose package versions independently of the rest of the system. It's perfect for testing! I found the package description language refreshing - it was powerful without getting too complicated. Over the course of a couple of days I was able to adapt a few packages and create my own too, with the build environment. It was almost finished, but the last problem remained: installing CUDA and the userspace portion of the Nvidia driver. It's not rocket science – I thought – all I need is a few .so's, it even works with Docker. Alas, after battling Nix for another couple of days, trying to use generic GL, installing the Nvidia one, ignoring it altogether or trying to using the host version - I gave up. I found no way to build a package linked against OpenGL that would actually work. Despite that, I hope to use Nix with a different project in the future.
- nh2 9y ago
  Here are some links that might help you to get OpenGL work with nix programs on non-NixOS machines: * https://github.com/NixOS/nixpkgs/issues/9415#issuecomment-309249312 https://github.com/NixOS/nixpkgs/issues/9415#issuecomment-30... * https://github.com/guibou/nixGL https://github.com/guibou/nixGL * https://github.com/deepfire/nix-install-vendor-gl https://github.com/deepfire/nix-install-vendor-gl
- ris 9y ago
  Although other people have different opinions to me, I don't really see Nix as something for the desktop, but for development, deployment and server software it's a killer solution for me.
  - Filligree 9y ago
    None of what he mentioned was desktop-specific. GPUs are useful, and if CUDA is involved then it's being used for acceleration of some kind, which can perfectly well be done on servers. I agree that Nix is hard to deal with when it comes to binary distributions of any kind, which includes CUDA.
pradeepchhetri 9y ago
Recently, I got the opportunity to play with Nix. To me, it felt to be a very nice way to bundle the dependencies along with the application. But there are few questions which always come to my mind were - how people run it in production. Can they achieve all the things (eg monitoring, debugging..) easily just like the app hosted on a linux machine ?
- jitl 9y ago
  Sure? It’s still Linux underneath and all the same skills and strategies carry over.
  - pradeepchhetri 9y ago
    Thank you, I definitely need to play with it more to understand it better.
hyperion2010 9y ago
Sounds like a similar solution to gentoo's slotted ebuilds [0]. Switching the 'default' implementation system wide or per user (eselect) has the same issues discussed. Not sure if there is an existing utility (beyond your standard shell script) that can produce sane per-shell environments. 0. https://devmanual.gentoo.org/general-concepts/slotting/index.html https://devmanual.gentoo.org/general-concepts/slotting/index...
- ben0x539 9y ago
  Mhm, doesn't sound all that similar to me. This looks like something that needs to be maintained on a per-package basis as a fairly ad-hoc solution for different library versions, in Nix the whole thing just falls out of the way it's set up in general.
SideburnsOfDoom 9y ago
That article on "What is Nix and .. " does not contain the words "Nix is a..." A quick read gave a vague sense that it was about installs and file paths so maybe something package-related? Nothing definite. If you click through to https://nixos.org/nixos/nix-pills/why-you-should-give-it-a-try.html https://nixos.org/nixos/nix-pills/why-you-should-give-it-a-t... you will see "Nix is a purely functional package manager and deployment system for POSIX"
- vletrmx 9y ago
  Yes I recommend the nix pills they are really awesome and how I learned Nix!
  - samstave 9y ago
    Links?
    - vletrmx 9y ago
      https://nixos.org/nixos/nix-pills/ https://nixos.org/nixos/nix-pills/
- sundarurfriend 9y ago
  I get the feel that Nix does something like what virtualenv does for python, but more generalized to make that work for other software. Is that approximately right?
  - aws_ls 9y ago
    Yes, I also was immediately reminded of Python's conda based environment management. E.g. 'source activate <env1>' may have python3 but when used with <env2> will use python2 and different version of other libraries.
georgewsinger 9y ago
We used Nix to vastly simplify the build process of Simula: https://github.com/SimulaVR/Simula https://github.com/SimulaVR/Simula Simula is a bleeding edge VR Desktop project for Linux; virtually all of its dependencies are highly novel and require building from source for almost any distro. Nix allowed us to reduce the effort to building our project from 1hr of sifting through build documentation to a single build command. Nix's only issue is that it so far can't handle OpenGL dependencies very well. I'm not sure if this is something in principle it cannot handle, or if it just hasn't been done yet. I'm praying it's the latter.
- joepie91_ 9y ago
  So, OpenGL is a bit of a weird case. Hardware is the one thing that actually varies between systems no matter how declarative your configuration is - this is normally not a problem, since the kernel abstracts it away. The problem with OpenGL, then, is that every graphics driver provides its own set of OpenGL libraries that is subtly different from all the others. This means that applications need to be built against a specific set of OpenGL libraries from a specific graphics driver, and the kernel is of no help here. That's fundamentally where the OpenGL issues come from; Nix packages typically expect the libraries to be semi-statefully provided in a `/run` directory. This gets especially hairy when targeting different distros. EDIT: And because the package doesn't know what graphics drivers it'll be running against on non-NixOS, it can't automatically build against a copy of the correct drivers in nixpkgs either.
  - georgewsinger 9y ago
    I agree that, given this description, it's a hard problem. But can Nix find a way to abstract away these difficulties? There are also bugs. For example, non-NixOS users of Simula are forced to run this script: https://github.com/SimulaVR/Simula/blob/master/swrast.sh https://github.com/SimulaVR/Simula/blob/master/swrast.sh This is because a nix package expects to find a driver in `/run/opengl-driver`, which isn't always present if you're not running NixOS.
  - jancsika 9y ago
    Does the Guix choice of a more expressive language for defining the packages help here?
j_s 9y ago
Just a heads-up in case anyone is confused as I was: Nix is not 100% bit-for-bit deterministic/reproducible yet, though they do deliver functional equivalence.
- FrozenCow 9y ago
  There are efforts to get deterministic builds in NixOS, but it comes with downsides like very high build times.
  - sly010 9y ago
    Can you elaborate? I always thought deterministic builds would enable faster builds (because it would basically allow for downloading and verification of binaries).
    - taktoa 9y ago
      Nix already does binary substitution. It just has the assumption baked in that builds don't do anything nondeterministic (and the Nix build sandbox removes a lot, but not all, of those opportunities; the ones remaining are things like threads, hence the slowdown).
    - wmertens 9y ago
      As an example, gcc includes code generators that try a few random things in order to optimize code. So two builds, on the same system, won't result in the same byte code. Also, build stamps like time, PID, path etc.
marcinkuzminski 9y ago
RhodeCode is one of projects that build their installer on top of nix package manager. Check out this blog post: https://rhodecode.com/blog/61/rhodecode-and-nix-package-manager https://rhodecode.com/blog/61/rhodecode-and-nix-package-mana...
konschubert 9y ago
So, it's like virtualenv, but for all software and not just Python?
- pfranz 9y ago
  Kind of. You can version your workspace, too. Updates are basically atomic. You build the new workspace (with updated versions), then under the hood it just moves a symlink to the new version. It's got some clever fundamentals that allow for really cool (and clean) features because of it.
dim-an 9y ago
Is there a way to install nix into home folder (suppose I don't have sudo on server). I spend some time recently trying to setup nix in such environment and failed. I ended up compiling recent versions of neovim and tmux myself.
- Ericson2314 9y ago
  Your best bet is proot or a user+mnt namespace.
- pfranz 9y ago
  Yes and no (mostly yes). Ideally, you have /nix/ where everything gets installed, then folders with symlinks in your homedir (one that builds your workspaces and another that versions them) with an environment variable in your bash_rc to hook you in. You can put that /nix folder anywhere, but you can no longer use their binary package caches and it will recompile everything. This is because they hard-code paths for dependencies during build time.
- catern 9y ago
  If you can use it, https://github.com/lethalman/nix-user-chroot https://github.com/lethalman/nix-user-chroot is the best way. But, it depends on user namespaces being enabled on your system. That may not be the case.
deleted 9y ago
[deleted]
pknopf 9y ago
I have used NixOS. It's fustrations led me to develop this. https://github.com/pauldotknopf/darch https://github.com/pauldotknopf/darch It is essentially Docker, but you can boot bare-metal with it. It even uses Docker under the hood. Every boot is a fresh boot. You can read-write during boot, but all changes are made to ram. You mount with fstab things you want persisted, like home.
- icebraining 9y ago
  Interesting. Isn't that essentially a livecd? Have you considered using Archiso? If so, what do you see as the advantages of darch?
  - pknopf 9y ago
    Archiso/etc are similar, but that lack some things. --- Layering ---- I can change my inherited build without rebuilding everything. For example: base > xorg-nvidia > plasma > homepc I can easily switch desktop environments by making "homepc" inherit "i3", or w/e. Each layer is essentially a "Dockerfile". If you understand docker, you understand how the images are built and managed. --- Fast switching. --- I can create images for different dev environemnts/clients. I can create an image purely for gaming. I can create an image steam. Darch integrates with grub, so entries will dynamically show up on boot. --- Sharing with DockerHub. --- Sharing with other machines (and other people). Since they are docker images, I can easily upload them to DockerHub. I can update my local build by doing "docker pull && darch extract && sudo darch stage". I will soon setup Travis-CI to auto build and push to DockerHub. Then, I never have to build locally. A cron job will queue a build every few days to make my image "rolling". I can easily revert back to previously working docker images (all tagged by date).
    - icebraining 9y ago
      Thanks!
johnramsden 9y ago
I switched from Arch Linux to NixOS last year and it was a great experience https://ramsdenj.com/2017/06/19/switching-to-nixos-from-arch-linux.html https://ramsdenj.com/2017/06/19/switching-to-nixos-from-arch.... The community is relatively small and easy to get into, with lots of people ready to help out beginners. It took a while to get used to, especially considering the way to learn how something works seems to always be to go and read source code on GitHub. There are good things and bad things about this approach but I fear it makes it difficult for your average user to use since it is a bit of a barrier to entry. I loved how extensible the system was, and how easy it was to make modifications simply by modifying configuration.nix. It made it really feel as though my system was truly 'mine', in some ways being similar to the feeling I get from setting up an Arch machine. Being able to just recreate a machine by cloning your configuration onto the new machine, and running 'nixos-rebuild switch' is extremely powerful. Being able to roll back machine is also amazing. Something else that really impressed me was how great though ZFS support was. Setting up a ZFS system on Nix is one of the best experiences I've had using ZFS on Linux. It really feels as though ZFS is a first-class citizen on Nix, not something tacked on top. It's possible to set up ZFS without adding any sort of external repository like with Arch. I ended up leaving NixOS after running into an issue that I would get related to UEFI, and at that point didn't have the time to track down the problem, but I'm really excited for where NixOS is going in the future, especially when declarative user environments https://github.com/NixOS/nixpkgs/pull/9250 https://github.com/NixOS/nixpkgs/pull/9250 (user configuration) with NixUP becomes a thing. I will definitely be coming back to it in the future.
- CyberShadow 9y ago
  If you're using Arch Linux now, you may find this project useful: https://github.com/CyberShadow/aconfmgr https://github.com/CyberShadow/aconfmgr
- cstrahan 9y ago
  Can I ask what your UEFI problem was? I run NixOS on a couple MacBook Pros using UEFI with systemd-boot (née gummiboot), and I haven't had any problems yet.
Animats 9y ago
Every problem in computer science can be solved by adding another layer of indirection. Except too many layers of indirection.
k2enemy 9y ago
I'm a big fan of Nix, but I really with there was a declarative way to define a user's environment similar to what NixOS has with /etc/nixos/configuration.nix. It seems a little strange to me to have a functional package manager, but an imperative package install process. I think there are a few projects like NixUP and home-manager that are looking to address this, but I'm hoping Nix will provide an official way to do it.
- johnramsden 9y ago
  It's coming: https://github.com/NixOS/nixpkgs/pull/9250 https://github.com/NixOS/nixpkgs/pull/9250
  - clhodapp 9y ago
    That's a bit too strong a statement to make based on a two-year-old still-open PR with an uncertain future. It seems like it might be coming at some point in the future.
    - johnramsden 9y ago
      No, there's actually a fair bit of activity around it, if you read through the comments in the pull request it has a fair bit of activity. They recently got a fair bit of interest on the mailing list https://goo.gl/kvNwC1 https://goo.gl/kvNwC1 and raised some money for it as well https://github.com/NixOS/nixpkgs/pull/9250#issuecomment-320860635 https://github.com/NixOS/nixpkgs/pull/9250#issuecomment-3208.... I'm pretty sure I read somewhere that it's planned to go in the next release.
- asymmetric 9y ago
  I do this without needing any extra tool[0]. I basically define a custom meta-package with all the packages I want as dependencies and install it with `nix-env -iA`. [0]: https://github.com/asymmetric/dotfiles/blob/master/config.nix https://github.com/asymmetric/dotfiles/blob/master/config.ni...
  - 9y ago
austinl 9y ago
I recently wrote a blog post about how we use Nix at Pinterest (just the package manager, not the OS). It helps us give all developers and CI an identical environment. On iOS, we run most build commands and other tools through the nix-shell. New engineers set up their environment by just running a script that installs nix and enters the shell. https://medium.com/@Pinterest_Engineering/continuous-integration-for-ios-with-nix-and-buildkite-ef5b36c5292d https://medium.com/@Pinterest_Engineering/continuous-integra...
_ibu9 9y ago
Nix the package manager is great. Poorly documented, but it works as expected. I've also had uneventful experiences using NixOS on a server. On the other hand, trying to use NixOS on my laptop has been struggle after struggle. Every update breaks something. Many times updates cause the entire system to crash. Different combinations of display managers, window managers, and various system level daemons interact in complex ways. None of this is the fault of NixOS, really it is the fault of the Unix philosophy scaled to the level of the desktop Linux ecosystem, combined with the traditional assurance on upstream developers that packagers in distros like Ubuntu will fix their shit. What would be really great for NixOS would be a set of various well tested base configurations for the various DE/WM combos, like all the spinoff Ubuntu distros. These would fix the versions of all the fragile graphical components on some kind of release schedule, while probably still using nixos-unstable underneath for all the relatively reliable stuff like the kernel, emacs, vim, coreutils, etc.
- matthewbauer 9y ago
  Yes, this is something that I think is really important in the future. NixOS really needs something like Ubuntu is to Debian or Manjaro is to Arch. Lots of polishing that a standard Linux user can start using out of the box (no instructions required).
infinitebyte 9y ago
Software Collections (https://www.softwarecollections.org/en/ https://www.softwarecollections.org/en/) give you the power to build, install, and use multiple versions of software on the same system, without affecting system-wide installed packages. Is this what Nix OS is able to do? Install multiple versions of software and select which version to use before running?
Annatar 9y ago
what would happen if we want to install, for example, two different versions of ruby at the same time? This is treating the symptom instead of the root cause, that being ineptitude to design backward-compatible software. We as an industry should fight such band aids and take a stand. Yes, designing backwards compatible software is hard, but exactly that is the difference between engineering and amateurism. And if one is getting paid to program, I’m going so far as to argue that it’s one’s job to have their head hurt solving such difficult problems so that users of computers don’t have to.
CMCDragonkai 9y ago
For those new to NixOS, the default package installation method is through a concept called channels. It can be a bit confusing reconciling the nature of channels and the real strength of NixOS which is functional reproducibility. I wrote a blog post explaining what channels really are and an alternative which is to use Git commit hashes instead https://matrix.ai/2017/03/13/intro-to-nix-channels-and-reproducible-nixos-environment/ https://matrix.ai/2017/03/13/intro-to-nix-channels-and-repro...
kaushalmodi 9y ago
I do pretty much that using GNU Stow. Of course I then build packages and libraries on my own, in my $HOME, because I don't have root access on that machine. I install any PACKAGE of version VERSION in: ~/stow/pkgs/PACKAGE/VERSION/ So taking nim for example, I'd have: ~/stow/pkgs/nim/0.17.1/ Under that, I'd have the whole FHS system for just nim 0.17.1: ~/stow/pkgs/nim/0.17.1/bin/ ~/stow/pkgs/nim/0.17.1/lib/ ~/stow/pkgs/nim/0.17.1/share/ I set ~/stowed/ as my STOW_TARGET. So on running stow, symlinks to all: ~/stow/pkgs/PACKAGE/VERSION/{bin,lib,share,..}/.. get created in: ~/stowed/{bin,lib,share,..}/.. I then have aliases set up to do something like "unstow PKG/OLD_VER" and "restow PKG/NEW_VER" when I want to change the package version. I skip the "restow" step if I just want to "soft uninstall" a package i.e. remove it from PATH, PKG_CONFIG_PATH, MAN_PATH, .. by removing it only from the STOW_TARGET ~/stowed. "Hard uninstall" would be simply: \rm -rf ~/stow/pkgs/PACKAGE/VERSION_I_DONT_WANT/ Or even: \rm -rf ~/stow/pkgs/PACKAGE_I_DONT_WANT/
cstrahan 9y ago
A copy of what I commented on the blog: Nice post, and I'm glad you're enjoying NixOS! I'm a NixOS contributor/committer, and the principle author (and co-maintainer) of the Bundler-based packaging integration. If you or anyone reading this has any feedback and/or questions about NixOS and Ruby (or NixOS in general) feel free to shoot me a message. I idle on #nixos on Freenode (as cstrahan), and you can email me at charles {{at}} cstrahan.com. Cheers! -Charles Strahan (cstrahan)
stylishmunda136 9y ago
That's a bit too strong a statement to make based on a two-year-old still-open PR with an uncertain future. https://socialworldblog.com/ https://socialworldblog.com/

461 points by vletrmx 9y ago

bfrog 9y ago

Nix is pretty cool but has some significant usability issues.

philipov 9y ago
Having never used Nix before, I would like to know what kind of usability issues it faces. For me, the biggest one is that I can't use it at clients running a Windows shop. That's a blocker.
- nextos 9y ago
  I think biggest ones are i) nix command is a bit complex, but it's getting redesigned [1] & ii) nixpkg definitions sometimes contain a lot of cruft. I've found Guix and GuixSD, which are a GNU-blessed Guile Scheme-based reimplementation of Nix and NixOS, more aesthetically pleasing. Quite simple and elegant in fact. The major differences are that Guix DSLs are implemented on top of Scheme, whereas Nix uses a custom DSL. Furthermore, Guix avoids systemd and uses GNU herd instead. [1] https://github.com/NixOS/nix/issues/779 https://github.com/NixOS/nix/issues/779
  - jitl 9y ago
    Guix uses it’s own init system implemented in Scheme: Sheperd (https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/shepherd/) Herd/Hurd is a kernel, not an init system, although since systemd is Linux only, using a different kernel implies using a non-systemd init system.
    - agumonkey 9y ago
      Shepherd is not a kernel, Hurd is, and shepherd page mentions a relation, that dmd/shepherd was developped closely to Hurd but it not the same thing.
      - nextos 9y ago
        Sure, I wrote herd not Hurd! herd is the commandname of Shepherd client: https://www.gnu.org/software/shepherd/manual/shepherd.html https://www.gnu.org/software/shepherd/manual/shepherd.html
        jitl 9y ago
        Ah — confusing as Herd is the second recursive acronym of Hurd... sorry to pedantic :-)
    - xelxebar 9y ago
      Nitpick---but while we're here---Hurd technically refers to the set of (microkernel) servers. The microkernel itself is Mach. In spirit, Mach and the Hurd servers together provide what the Linux kernel provides monolithically. Anyway... :)
  - gcoda 9y ago
    For my practical reasons I can not use pure GNU distributions, I am not aware of easy community way to re use packages for other distro or something hacky like that. Not everyone have brainpower and time to build custom packages for rare distro, it is a shame, I really like Guix. NixOS got some recepies for using not 100% libre software.
    - nextos 9y ago
      There are repos around packaging tons of non-free (mainly scientific) software for Guix.
    - tilpner 9y ago
      I was told guix has some support for importing normal Nix packages, but I don't know how well it works in practice. https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-import.html https://www.gnu.org/software/guix/manual/html_node/Invoking-...
    - jitl 9y ago
      This is also what keeps me away from Guix. I get that there are third-party repos with non-free software, but using a fringe package of a fringe packager is too far for me. There’s no good choice here: Nix package definitions and tools are inscrutable and user-hostile; and the alternative Guix is burden with GNU/free software zealotry and GPL. A somewhat comparable third option is Habitat, from Chef. It also has a pure build system, a package source, and pure, discrete environments. But it’s also got a bunch of service orchestration parts... Hopefully the Nix redesign will make the tools more palatable for mortals.
      - nextos 9y ago
        What kind of non-free tools are you missing from Guix? The only notable omission is linux, as Guix is based on linux-libre instead. But changing this is a matter of 1 LOC.
        thomastjeffery 9y ago
        > But changing this is a matter of 1 LOC. And how difficult is it for a new user to find that line?
  - pmoriarty 9y ago
    One of the major turn-offs for me in regards to Nix was that it uses a ton of bash scripts. Guix's use of Scheme is a lot more elegant and powerful, and a lot less hacky than bash.
    - sly010 9y ago
      You could use nix the same way guix uses scheme. The lowest level operation in nix is not "run-this-bash-script" but "run- this-executable-with-these-arguments".
      - davexunit 9y ago
        But even still you are mixing languages, so the problem remains. The issue is not that Nix uses Bash, but that Nix uses different languages for the host-side and build-side. AFAIK people aren't writing the build-side code in the Nix language, and I'm not sure if it even has the features necessary to do it. Guix unifies the different layers of code execution with a single language, and using a Lisp enabled that design. For a complete explanation of this design, see the "Code Staging in GNU Guix" paper: https://arxiv.org/abs/1709.00833 https://arxiv.org/abs/1709.00833
        thomastjeffery 9y ago
        > Nix uses different languages for the host-side and build-side. I'm not sure what you mean by that. Nix packages are Nix expressions.
        davexunit 9y ago
        Those package expressions have Bash snippets embedded in them that run on the build daemon. The daemon doesn't evaluate Nix code.
        thomastjeffery 9y ago
        How is that a problem?
  - k__ 9y ago
    When will the redesign be merged? It's over a year that I first read about Nix and they talked about the redesign.
    - grhmc 9y ago
      The redesign is merged and available via `nix-shell -p nixUnstable`. It isn't so much an issue of merging, but calling the new version stable. We're working on it. No definite timetable though.
      - k__ 9y ago
        Ah, cool! Are there docs for the usage after "nix-shell -p nixUnstable"?
- bfrog 9y ago
  Primarily from my perspective... the entire package repo acts as one enormous program. Which is both good and bad. Its not that easy imo to create ad hoc packages or packaging scripts
  - taktoa 9y ago
    I strongly disagree. Creating a Nix package is significantly easier than creating, e.g.: an Arch package, from my experience. packageOverrides is really nice too.
    - bfrog 9y ago
      Try packaging a postgres extension :-)
      - taktoa 9y ago
        If you tell me which specific piece of software you tried to package, I can probably explain what is going on. I strongly suspect that it is either not Nix's fault, or an inherent tradeoff in packaging software (i.e.: not a design flaw, but simply a result of the correctness of package expressions being more tightly controlled in Nix than in other languages). The main exception to that statement that I've seen are cases where Nix works fine, but the Nix expression takes so long to build that iterating on it is very difficult. Luckily, there is a solution for that in the pipeline: "recursive Nix", which allows `nix-build` to be called _inside_ a Nix build sandbox, thus allowing safe memoization of things like `gcc`.
        ben0x539 9y ago
        What's the status of recursive nix / people's thinking about recursive nix?
- zzzcpan 9y ago
  Discoverability is a problem everywhere in Nix, from configuration options to documentation. Which makes it necessary to learn its weird poorly implemented functional programming language and read code. Then there is performance, it's very slow and uses a lot of memory making it impossible to use on a 512 MB vm, for example. If you just want a solution for your packaging management needs - Nix is definitely not it. Nix is more like a thing to get inspired by to make a package manager.
  - philipov 9y ago
    That's nice to hear you say, because I am making a package manager, and I find nix inspiring :p I keep trying to convince myself that someone's already done it better, and there's no point, but then every solution I look at doesn't seem to be good enough.
    - jitl 9y ago
      Agreed, it’s an area where nothing is quite there. Take a look at Habitat - another not quite there option, but one with interesting ideas.
      - philipov 9y ago
        What's the downside of Habitat?
        jitl 9y ago
        I don’t know anyone using it.
  - taktoa 9y ago
    > Then there is performance, it's very slow and uses a lot of memory making it impossible to use on a 512 MB vm, for example. No, this is just a side effect of the CLI user experience being garbage. `nix-env -i <regex>` is almost never what you want, because its semantics are to evaluate everything in nixpkgs, find the set of packages whose `name` attribute is matched by the given regex, and install all of the packages in that set modulo the equivalence relation generated by package `name` equality ignoring version numbers. Instead, you should use `nix-env -iA <channel>.<attribute-path>`, where `<channel>` is the name of a Nix channel (viewable via `nix-channel --list`, usually it is `nixos` or `nixpkgs`) and `<attribute-path>` is a valid attribute path in the nixpkgs package set (these can be discovered by running `nix-repl '<nixpkgs>'` and tab-completing).
- mkl 9y ago
  It apparently works in WSL [1], so Windows needn't be an issue. [1] https://www.reddit.com/r/NixOS/comments/64xyd7/nix_package_manager_works_flawlessly_in_windows/ https://www.reddit.com/r/NixOS/comments/64xyd7/nix_package_m...
  - philipov 9y ago
    Do you use Windows 10 Creators Update on production? It needs to work on Windows Server 2012 or no dice. Maybe Nix will be an option in 5 years when companies upgrade their servers, but that's not an option now.
    - jitl 9y ago
      You could say the same thing about Windows: Windows just isn’t an option yet.... maybe in 5 years when WSL is performant and MSFT has open-sourced enough to not be a threat to more cautious companies.
      - philipov 9y ago
        No, I don't think you can say that. The point is that I have clients that use linux, clients that use windows, and clients that use both windows and linux which need to talk to each other. I need a solution that can factor out the operating system into a module and build packages that will work for both the quants and the servers. I don't get to tell my clients what operating systems to use. I must provide solutions that work on whatever they're running.
        danharaj 9y ago
        Nix has facilities for creating Docker and Singularity containers from a nix expression, which lets you package up arbitrary environments. Does that satisfy your use-case? https://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools https://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools
oconnore 9y ago
* is pretty cool but has some issues.

jingwen 9y ago

On my macOS work machine, Nix has replaced Homebrew. The ability to switch between generations of your system state [1] when a new install goes awry is underrated, IMO. [1] https://nixos.org/nix/manual/#sec-profiles https://nixos.org/nix/manual/#sec-profiles

pfranz 9y ago
I really think the biggest roadblock is the command line interface[1]. To replace Homebrew you only need like 3 or 4 commands. Right now, that means 3 or 4 different nix commands with weird arguments. The way Nix is currently set up is great and make sense for the OS, but Homebrew has a much simpler use-case (single-user, all user land packages, very low barrier to entry). I can't wait until that ticket is addressed. [1] https://github.com/NixOS/nix/issues/779 https://github.com/NixOS/nix/issues/779
j_s 9y ago
Why not both? Does Homebrew conflict with Nix in such a way that only one is possible at a time? I can definitely see giving Nix priority for work-related development, but I would like to know if Homebrew can still fill in as a backup option.
- pfranz 9y ago
  I've installed both without issue. It might be a headache long-term because of libs and installing things in both systems, etc. Just make sure you know which comes first in PATH.

distantsounds 9y ago

Gobolinux does something similar, and has been around for years: https://www.gobolinux.org/ https://www.gobolinux.org/

taktoa 9y ago
It "does something similar" in the sense that it doesn't obey the FHS. NixOS is otherwise a pretty radically different approach AFAIK.
infinisil 9y ago
Funnily enough, NixOS has had its initial release in the same year as Gobolinux, 2003. I'm not sure how Gobolinux organizes files exactly, but with NixOS, the hash in /nix/store/<hash>-packagename is produced by combining every input that might influence the package. By input I mean for example: - The source: git revision / source url / etc. - All dependencies, which means if a dependency of a dependency of this package changes, it gets a new hash - Build instructions, including build flags This wouldn't be possible with a more conventional file structure.

jf 9y ago

I'm very excited about Nix and the possibilities that it opens. If you want to learn more about Nix, I suggest starting with this excellent article on InfoQ: https://www.infoq.com/articles/configuration-management-with-nix https://www.infoq.com/articles/configuration-management-with... I also gave a talk about why I think Nix is so great: https://vimeo.com/album/4676161/video/223525975 https://vimeo.com/album/4676161/video/223525975 Finally, I highly recommend the PhD thesis that Nix is based on: https://nixos.org/~eelco/pubs/phd-thesis.pdf https://nixos.org/~eelco/pubs/phd-thesis.pdf

Jeaye 9y ago

I recently wrote about my experience using NixOS on my VPS [1]; it's truly a very different way of approaching systems administration and Nix is at the heart of it. While I think the Nix expression language has a negative impact on usability, Nix still ends up being a net gain for not only entire OSs, but also reproducible environments for packages on many other OSs. 1: https://blog.jeaye.com/2017/07/30/nixos-revisited/ https://blog.jeaye.com/2017/07/30/nixos-revisited/

afarrell 9y ago
Oooh! Thanks for linking this write-up. I've been thinking of playing around with Nix and basically only be able to do it on a VPS. Before I get started though, what things could I consider implicit prerequisites of running Nix? For example: I've never built a Debian or RPM package. Would I be better served gaining some background in OS package management before diving into this?
- Filligree 9y ago
  Most of what you'd learn playing with other OSs, you'd need to unlrearn to work with Nix. So... nothing much really. Read the Nix Pills series, that'll teach you more than any amount of playing with non-Nix software.
  - afarrell 9y ago
    Thanks! https://nixos.org/nixos/nix-pills/ https://nixos.org/nixos/nix-pills/ for others
- jitl 9y ago
  No: each package manager had its own strange rules and concepts. I’ve worked with deb packaging, and I wouldn’t say that experience transferred to working on Homebrew or Nix. You might as well start with what you want to use.
  - afarrell 9y ago
    This is good to know, though I continue to be sad that there isn't a general "design principles of package managers" knowledgebase.

zzzeek 9y ago

"To deal with this nix provides the nix-shell utility which constructs an environment on demand and runs a new shell based on that environment." I'm sure nix is cool but this sort of sounds like something we just end up using docker for these days (for better or worse).

zzzcpan 9y ago
Yes, Docker is a competing solution. Hopefully in the future we will see a better one, more nix-like.
- Crespyl 9y ago
  Does Docker actually compete with Nix? It seems that Docker is more concerned with containment and Nix with packages. I would love to be able to use Nix to define my project+dependencies and Docker to run it. I'd be surprised if someone hasn't already made a baseline NixOS docker image to build off of.

ldlework 9y ago

I have recently started looking into Nix to solve the problem of dotfile deployment to new OSX workstations. When you get a new laptop, you clone your dotfiles, maybe symlink them to your home directory -- and then what? Nix solves this problem for me by coupling my dotfile deployment with the installation of the related software. The learning curve has been absolutely tremendous, however. That said, the support on Freenode has been some of the best I've encountered in more than a decade. https://nixos.org/nix/manual/#chap-package-management https://nixos.org/nix/manual/#chap-package-management https://rycee.net/posts/2017-07-02-manage-your-home-with-nix.html https://rycee.net/posts/2017-07-02-manage-your-home-with-nix...

k__ 9y ago
Nice. I started using macOS 5 months ago and it felt a bit as a step back coming from Linux. Does Nix work good with macOS?
- jitl 9y ago
  Yep
- kccqzy 9y ago
  I should mention that on High Sierra there’s a bug with kill(-1, ...) that sometimes causes Nix builds to lock up the whole system.
  - wmertens 9y ago
    Also, the OS X windowmanager has a memory leak and you have to resart every so often. Yesterday mine was 22GB and after restart <100MB… Nothing to do with Nix, just venting ;-)
    - tejasmanohar 9y ago
      you have to restart every so often I've never had that happen. Maybe things that don't have to do with Nix... really just don't have to do with Nix ;-)

amelius 9y ago

Python solves this problem with "virtualenv", where the user creates a virtual environment and installs all programs and libraries into that environment. The user can have multiple virtual environments, and it is easy to switch between environments.

e12e 9y ago
Up to a point. You can't install the c (etc) compiler in the venv, so you end up with some dependencies on the external system.
pfranz 9y ago
virtualenv solves virtual environment as much as pip solves OS package management. Not that it's not useful, but you see all over where you have little fiefdoms that work pretty well for their little ecosystem, but become a mess if you integrate stuff outside (virtualenv, rbenv or pip, npm, gem, rpm, apt or make, ant, scons, jam). A lot of these systems are just reimplementations tailored to language-X. Nix is pretty unique and clever. For example, you can effectively version control you virtual environment, it's at the OS level, and accommodates major languages and libraries (Python, Perl, Lua, Java, Go, Qt).
- deleted 9y ago
  [deleted]
philipov 9y ago
venv doesn't even handle environment variables. Some environment that is :p
davexunit 9y ago
Every language has it's equivalent of virtualenv, and that's the problem: it only works for that language's tools and libraries. I don't use Nix, but I do hack on an alternative called GNU Guix sometimes, and I wrote a tool called 'guix environment' which is similar to virtualenv but applicable to any software. Having a generalized solution is much better than one virtualenv tool and package manager per programming language. In Nix the equivalent tool is called nix-shell.

dhruvio 9y ago

I can vouch for the immense improvement Nix has made to my software development process. I use NixOS on my desktop and laptop. At the OS-level, it gets a lot of things right: reproducible, immutable system configs; lightweight containers; devops with declarative configs. At a software project level, nix-shell is an indispensible tool. Compilers and interpreters aren't even part of my system-wide config; instead each project has it's own shell.nix file that installs all dependencies I need on the fly without polluting system state or virtualization. Nix is a god-send, and the developers that contribute to it are nothing short of awesome! The area that needs improvement is the documentation. Once you learn the Nix language, reading the source code is pretty helpful, but it would be nice to make it more approachable. For example, the nixpkgs repo has a bunch of Nix helper functions that are useful to developers when writing their own packages, but these functions' documentation is either buried in a long manual, or non-existent.

vog 9y ago
Naive question: Isn't all that also true for Guix? If so, why do your prefer Nix over Guix?
- ben0x539 9y ago
  Why shouldn't one prefer the original over some rando's weakly motivated, niche NIH rehash, unless you're already victim to lisp-induced Stockholm syndrome?
  - roblabla 9y ago
    > some rando's This is a GNU-approved fork > weakly motivated Has lots of strong motivation, like a stricter stance on non-free software, the usage of a "real", more expressive language (Guile) instead of a niche, poorly undocumented DSL (Nix), use of GNU Shepherd instead of SystemD for the init system, among other > niche NIH rehash It shares most of the codebase with Nix, so to say it's NIH is missing the point. Nix improvements are shared with Guix, and Guix improvements are shared with Nix > unless you're already victim to lisp-induced stockholm syndrome Different lisp offer different syntaxes, features, and use-cases. That you cannot see it makes me think you didn't try too much, and are probably just trolling.

c3534l 9y ago

I'm gonna need a better reason to switch distros than that. I do think that is an improvement that needs to be adopted in the OS. But, I mean, it's not that much of a improvement over containers. I don't feel like it gives me, the user, that much more power over the OS and would be a feature that I would only use very rarely.

infinisil 9y ago
The blogpost just highlights one nice aspect of it, there's more though: - The really powerful NixOS module system, which let's you specify your system declaratively and rather simply: Which programs should be installed, what systemd services should run, use grub for booting, allow this ssh key to login to this user, enable the IPFS daemon, etc. All options (for the 17.09 release) are available here: https://nixos.org/nixos/options.html https://nixos.org/nixos/options.html - System generations: Upon changing an option in your system config, you run `nixos-rebuild switch` which will build, activate the new system and add it to the system generations. All of these are bootable from your bootloader! So if something breaks miserably, you can just rollback to a previous one that worked. New kernel breaks on your hardware? No problem, just roll back. - If you have a new nixos machine, you don't need to run a bunch of odd commands to have it set up. Since the config is declarative, everything you set up is right there, and all you need is a `nixos-rebuild switch` to make it work. - Wanna test some configuration but are too afraid to use your machine? Just build a VM with it by doing `nixos-rebuild build-vm`. Like with everything else with nix, this fetches all dependencies, no need to install them manually.
throwaway34832 9y ago
Have you tried Habitat.sh yet? I has similar goals to NixOS without needing to give up the OS of your choice.
pfranz 9y ago
Well, you don't have to use NixOS, you can just use NixPkgs either as a way to familiarize yourself or to manage a project--personally, I'm hoping after a few things get fixed I can replace Homebrew with it. Even though containers have had a lot of buzz and tooling built around them in the past few years, it's good to see how other approaches can solve similar problems with different pros and cons.

rhn_mk1 9y ago

My experience with Nix was a real pleasure, and a complete failure. I set out with the goal of building a development environment for a software I was working on. I thought - Nix sounds like a better Docker, where it's possible to choose package versions independently of the rest of the system. It's perfect for testing! I found the package description language refreshing - it was powerful without getting too complicated. Over the course of a couple of days I was able to adapt a few packages and create my own too, with the build environment. It was almost finished, but the last problem remained: installing CUDA and the userspace portion of the Nvidia driver. It's not rocket science – I thought – all I need is a few .so's, it even works with Docker. Alas, after battling Nix for another couple of days, trying to use generic GL, installing the Nvidia one, ignoring it altogether or trying to using the host version - I gave up. I found no way to build a package linked against OpenGL that would actually work. Despite that, I hope to use Nix with a different project in the future.

nh2 9y ago
Here are some links that might help you to get OpenGL work with nix programs on non-NixOS machines: * https://github.com/NixOS/nixpkgs/issues/9415#issuecomment-309249312 https://github.com/NixOS/nixpkgs/issues/9415#issuecomment-30... * https://github.com/guibou/nixGL https://github.com/guibou/nixGL * https://github.com/deepfire/nix-install-vendor-gl https://github.com/deepfire/nix-install-vendor-gl
ris 9y ago
Although other people have different opinions to me, I don't really see Nix as something for the desktop, but for development, deployment and server software it's a killer solution for me.
- Filligree 9y ago
  None of what he mentioned was desktop-specific. GPUs are useful, and if CUDA is involved then it's being used for acceleration of some kind, which can perfectly well be done on servers. I agree that Nix is hard to deal with when it comes to binary distributions of any kind, which includes CUDA.

pradeepchhetri 9y ago

Recently, I got the opportunity to play with Nix. To me, it felt to be a very nice way to bundle the dependencies along with the application. But there are few questions which always come to my mind were - how people run it in production. Can they achieve all the things (eg monitoring, debugging..) easily just like the app hosted on a linux machine ?

jitl 9y ago
Sure? It’s still Linux underneath and all the same skills and strategies carry over.
- pradeepchhetri 9y ago
  Thank you, I definitely need to play with it more to understand it better.

hyperion2010 9y ago

Sounds like a similar solution to gentoo's slotted ebuilds [0]. Switching the 'default' implementation system wide or per user (eselect) has the same issues discussed. Not sure if there is an existing utility (beyond your standard shell script) that can produce sane per-shell environments. 0. https://devmanual.gentoo.org/general-concepts/slotting/index.html https://devmanual.gentoo.org/general-concepts/slotting/index...

ben0x539 9y ago
Mhm, doesn't sound all that similar to me. This looks like something that needs to be maintained on a per-package basis as a fairly ad-hoc solution for different library versions, in Nix the whole thing just falls out of the way it's set up in general.

SideburnsOfDoom 9y ago

That article on "What is Nix and .. " does not contain the words "Nix is a..." A quick read gave a vague sense that it was about installs and file paths so maybe something package-related? Nothing definite. If you click through to https://nixos.org/nixos/nix-pills/why-you-should-give-it-a-try.html https://nixos.org/nixos/nix-pills/why-you-should-give-it-a-t... you will see "Nix is a purely functional package manager and deployment system for POSIX"

vletrmx 9y ago
Yes I recommend the nix pills they are really awesome and how I learned Nix!
- samstave 9y ago
  Links?
  - vletrmx 9y ago
    https://nixos.org/nixos/nix-pills/ https://nixos.org/nixos/nix-pills/
sundarurfriend 9y ago
I get the feel that Nix does something like what virtualenv does for python, but more generalized to make that work for other software. Is that approximately right?
- aws_ls 9y ago
  Yes, I also was immediately reminded of Python's conda based environment management. E.g. 'source activate <env1>' may have python3 but when used with <env2> will use python2 and different version of other libraries.

georgewsinger 9y ago

We used Nix to vastly simplify the build process of Simula: https://github.com/SimulaVR/Simula https://github.com/SimulaVR/Simula Simula is a bleeding edge VR Desktop project for Linux; virtually all of its dependencies are highly novel and require building from source for almost any distro. Nix allowed us to reduce the effort to building our project from 1hr of sifting through build documentation to a single build command. Nix's only issue is that it so far can't handle OpenGL dependencies very well. I'm not sure if this is something in principle it cannot handle, or if it just hasn't been done yet. I'm praying it's the latter.

joepie91_ 9y ago
So, OpenGL is a bit of a weird case. Hardware is the one thing that actually varies between systems no matter how declarative your configuration is - this is normally not a problem, since the kernel abstracts it away. The problem with OpenGL, then, is that every graphics driver provides its own set of OpenGL libraries that is subtly different from all the others. This means that applications need to be built against a specific set of OpenGL libraries from a specific graphics driver, and the kernel is of no help here. That's fundamentally where the OpenGL issues come from; Nix packages typically expect the libraries to be semi-statefully provided in a `/run` directory. This gets especially hairy when targeting different distros. EDIT: And because the package doesn't know what graphics drivers it'll be running against on non-NixOS, it can't automatically build against a copy of the correct drivers in nixpkgs either.
- georgewsinger 9y ago
  I agree that, given this description, it's a hard problem. But can Nix find a way to abstract away these difficulties? There are also bugs. For example, non-NixOS users of Simula are forced to run this script: https://github.com/SimulaVR/Simula/blob/master/swrast.sh https://github.com/SimulaVR/Simula/blob/master/swrast.sh This is because a nix package expects to find a driver in `/run/opengl-driver`, which isn't always present if you're not running NixOS.
- jancsika 9y ago
  Does the Guix choice of a more expressive language for defining the packages help here?

j_s 9y ago

Just a heads-up in case anyone is confused as I was: Nix is not 100% bit-for-bit deterministic/reproducible yet, though they do deliver functional equivalence.

FrozenCow 9y ago
There are efforts to get deterministic builds in NixOS, but it comes with downsides like very high build times.
- sly010 9y ago
  Can you elaborate? I always thought deterministic builds would enable faster builds (because it would basically allow for downloading and verification of binaries).
  - taktoa 9y ago
    Nix already does binary substitution. It just has the assumption baked in that builds don't do anything nondeterministic (and the Nix build sandbox removes a lot, but not all, of those opportunities; the ones remaining are things like threads, hence the slowdown).
  - wmertens 9y ago
    As an example, gcc includes code generators that try a few random things in order to optimize code. So two builds, on the same system, won't result in the same byte code. Also, build stamps like time, PID, path etc.

marcinkuzminski 9y ago

RhodeCode is one of projects that build their installer on top of nix package manager. Check out this blog post: https://rhodecode.com/blog/61/rhodecode-and-nix-package-manager https://rhodecode.com/blog/61/rhodecode-and-nix-package-mana...

konschubert 9y ago

So, it's like virtualenv, but for all software and not just Python?

pfranz 9y ago
Kind of. You can version your workspace, too. Updates are basically atomic. You build the new workspace (with updated versions), then under the hood it just moves a symlink to the new version. It's got some clever fundamentals that allow for really cool (and clean) features because of it.

dim-an 9y ago

Is there a way to install nix into home folder (suppose I don't have sudo on server). I spend some time recently trying to setup nix in such environment and failed. I ended up compiling recent versions of neovim and tmux myself.

Ericson2314 9y ago
Your best bet is proot or a user+mnt namespace.
pfranz 9y ago
Yes and no (mostly yes). Ideally, you have /nix/ where everything gets installed, then folders with symlinks in your homedir (one that builds your workspaces and another that versions them) with an environment variable in your bash_rc to hook you in. You can put that /nix folder anywhere, but you can no longer use their binary package caches and it will recompile everything. This is because they hard-code paths for dependencies during build time.
catern 9y ago
If you can use it, https://github.com/lethalman/nix-user-chroot https://github.com/lethalman/nix-user-chroot is the best way. But, it depends on user namespaces being enabled on your system. That may not be the case.

deleted 9y ago

[deleted]

pknopf 9y ago

I have used NixOS. It's fustrations led me to develop this. https://github.com/pauldotknopf/darch https://github.com/pauldotknopf/darch It is essentially Docker, but you can boot bare-metal with it. It even uses Docker under the hood. Every boot is a fresh boot. You can read-write during boot, but all changes are made to ram. You mount with fstab things you want persisted, like home.

icebraining 9y ago
Interesting. Isn't that essentially a livecd? Have you considered using Archiso? If so, what do you see as the advantages of darch?
- pknopf 9y ago
  Archiso/etc are similar, but that lack some things. --- Layering ---- I can change my inherited build without rebuilding everything. For example: base > xorg-nvidia > plasma > homepc I can easily switch desktop environments by making "homepc" inherit "i3", or w/e. Each layer is essentially a "Dockerfile". If you understand docker, you understand how the images are built and managed. --- Fast switching. --- I can create images for different dev environemnts/clients. I can create an image purely for gaming. I can create an image steam. Darch integrates with grub, so entries will dynamically show up on boot. --- Sharing with DockerHub. --- Sharing with other machines (and other people). Since they are docker images, I can easily upload them to DockerHub. I can update my local build by doing "docker pull && darch extract && sudo darch stage". I will soon setup Travis-CI to auto build and push to DockerHub. Then, I never have to build locally. A cron job will queue a build every few days to make my image "rolling". I can easily revert back to previously working docker images (all tagged by date).
  - icebraining 9y ago
    Thanks!

johnramsden 9y ago

I switched from Arch Linux to NixOS last year and it was a great experience https://ramsdenj.com/2017/06/19/switching-to-nixos-from-arch-linux.html https://ramsdenj.com/2017/06/19/switching-to-nixos-from-arch.... The community is relatively small and easy to get into, with lots of people ready to help out beginners. It took a while to get used to, especially considering the way to learn how something works seems to always be to go and read source code on GitHub. There are good things and bad things about this approach but I fear it makes it difficult for your average user to use since it is a bit of a barrier to entry. I loved how extensible the system was, and how easy it was to make modifications simply by modifying configuration.nix. It made it really feel as though my system was truly 'mine', in some ways being similar to the feeling I get from setting up an Arch machine. Being able to just recreate a machine by cloning your configuration onto the new machine, and running 'nixos-rebuild switch' is extremely powerful. Being able to roll back machine is also amazing. Something else that really impressed me was how great though ZFS support was. Setting up a ZFS system on Nix is one of the best experiences I've had using ZFS on Linux. It really feels as though ZFS is a first-class citizen on Nix, not something tacked on top. It's possible to set up ZFS without adding any sort of external repository like with Arch. I ended up leaving NixOS after running into an issue that I would get related to UEFI, and at that point didn't have the time to track down the problem, but I'm really excited for where NixOS is going in the future, especially when declarative user environments https://github.com/NixOS/nixpkgs/pull/9250 https://github.com/NixOS/nixpkgs/pull/9250 (user configuration) with NixUP becomes a thing. I will definitely be coming back to it in the future.

CyberShadow 9y ago
If you're using Arch Linux now, you may find this project useful: https://github.com/CyberShadow/aconfmgr https://github.com/CyberShadow/aconfmgr
cstrahan 9y ago
Can I ask what your UEFI problem was? I run NixOS on a couple MacBook Pros using UEFI with systemd-boot (née gummiboot), and I haven't had any problems yet.

Animats 9y ago

Every problem in computer science can be solved by adding another layer of indirection. Except too many layers of indirection.

k2enemy 9y ago

I'm a big fan of Nix, but I really with there was a declarative way to define a user's environment similar to what NixOS has with /etc/nixos/configuration.nix. It seems a little strange to me to have a functional package manager, but an imperative package install process. I think there are a few projects like NixUP and home-manager that are looking to address this, but I'm hoping Nix will provide an official way to do it.

johnramsden 9y ago
It's coming: https://github.com/NixOS/nixpkgs/pull/9250 https://github.com/NixOS/nixpkgs/pull/9250
- clhodapp 9y ago
  That's a bit too strong a statement to make based on a two-year-old still-open PR with an uncertain future. It seems like it might be coming at some point in the future.
  - johnramsden 9y ago
    No, there's actually a fair bit of activity around it, if you read through the comments in the pull request it has a fair bit of activity. They recently got a fair bit of interest on the mailing list https://goo.gl/kvNwC1 https://goo.gl/kvNwC1 and raised some money for it as well https://github.com/NixOS/nixpkgs/pull/9250#issuecomment-320860635 https://github.com/NixOS/nixpkgs/pull/9250#issuecomment-3208.... I'm pretty sure I read somewhere that it's planned to go in the next release.
asymmetric 9y ago
I do this without needing any extra tool[0]. I basically define a custom meta-package with all the packages I want as dependencies and install it with `nix-env -iA`. [0]: https://github.com/asymmetric/dotfiles/blob/master/config.nix https://github.com/asymmetric/dotfiles/blob/master/config.ni...
- 9y ago

austinl 9y ago

I recently wrote a blog post about how we use Nix at Pinterest (just the package manager, not the OS). It helps us give all developers and CI an identical environment. On iOS, we run most build commands and other tools through the nix-shell. New engineers set up their environment by just running a script that installs nix and enters the shell. https://medium.com/@Pinterest_Engineering/continuous-integration-for-ios-with-nix-and-buildkite-ef5b36c5292d https://medium.com/@Pinterest_Engineering/continuous-integra...

_ibu9 9y ago

Nix the package manager is great. Poorly documented, but it works as expected. I've also had uneventful experiences using NixOS on a server. On the other hand, trying to use NixOS on my laptop has been struggle after struggle. Every update breaks something. Many times updates cause the entire system to crash. Different combinations of display managers, window managers, and various system level daemons interact in complex ways. None of this is the fault of NixOS, really it is the fault of the Unix philosophy scaled to the level of the desktop Linux ecosystem, combined with the traditional assurance on upstream developers that packagers in distros like Ubuntu will fix their shit. What would be really great for NixOS would be a set of various well tested base configurations for the various DE/WM combos, like all the spinoff Ubuntu distros. These would fix the versions of all the fragile graphical components on some kind of release schedule, while probably still using nixos-unstable underneath for all the relatively reliable stuff like the kernel, emacs, vim, coreutils, etc.

matthewbauer 9y ago
Yes, this is something that I think is really important in the future. NixOS really needs something like Ubuntu is to Debian or Manjaro is to Arch. Lots of polishing that a standard Linux user can start using out of the box (no instructions required).

infinitebyte 9y ago

Software Collections (https://www.softwarecollections.org/en/ https://www.softwarecollections.org/en/) give you the power to build, install, and use multiple versions of software on the same system, without affecting system-wide installed packages. Is this what Nix OS is able to do? Install multiple versions of software and select which version to use before running?

Annatar 9y ago

what would happen if we want to install, for example, two different versions of ruby at the same time? This is treating the symptom instead of the root cause, that being ineptitude to design backward-compatible software. We as an industry should fight such band aids and take a stand. Yes, designing backwards compatible software is hard, but exactly that is the difference between engineering and amateurism. And if one is getting paid to program, I’m going so far as to argue that it’s one’s job to have their head hurt solving such difficult problems so that users of computers don’t have to.

CMCDragonkai 9y ago

For those new to NixOS, the default package installation method is through a concept called channels. It can be a bit confusing reconciling the nature of channels and the real strength of NixOS which is functional reproducibility. I wrote a blog post explaining what channels really are and an alternative which is to use Git commit hashes instead https://matrix.ai/2017/03/13/intro-to-nix-channels-and-reproducible-nixos-environment/ https://matrix.ai/2017/03/13/intro-to-nix-channels-and-repro...

kaushalmodi 9y ago

I do pretty much that using GNU Stow. Of course I then build packages and libraries on my own, in my $HOME, because I don't have root access on that machine. I install any PACKAGE of version VERSION in: ~/stow/pkgs/PACKAGE/VERSION/ So taking nim for example, I'd have: ~/stow/pkgs/nim/0.17.1/ Under that, I'd have the whole FHS system for just nim 0.17.1: ~/stow/pkgs/nim/0.17.1/bin/ ~/stow/pkgs/nim/0.17.1/lib/ ~/stow/pkgs/nim/0.17.1/share/ I set ~/stowed/ as my STOW_TARGET. So on running stow, symlinks to all: ~/stow/pkgs/PACKAGE/VERSION/{bin,lib,share,..}/.. get created in: ~/stowed/{bin,lib,share,..}/.. I then have aliases set up to do something like "unstow PKG/OLD_VER" and "restow PKG/NEW_VER" when I want to change the package version. I skip the "restow" step if I just want to "soft uninstall" a package i.e. remove it from PATH, PKG_CONFIG_PATH, MAN_PATH, .. by removing it only from the STOW_TARGET ~/stowed. "Hard uninstall" would be simply: \rm -rf ~/stow/pkgs/PACKAGE/VERSION_I_DONT_WANT/ Or even: \rm -rf ~/stow/pkgs/PACKAGE_I_DONT_WANT/

cstrahan 9y ago

A copy of what I commented on the blog: Nice post, and I'm glad you're enjoying NixOS! I'm a NixOS contributor/committer, and the principle author (and co-maintainer) of the Bundler-based packaging integration. If you or anyone reading this has any feedback and/or questions about NixOS and Ruby (or NixOS in general) feel free to shoot me a message. I idle on #nixos on Freenode (as cstrahan), and you can email me at charles {{at}} cstrahan.com. Cheers! -Charles Strahan (cstrahan)

stylishmunda136 9y ago

That's a bit too strong a statement to make based on a two-year-old still-open PR with an uncertain future. https://socialworldblog.com/ https://socialworldblog.com/