7 ms·

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

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.
    - lfam 9y ago
      > 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. In Guix, the only code from Nix is the Nix daemon. There is not really much code going back and forth, mostly just bug fixes.
    - davexunit 9y ago
      Guix doesn't really share any of the codebase with Nix. Guix uses a modified version of the Nix daemon, but that is a tiny fraction of the total source code. Guix is an alternative implementation of the packaging model pioneered by Nix, plus additional features not found in Nix.
    - dikaiosune 9y ago
      I’d just like to interject for a moment. What you’re refering to as Guix, is in fact, Nix/Guile, or as I’ve recently taken to calling it, Nix plus Guile.
      - deleted 9y ago
        [deleted]
    - ben0x539 9y ago
      I'm curious if you'd like to elaborate on what makes Guile more expressive than Nix for writing package definitions.
- majewsky 9y ago
  Not the grandparent, but from what i can see, grandparent compares Nix with traditional package managers like dpkg or RPM, rather than Guix. I cannot answer your question, but I think Nix has (for some reason) a lot more publicity than Guix at the moment.
  - joepie91_ 9y ago
    Guix is derived from Nix, so that might be why.
    - rekado 9y ago
      If by "derived" you mean that it is another implementation of functional package management, then you are right. But if "derived" implies that Guix is a fork, then you are mistaken. Guix is not a fork of Nix.
      - xwvvvvwx 9y ago
        Guix is built on top of the nix daemon, so while it's not strictly a fork, derived seems fair.
- thomastjeffery 9y ago
  Guix explicitly rejects non-free software. Unfortunately, that isn't workable for most of us.
  - nejenendn 9y ago
    Ouch. Is this at a legal or community level?
    - thomastjeffery 9y ago
      Community. There may even be community-based sources for non-free packages, but they are explicitly ignored by the Guix project.
      - hackermailman 9y ago
        Anybody can run guix publish however and self publish their own non-free substitutes if they wanted, plus there's all the existing non-free substitute servers around, and you can try your luck with guix import from nixpkgs. The community won't help anybody if they ask for help with non-free software though. I haven't missed any non-free packages since switching to Guix surprisingly, I always seem to find a free alternative though my daily req are pretty basic.
        thomastjeffery 9y ago
        > plus there's all the existing non-free substitute servers around Where? > The community won't help anybody if they ask for help with non-free software though. This, specifically, is where Nix has the advantage.
  - nextos 9y ago
    Note you can use any Nix package in Guix...
nerdponx 9y ago
these functions' documentation is either buried in a long manual This is a problem with lots of feature-rich software, even with meticulously-documented APIs. What we need is reverse-indexed documentation. That is, an extensive API reference is only useful for someone who already knows what functions are in the API and just needs to remember how to use them. But even the most thorough API reference does nothing to promote discovering new functionality. This is often left to the authors, who then have to go about writing a User's Guide that gradually explains concepts, idioms, etc. in prose. Thorough User's Guides are rare because they are tough to write, and even tougher to write well. Users don't often have the time to read through potentially hundreds of pages of prose to find what they're looking for. We need a better way to let users search or browse for concepts, and then be given a list of the functions that implement each concept. That is, addition to documentation like: size_t strlen(const char * s); RETURN: Length of string s. size_t strnlen(const char * s, size_t maxlen); RETURN: Length of string s, or maxlen (whichever is smaller). NOTE: Stops reading after maxlen. char * stpcpy(char * dst, const char * src); Copy src to dst. RETURN: pointer to trailing '\0' of dst, or dst[n] if no trailing NUL. NOTE: Undefined behavior if dst and src overlap. char * stpncpy(char * dst, const char * src, size_t len); Copy up to len bytes from src to dst. RETURN: pointer to trailing '\0' of dst, or dst[n] if no trailing NUL. NOTE: Undefined behavior if dst and src overlap. char * strcpy(char * dst, const char * src); Copy src to dst. RETURN: dst. NOTE: Undefined behavior if dst and src overlap. char * strncpy(char * dst, const char * src, size_t len); Copy up to len bytes from src to dst RETURN: dst. NOTE: Undefined behavior if dst and src overlap. We also need to be able to "tag" functions. So we might have the following tags that allow us to search for concepts: strcpy TAGS: "concept":"data type":"text", "concept":"attribute":"length", ".input":"array", ".input":"char", ".input":"pointer", ".return":"string", ".return":"pointer" strncpy TAGS: "concept":"data type":"text", "concept":"attribute":"length", "concept":"data type":"array":"max-length operator", ".input":"array", ".input":"char", ".input":"pointer", ".return":"array", ".return":"pointer" And a tag browsing page that looks like concept └─ data type └─ text └─ array (conceptual) └─ max-length operator └─ attribute └─ length / size data structure └─ char └─ array (implementation) └─ pointer Which the user could then scan, and identify keywords to search for: '"concept":"data type":"text" AND "concept":"attribute":"length"' And be given "strlen" and "strnlen" as the top two hits, followed by "wcslen" and "wcsnlen". It seems like a PITA at first, but I'm pretty sure tagging functions in their docstrings is easier than writing a whole new User's Guide.
aprdm 9y ago
By reading your comment and a little bit of the package declarations in some nix packages, it seems like the software package system of nix is very similar to rez. Rez ( https://github.com/nerdvegas/rez https://github.com/nerdvegas/rez ) is used by some visual effects companies (including mine) to manage software packages. It allows us to have great flexibility in the mix & match of software versions and runtime environments.
- ben0x539 9y ago
  Does rez handle having an environment with two apps in it that require differing versions of the same dependency?
  - gfixler 9y ago
    It takes a list of requested packages, does some dependency resolution to arrive at a matching package list, generates environment variable setting/exporting code (in Python, e.g. setting things like PYTHONPATH and MAYA_PLUGIN_PATH), then launches a new shell with that code. So, yes, you can have multiple shells with different packages in use simultaneously. I don't think it operates below the industry software package level, which makes sense, as most industry software is non-free, closed-source binaries. Each package has a `package.py` with its own list of dependencies, and code for things like manual tweaks to env vars. >"Using Rez you can create standalone environments configured for a given set of packages. However, unlike many other package managers, packages are not installed into these standalone environments. Instead, all package versions are installed into a central repository, and standalone environments reference these existing packages. This means that configured environments are lightweight, and very fast to create, often taking just a few seconds to configure despite containing hundreds of packages."
    - mrkgnao 9y ago
      I believe GP was asking if you could have packages A and B installed simultaneously if - A depended on version X of C - B depended on version Y of C - X != Y
jimbokun 9y ago
Sounds like this solves a similar problem to Docker. Can you comment on what the differences are, and the relative strengths and weaknesses of each approach?
- KirinDave 9y ago
  I was confused by this first. So Nix is ultimately a tool for making and sharing reproducible package builds. It has a binary cache, but it's not necessary. Like Ports, packages get built by default. Docker, on the other hand, is a distribution and execution mechanism. It provides an abstract way to move around a fully assembled, ready-to-go service or application running in isolation. It's entirely reasonable to use both. You can use Nix to build and manage docker images and make extremely minimalist docker images. You can use Nix knowing that the entire process is perfectly reproducible, and the Docker containerization is only a final integration step. With this, you sorta get the best of both worlds. You get a reproducible build (and if done right, also a reproducible dev environment via nix-shell) and with Docker you get the ability to build and run a prepped copy with a well-defined interface. Docker really doesn't provide a way to reproduce a built image from scratch. You sort of have to trust and build on existing images, and most folks making bulk images appeal to external tooling outside docker files to do this.
- dhruvio 9y ago
  The main difference between the two is Nix's ideas come from functional programming, and Docker's are imperative. The practical outcome of this is that it's easier to keep your system clean over time with Nix than Docker because of the way it's been designed. Nix isn't only a package manager, it is also a functional programming language intended for system administration. This means that, while a Nix file is comparative to a Dockerfile, it has several key differences: 1. All Nix files are just functions that take a number of arguments and return a system config (like a JSON object, but with some nice functionality). A Dockerfile is a set of commands you run to build a system to a "starting" state. This is imperative (you're telling the computer to "do this", then "do that", etc.), so once it's done, you can mutate state to deviate from what you specified in your Dockerfile. With Nix, while you can technically do this on some systems, it does provide you with the command line tools so you don't break things (e.g. nix-shell, nix-env). Note, on NixOS, other measures are taken to encourage safety. 2. If things go wrong in Nix(OS), the idea is that you can do a fresh install in your system, copy your old Nix file to it, and with one bash command, be back to where you were before things went haywire. In terms of containers, there's nothing new with this because this is exactly what Docker does. However, Nix also has this concept of generations, so every time you use a Nix command to change your system state either declaratively via a Nix file or imperatively in the command-line using nix-env, you can roll back to a previous version of state. This is especially nice with NixOS, because it creates generations for your entire system too (includes hardware config, drivers, kernel etc.), and makes separate GRUB entries for each generation, so if something breaks after you do a system upgrade, you just chose an old GRUB entry to go back to where you were. AFAIK, Docker doesn't offer anything like this, and this is a good example of how these tools' designs can impact their feature-set so dramatically. 3. A neat feature of Docker is composability. You can inherit from other, pre-existing Dockerfiles, and you can deploy multi-container apps with various tools. Composability at a single-container level is very straightforward with Nix. Since every config is just a function, you simply call the function exposed by a different Nix file with the correct arguments, and... voila! Once you've made your desired Nix file, you can run it either using nix-shell or nixos-container. While I'm no expert, I believe they perform better than Docker as they don't use virtualization. For multi-container deployment, there is NixOps. You write some Nix files describing the VMs you want to deploy, and run a bash command to deploy them to various back-ends (AWS, Azure, etc.). Again, the big difference here is that you can incrementally modify these VMs in a safe way using Nix. If you change your deployment config file, Nix will figure out something has changed, and modify the corresponding VMs to achieve the desired state. Some may believe that Docker and Nix are very similar, and to their credit, they are in certain scenarios. The thing I like about Nix is that it's one language (and architecture) that was designed well. It's minimal, yet makes it possible to do so much in a safe way. Nix has been around for a while, but I think the community is growing quickly as functional programming continues to take off. I'm excited to see where it goes, and am super grateful I have a tool like this to use while coding.
xfer 9y ago
To me, when i look at new distro, i look for how well the repo covers binary packages, i have no time/resource to build compilers/big projects. Last time i checked nix, there aren't that many packages in repo to be usable on laptop. But the package manager itself might be a good idea for dev environments, but all the languages i use provide similar facility(not counting system-library dependencies).
- taktoa 9y ago
  I'm confused by this statement. `nixpkgs` contains tens of thousands of packages, the majority of which have binary substitutions via the NixOS Hydra build farm. Usually the only time I build things from source on my NixOS laptop are when I override some package to use a patch of my own design. Hell, when I was using Arch Linux I found myself building things from source _way_ more often than after switching to NixOS.
  - xfer 9y ago
    I use void-linux and the only thing that i am building from source(aside from language specific pkgs) are emacs-git and st(terminal emulator). At that time, most packages were old version on nixpkgs and some weren't available. I will look into it again, when i have the mood to switch distros.
    - thinkpad20 9y ago
      I don’t know when you were last looking but for as long as I’ve been using nix (since early 2015) nixpkgs has had definitions of the vast majority of commonly used software, and pre-built binaries of most of those. Definitely worth another look. Also note that you don’t have to switch distros as nix can be plugged into almost any Linux environment without conflicting with whatever else is there.
- thomastjeffery 9y ago
  I very rarely run into packages that Nix doesn't have prebuilt binaries for.
- 9y ago

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.
  - lfam 9y ago
    > 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. In Guix, the only code from Nix is the Nix daemon. There is not really much code going back and forth, mostly just bug fixes.
  - davexunit 9y ago
    Guix doesn't really share any of the codebase with Nix. Guix uses a modified version of the Nix daemon, but that is a tiny fraction of the total source code. Guix is an alternative implementation of the packaging model pioneered by Nix, plus additional features not found in Nix.
  - dikaiosune 9y ago
    I’d just like to interject for a moment. What you’re refering to as Guix, is in fact, Nix/Guile, or as I’ve recently taken to calling it, Nix plus Guile.
    - deleted 9y ago
      [deleted]
  - ben0x539 9y ago
    I'm curious if you'd like to elaborate on what makes Guile more expressive than Nix for writing package definitions.
majewsky 9y ago
Not the grandparent, but from what i can see, grandparent compares Nix with traditional package managers like dpkg or RPM, rather than Guix. I cannot answer your question, but I think Nix has (for some reason) a lot more publicity than Guix at the moment.
- joepie91_ 9y ago
  Guix is derived from Nix, so that might be why.
  - rekado 9y ago
    If by "derived" you mean that it is another implementation of functional package management, then you are right. But if "derived" implies that Guix is a fork, then you are mistaken. Guix is not a fork of Nix.
    - xwvvvvwx 9y ago
      Guix is built on top of the nix daemon, so while it's not strictly a fork, derived seems fair.
thomastjeffery 9y ago
Guix explicitly rejects non-free software. Unfortunately, that isn't workable for most of us.
- nejenendn 9y ago
  Ouch. Is this at a legal or community level?
  - thomastjeffery 9y ago
    Community. There may even be community-based sources for non-free packages, but they are explicitly ignored by the Guix project.
    - hackermailman 9y ago
      Anybody can run guix publish however and self publish their own non-free substitutes if they wanted, plus there's all the existing non-free substitute servers around, and you can try your luck with guix import from nixpkgs. The community won't help anybody if they ask for help with non-free software though. I haven't missed any non-free packages since switching to Guix surprisingly, I always seem to find a free alternative though my daily req are pretty basic.
      - thomastjeffery 9y ago
        > plus there's all the existing non-free substitute servers around Where? > The community won't help anybody if they ask for help with non-free software though. This, specifically, is where Nix has the advantage.
- nextos 9y ago
  Note you can use any Nix package in Guix...

nerdponx 9y ago

these functions' documentation is either buried in a long manual This is a problem with lots of feature-rich software, even with meticulously-documented APIs. What we need is reverse-indexed documentation. That is, an extensive API reference is only useful for someone who already knows what functions are in the API and just needs to remember how to use them. But even the most thorough API reference does nothing to promote discovering new functionality. This is often left to the authors, who then have to go about writing a User's Guide that gradually explains concepts, idioms, etc. in prose. Thorough User's Guides are rare because they are tough to write, and even tougher to write well. Users don't often have the time to read through potentially hundreds of pages of prose to find what they're looking for. We need a better way to let users search or browse for concepts, and then be given a list of the functions that implement each concept. That is, addition to documentation like: size_t strlen(const char * s); RETURN: Length of string s. size_t strnlen(const char * s, size_t maxlen); RETURN: Length of string s, or maxlen (whichever is smaller). NOTE: Stops reading after maxlen. char * stpcpy(char * dst, const char * src); Copy src to dst. RETURN: pointer to trailing '\0' of dst, or dst[n] if no trailing NUL. NOTE: Undefined behavior if dst and src overlap. char * stpncpy(char * dst, const char * src, size_t len); Copy up to len bytes from src to dst. RETURN: pointer to trailing '\0' of dst, or dst[n] if no trailing NUL. NOTE: Undefined behavior if dst and src overlap. char * strcpy(char * dst, const char * src); Copy src to dst. RETURN: dst. NOTE: Undefined behavior if dst and src overlap. char * strncpy(char * dst, const char * src, size_t len); Copy up to len bytes from src to dst RETURN: dst. NOTE: Undefined behavior if dst and src overlap. We also need to be able to "tag" functions. So we might have the following tags that allow us to search for concepts: strcpy TAGS: "concept":"data type":"text", "concept":"attribute":"length", ".input":"array", ".input":"char", ".input":"pointer", ".return":"string", ".return":"pointer" strncpy TAGS: "concept":"data type":"text", "concept":"attribute":"length", "concept":"data type":"array":"max-length operator", ".input":"array", ".input":"char", ".input":"pointer", ".return":"array", ".return":"pointer" And a tag browsing page that looks like concept └─ data type └─ text └─ array (conceptual) └─ max-length operator └─ attribute └─ length / size data structure └─ char └─ array (implementation) └─ pointer Which the user could then scan, and identify keywords to search for: '"concept":"data type":"text" AND "concept":"attribute":"length"' And be given "strlen" and "strnlen" as the top two hits, followed by "wcslen" and "wcsnlen". It seems like a PITA at first, but I'm pretty sure tagging functions in their docstrings is easier than writing a whole new User's Guide.

aprdm 9y ago

By reading your comment and a little bit of the package declarations in some nix packages, it seems like the software package system of nix is very similar to rez. Rez ( https://github.com/nerdvegas/rez https://github.com/nerdvegas/rez ) is used by some visual effects companies (including mine) to manage software packages. It allows us to have great flexibility in the mix & match of software versions and runtime environments.

ben0x539 9y ago
Does rez handle having an environment with two apps in it that require differing versions of the same dependency?
- gfixler 9y ago
  It takes a list of requested packages, does some dependency resolution to arrive at a matching package list, generates environment variable setting/exporting code (in Python, e.g. setting things like PYTHONPATH and MAYA_PLUGIN_PATH), then launches a new shell with that code. So, yes, you can have multiple shells with different packages in use simultaneously. I don't think it operates below the industry software package level, which makes sense, as most industry software is non-free, closed-source binaries. Each package has a `package.py` with its own list of dependencies, and code for things like manual tweaks to env vars. >"Using Rez you can create standalone environments configured for a given set of packages. However, unlike many other package managers, packages are not installed into these standalone environments. Instead, all package versions are installed into a central repository, and standalone environments reference these existing packages. This means that configured environments are lightweight, and very fast to create, often taking just a few seconds to configure despite containing hundreds of packages."
  - mrkgnao 9y ago
    I believe GP was asking if you could have packages A and B installed simultaneously if - A depended on version X of C - B depended on version Y of C - X != Y

jimbokun 9y ago

Sounds like this solves a similar problem to Docker. Can you comment on what the differences are, and the relative strengths and weaknesses of each approach?

KirinDave 9y ago
I was confused by this first. So Nix is ultimately a tool for making and sharing reproducible package builds. It has a binary cache, but it's not necessary. Like Ports, packages get built by default. Docker, on the other hand, is a distribution and execution mechanism. It provides an abstract way to move around a fully assembled, ready-to-go service or application running in isolation. It's entirely reasonable to use both. You can use Nix to build and manage docker images and make extremely minimalist docker images. You can use Nix knowing that the entire process is perfectly reproducible, and the Docker containerization is only a final integration step. With this, you sorta get the best of both worlds. You get a reproducible build (and if done right, also a reproducible dev environment via nix-shell) and with Docker you get the ability to build and run a prepped copy with a well-defined interface. Docker really doesn't provide a way to reproduce a built image from scratch. You sort of have to trust and build on existing images, and most folks making bulk images appeal to external tooling outside docker files to do this.
dhruvio 9y ago
The main difference between the two is Nix's ideas come from functional programming, and Docker's are imperative. The practical outcome of this is that it's easier to keep your system clean over time with Nix than Docker because of the way it's been designed. Nix isn't only a package manager, it is also a functional programming language intended for system administration. This means that, while a Nix file is comparative to a Dockerfile, it has several key differences: 1. All Nix files are just functions that take a number of arguments and return a system config (like a JSON object, but with some nice functionality). A Dockerfile is a set of commands you run to build a system to a "starting" state. This is imperative (you're telling the computer to "do this", then "do that", etc.), so once it's done, you can mutate state to deviate from what you specified in your Dockerfile. With Nix, while you can technically do this on some systems, it does provide you with the command line tools so you don't break things (e.g. nix-shell, nix-env). Note, on NixOS, other measures are taken to encourage safety. 2. If things go wrong in Nix(OS), the idea is that you can do a fresh install in your system, copy your old Nix file to it, and with one bash command, be back to where you were before things went haywire. In terms of containers, there's nothing new with this because this is exactly what Docker does. However, Nix also has this concept of generations, so every time you use a Nix command to change your system state either declaratively via a Nix file or imperatively in the command-line using nix-env, you can roll back to a previous version of state. This is especially nice with NixOS, because it creates generations for your entire system too (includes hardware config, drivers, kernel etc.), and makes separate GRUB entries for each generation, so if something breaks after you do a system upgrade, you just chose an old GRUB entry to go back to where you were. AFAIK, Docker doesn't offer anything like this, and this is a good example of how these tools' designs can impact their feature-set so dramatically. 3. A neat feature of Docker is composability. You can inherit from other, pre-existing Dockerfiles, and you can deploy multi-container apps with various tools. Composability at a single-container level is very straightforward with Nix. Since every config is just a function, you simply call the function exposed by a different Nix file with the correct arguments, and... voila! Once you've made your desired Nix file, you can run it either using nix-shell or nixos-container. While I'm no expert, I believe they perform better than Docker as they don't use virtualization. For multi-container deployment, there is NixOps. You write some Nix files describing the VMs you want to deploy, and run a bash command to deploy them to various back-ends (AWS, Azure, etc.). Again, the big difference here is that you can incrementally modify these VMs in a safe way using Nix. If you change your deployment config file, Nix will figure out something has changed, and modify the corresponding VMs to achieve the desired state. Some may believe that Docker and Nix are very similar, and to their credit, they are in certain scenarios. The thing I like about Nix is that it's one language (and architecture) that was designed well. It's minimal, yet makes it possible to do so much in a safe way. Nix has been around for a while, but I think the community is growing quickly as functional programming continues to take off. I'm excited to see where it goes, and am super grateful I have a tool like this to use while coding.

xfer 9y ago

To me, when i look at new distro, i look for how well the repo covers binary packages, i have no time/resource to build compilers/big projects. Last time i checked nix, there aren't that many packages in repo to be usable on laptop. But the package manager itself might be a good idea for dev environments, but all the languages i use provide similar facility(not counting system-library dependencies).

taktoa 9y ago
I'm confused by this statement. `nixpkgs` contains tens of thousands of packages, the majority of which have binary substitutions via the NixOS Hydra build farm. Usually the only time I build things from source on my NixOS laptop are when I override some package to use a patch of my own design. Hell, when I was using Arch Linux I found myself building things from source _way_ more often than after switching to NixOS.
- xfer 9y ago
  I use void-linux and the only thing that i am building from source(aside from language specific pkgs) are emacs-git and st(terminal emulator). At that time, most packages were old version on nixpkgs and some weren't available. I will look into it again, when i have the mood to switch distros.
  - thinkpad20 9y ago
    I don’t know when you were last looking but for as long as I’ve been using nix (since early 2015) nixpkgs has had definitions of the vast majority of commonly used software, and pre-built binaries of most of those. Definitely worth another look. Also note that you don’t have to switch distros as nix can be plugged into almost any Linux environment without conflicting with whatever else is there.
thomastjeffery 9y ago
I very rarely run into packages that Nix doesn't have prebuilt binaries for.
9y ago