Read the discussion on HN. A full-thread summary is not available yet.
NixOS
nixpkgs
Nix2013–2026
NixOS / nixpkgs
nixpkgs
Nix Packages collection & NixOS
360Distinct people
597Mentions
11Explicit recommenders
26.8KGitHub stars
What to know before exploring
What it is
Nix Packages collection & NixOS
GitHub
Where it is used
What people are saying
I love NixOS, it's my daily driver on my personal laptop, but it definitely has given me more than its fair share of headaches. If everything you're going to do is in Nixpkgs,…
tombert used a recommendation phrase. 11 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- nixos/nix · linked in 13 of the same discussions
- nix-darwin/nix-darwin · linked in 6 of the same discussions
- nix-community/home-manager · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 4:00:59 PM UTC.
Commenters debate whether Haskell's primary bottleneck is technical performance, such as compile time and incremental builds, or its lack of a coherent, polished ecosystem for building diverse applications like web and desktop software. While some argue that foundational libraries and better developer experience are the missing pieces, others contend that the language's utility is constrained by fragmented tooling and unclear positioning compared to more universal alternatives.
17 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4Mentions over time
HN mentions by year597 dated mentions
Observed mentions: 2013-12-15 16:18:08 UTC to 2026-10-21 00:27:48 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 13 | 1 | 12 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 23 | 1 | 22 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 22 | 0 | 22 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 21 | 0 | 21 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 31 | 1 | 30 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 59 | 1 | 58 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 112 | 3 | 109 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 72 | 3 | 69 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 81 | 5 | 76 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 77 | 3 | 74 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 53 | 5 | 48 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 25 | 2 | 23 |
From the project README
An excerpt from the repository, fetched Nov 12, 2026.
Read the project’s introduction
Nixpkgs is a collection of over 140,000 software packages that can be installed with the Nix package manager.
It also implements NixOS, a purely-functional Linux distribution.
Manuals
NixOS Manual - how to install, configure, and maintain a purely-functional Linux distribution
Nixpkgs Manual - contributing to Nixpkgs and using programming-language-specific Nix expressions
Nix Package Manager Manual - how to write Nix expressions (programs), and how to use Nix command line tools
Community
Discourse Forum
Matrix Chat
Official wiki
Community-maintained list of ways to get in touch (Discord, Telegram, IRC, etc.)
Other Project Repositories
The sources of all official Nix-related projects are in the NixOS organization on GitHub.
Here are some of the main ones:
Nix - the purely functional package manager
NixOps - the tool to remotely deploy NixOS machines
nixos-hardware - NixOS profiles to optimize settings for different hardware
Nix RFCs - the formal process for making substantial changes to the community
NixOS homepage - the NixOS.org website
hydra - our continuous integration system
NixOS Branding - NixOS branding
Continuous Integration and Distribution
Nixpkgs and NixOS are built and tested by our continuous integration system, Hydra.
Continuous package builds for unstable/master
Continuous package builds for the NixOS 26.05 release
Tests for unstable/master
Tests for the NixOS 26.05 release
Artifacts successfully built with Hydra are published to cache at https://cache.nixos.org/.
When successful build and test criteria are met, the Nixpkgs expressions are distributed via Nix channels.
Contributing
Nixpkgs is among the most active projects on GitHub.
While thousands of open issues and pull requests might seem like a lot at first, it helps to consider it in the context of the scope of the project.
Nixpkgs describes how to build tens of thousands of pieces of software and implements a Linux distribution.
The GitHub Insights page gives a sense of the project activity.
Community contributions are always welcome through GitHub Issues and Pull Requests.
For more information about contributing to the project, please visit the contributing page.
Donations
The infrastructure for NixOS and related projects is maintained by a nonprofit organization, the NixOS Foundation.
To ensure the continuity and expansion of the NixOS infrastructure, we are looking for donations to our organization.
You can donate to the NixOS Foundation through SEPA bank transfers or by using Open Collective:
License
Nixpkgs is licensed under the MIT License.
NoteMIT license does not apply to the packages built by Nixpkgs, merely to the files in this repository (the Nix expressions, build scripts, NixOS modules, etc.).
It also might not apply to patches included in Nixpkgs, which may be derivative works of the packages to which they apply.
The aforementioned artifacts are all covered by the licenses of the respective packages.
Read the full README on GitHubWhat Hacker News says
112 sources> Hm. Using Nix looks interesting (I’m a fellow Mac user).
Nix is very powerful; there's a steep learning curve the more of its ecosystem you use. If "declarative", "generational", "immutable" are all words you like, it's worth looking into.
It's one of the best ways to be able to get a consistent set of tools (and versions of) across macOS/Linux.
> When you do that, do you also need to compile the applications during installation…? (E.g. stuff written in Rust/C/C++)
My experience using Nixpkgs with macOS was that most stuff downloaded from the cache. I would run into a few cache-misses where Nix would fetch & compile the source. (e.g. KeePassXC .. although maybe it wasn't cached because other users would install programs like that from casks).
> Do you need to edit the “recipes” a lot or do they generally Just Work?
Mostly it works. The
Read the rest
caveats:
- I have run into a case where some test failed because of path length limits(?). I worked around that by skipping the test.
- I'd guess the order of popularity of community usage is "NixOS > other Linux > macOS > other". Some packages might be able to work on macOS, but either have metadata marked as linux-only, or don't take care of (maybe) macOS specific needs. (e.g. It's been fixed, and the workaround wasn't difficult before that, but I'd run into this https://github.com/NixOS/nixpkgs/issues/56348).
- Nix is weird; so, sometimes when it's not doing what you want, it can be difficult to figure out what it is you have to do. (So, you can fall-back and use homebrew or whatever).
I recently packaged fq (written in Go) in Nixpkgs[0] and it was a breeze. You just have to specify the vendor and source hashes (which can be done automatically), and you get reproducibility for free (at least in the build environment.)
[0] https://github.com/NixOS/nixpkgs/pull/151871/files
In Bingo – The missing package manager for Go binaries (Homebrew for “go install”)Wow! I can't believe I've never noticed that. For many years, the only graphical installation disk was based on Plasma, and I think it also had that tag. NixOS only started shipping a GNOME iso for installation purposes a little over a year ago (for 20.09), and I kinda never noticed.
Looks like the main reason GNOME is recommended for installation media at the moment is that it does a better job of autodetecting HiDPI displays, and then scaling appropriately: https://github.com/NixOS/nixos-homepage/pull/643
There are also some packaging issues for Qt with NixOS, because Qt plugins fundamentally rely on ‘impurity’ at runtime, and the Qt framework makes promises it doesn't keep about binary compatibility.
Here are some of the relevant issues for historical context and some of the tradeoffs Nixpkgs developers have faced when it comes to hand
Read the rest
ling Qt and KDE packaging:
https://github.com/NixOS/nixpkgs/issues/86369
https://github.com/NixOS/nixpkgs/pull/54525
https://github.com/NixOS/nixpkgs/pull/44047
I realize that may not be a fully satisfying answer as to why the GNOME-based installation graphical ISO is recommended over the Qt one because one can imagine that the Qt packaging issue should be resolved some other way, or see the difficulty of packaging Qt plugins and applications in Nixpkgs as fundamentally a Nix defect. But I hope it makes that decision make more sense.
FWIW, afaict Plasma is the more popular of the two major DEs on NixOS, and it's what I've always used on NixOS myself, including now. It is definitely usable.
I think it's more common practice to use Apple's frameworks on macOS and GNUStep on Linux. At least, that's what unar [1] and the Hopper Disassembler [2][3] does. That's probably the reason why GNUStep is absent in Homebrew.
[1]: https://github.com/NixOS/nixpkgs/blob/1cfd83e859002d1f053bb3...
[2]: https://github.com/NixOS/nixpkgs/blob/a0dbe47318bbab7559ffbf...
[3]: https://github.com/NixOS/nixpkgs/blob/a0dbe47318bbab7559ffbf...
In GNUstep: Open-source, Object-oriented, Cross-platform Development EnvironmentI made https://github.com/NixOS/nixpkgs/pull/149523 to kick off
nix-build -A pkgsStatic.llvmPackages.clang-unwrapped
Which built all the other deps just fine, but failed buildling LLVM with CONFIGURE_LLVM_NATIVE. That seems easy enough to fix, as that's the regular part, though.
No guarantee there wouldn't be other more serious issues lurking beneath, but we've attempted quite a lot of static builds of complicated thing, augmented Musl with various bits and scraps to make it more featureful.
You gave a very nice intro for my talk, saying Nixpkgs could well be the future so check it out. Well, I hope that future can arive more widely soon :).
In A proposal to start “llvm-libc” (2020)Nixpkgs has a PR for replacing the build environment of packages with uutils-coreutils[0]. From testing by building various packages over a dozen bugs were reported upstream, but a lot of software does build successfully with uutils[1][2], after upstream fixes, including chromium, vlc, nix, rustc, emacs, vim, uutils itself etc.
It's an interesting experiment to replace such a fundamental dependency with a rewrite. A lot of the build failures are due to uutils not implementing GNU extensions, some of which can get pretty involved.
[0] https://github.com/NixOS/nixpkgs/pull/116274
[1] https://github.com/NixOS/nixpkgs/pull/116274#issuecomment-85...
[2] https://github.com/NixOS/nixpkgs/pull/116274#issuecomment-86...
In Uutils: an attempt at writing cross-platform CLI utilities in RustAs sibling comments mention, this would struggle with edge-cases, and require too much buy-in from packagers.
A less ambitious approach would be creating/extending a static analyser/linter for Nix (there are already a few out there). This could nudge packagers towards certain styles, which language implementations could optimise for.
For example, an interpreter could have multiple implementations of the attrset interface (key/value mappings) with different performance characteristics, using some default for literals like '{ foo = "bar"; }' and a specialised version for known use-cases like nixpkgs.lib.nameValuePair ( https://github.com/NixOS/nixpkgs/blob/e9e53499b26ad98ac97f97... ) (mentioned in a sibling)
Linters could then spot when such functions are appropriate, e.g.
Found literal name/value pair on line 123:
{ name = "x"; v
Read the rest
alue = "y"; }
This can be slow, consider using:
nixpkgs.lib.nameValuePair "x" "y"'
I am frustrated that you ignored my main argument about Docker sufficiently serving the same business function as Nix, with lower maintenance. Instead you focused on a semantic argument about one word in my post - "reproducible". You have the wrong idea about reproducibility, where you say basically everything that is not Nix or Guix is not reproducible. This ignores things like conda and techniques like package version pinning that allow researchers and businesspeople to get the same results from the same code. Here's a definition of "reproducible" from Wikipedia:
Any results should be documented by making all data and code available in such a way that the computations can be executed again with identical results.
https://en.wikipedia.org/wiki/Reproducibility
-----
> To be clear, are you suggesting that
> RUN sudo apt-get update && s
Read the rest
udo apt-get -y install ...
No, you need to pin the dependency versions. With Python this practice is already normalized with requirements.txt or conda yml files. So you would take an existing project and do:
RUN conda env create -f environment.yml
which would likely be copy-pasted from the project README. The yml file specifies version numbers for dependencies. The SAT solver is deterministic. For other languages like C maybe the project didn't specify dependency version. So you need to figure them out when you first get a successful build, then specify their versions in apt. You can specify version numbers in the apt-get install line.
Yes, this is reproducible. Definitely good enough for most business use cases. When I say reproducible I do not mean ivory tower math proof reproducible. I just mean that the code will run on the relevant machines they are targeting. As I wrote in my initial comment. And as I defined at the top of this comment.
Also Nix provides a worse experience for pinning dependency versions since it does not have a native concept of version numbers [0]. Instead people have to grep through the Nixpkgs repo to find the correct hash of their dependency version.
> This is even more true for Nix, which has the largest and most up-to-date package repositories out there
No, Docker has the closure (to borrow Nix's terminology) of all of the package managers in that graph. If you add the height of the Debian packages with Pypi and Hackage you already have Nix beat. You can keep adding - cargo, ruby gems, etc all in their native package managers. If Nix were better off then people would be adapting Nix packages to other ecosystems. But the reality is the other way around.
> Plus, with Nix, you can easily make a new package based on existing packages with a mere few lines of code if the existing packages doesn't fit your needs. Other package managers besides Guix doesn't offer you that flexibility so you'd have to compile from scratch
With Nix, you are forced to make new packages based on existing packages. That is not a benefit. Regarding "if the existing packages doesn't fit your needs", compiling from source is not a big deal since Docker caches output artifacts.
[0]: https://github.com/NixOS/nixpkgs/issues/93327
NixOS has it packaged, reproducibly I presume?
https://github.com/NixOS/nixpkgs/blob/8a308775674e178495767d...
In Google Chromium, sans integration with GoogleNice move. Any will/energy to self-host instead of using sr.ht?
https://man.sr.ht/packages.md lists Alpine Linux and Arch Linux as best distributions for Sourcehut, there's also Debian though the maintainer wants help https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C2021062220010... ,
and NixOS, but the services part still needs more PR reviews: https://github.com/NixOS/nixpkgs/pull/133984 (full disclosure, I'm the author of this PR)
In Code.gouv.fr: Why Etalab's Free Software Pole Uses Sourcehut> wrapper script to set up LD_LIBRARY_PATH, or custom derivation to patch their ld lib paths.
There is your problem, I don't want to spend time writing wrapper scripts, or researching how to craft my buildFHS for every little piece of software I will run once for an oddly specific purpose.
Running the proprietary VPN on Arch Linux was as simple as running debtap, and then installing the package via pacman, even though the package shipped by the vendor was made for Ubuntu. It even figured out the dependencies automatically.
I know I could do the same thing on NixOS, but it would be way more clunky and time consuming. For example: this is how a package is installed from a .deb using nix: https://github.com/NixOS/nixpkgs/blob/nixos-19.09/pkgs/tools...
If Arch can do it in two commands, so should NixOS, just with two lines of nix :)
In How to Learn NixNo experience with ruby but nixpkgs has sections for many languages. See ruby: https://github.com/NixOS/nixpkgs/blob/master/doc/languages-f.... Also a quick search on the NixOS wiki gives this: https://nixos.wiki/wiki/Packaging/Ruby.
This is less packaging related (more nix lang related) but here is my go to resource for functions: https://teu5us.github.io/nix-lib.html. teu5us extracted the builtin/lib function docs and put them on one place saving you from having it split up into multiple manuals.
One issue with nix is the content has been written down it’s very inaccessible. It is split up between blog posts, discourse, nixpkgs code comments, the wiki, Reddit, etc. When working on something in nix I’ll frequently have 10+ sources of information. The google-fu needed is strong.
My biggest recommendation is to dive into the nixpkgs repo
Read the rest
and other public dotfiles as most likely what you are doing has been done.
I experimented with something similar with a Linux distribution's package binary cache.
Using `bup` (deduplicating backup tool using git packfile format) I deduplicated 4 Chromium builds into the size of 1. It could probably pack thousands into the size of a few.
Large download/storage requirements for updates are one of NixOS's few drawbacks, and I think deduplication could solve that pretty much completely.
Details: https://github.com/NixOS/nixpkgs/issues/89380
In Elfshaker: Version control system fine-tuned for binaries"If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong" still applies, even though we now type chacha20. https://people.eecs.berkeley.edu/~daw/teaching/cs261-f12/mis...
We should aim for not having to fiddle with SSH config, and having sane defaults.
That could involve:
* cryptographers advocating changing OpenSSH defaults
* people refining their threat model to being able to accept weaker defaults
* Distributions or config management solutions that improve on the defaults in a careful considered way.
I use NixOS which generates my sshd_config. By default, NixOS:
* Disables root login via password: https://github.com/NixOS/nixpkgs/blob/8605fbd737e526c40ff8f0...
* Sets ciphers according to Mozilla's recommendations: https://github.com/NixOS/nixpkgs/blob/8605fbd737e526c40ff8f0...
Other distros, cfgmgmt, and container syst
Read the rest
ems could do this too.
> Sounds a lot like Nix's philosophy of totally sandboxed/declarative package builds
They are similar but I think of Nix as being closer to Dockerfiles than to Bazel. Nix describes how to compose and build things, of multiple build systems, in a unixy environment. It sandboxes things and runs commands in those things like `make install` and then pulls the files those commands generates out and uses them for other things. This is very close to how people use Dockerfiles but very different to how someone would go about using Bazel. Bazel's main selling points are that it allows you to describe how your software is built by using application level concepts. Bazel has `library`, `binary`, and `test`. Regardless of what the language we're talking about any two programmers will probably know what these high level concepts mean and, due to conve
Read the rest
ntions in rules, any developer - regardless if they have experience in the language in question - can understand what is going on.
Bazel is also much finer grained than something like Nix. For example, the NixPkg for abseil-py is defined here: https://github.com/NixOS/nixpkgs/blob/nixos-21.05/pkgs/devel...
The BUILD files for abseil-py are found in the repo. Something you'll notice is that there isn't a single build target for all of abseil-py. Instead, each python module or "library" has it's own target: https://github.com/abseil/abseil-py/blob/master/absl/BUILD#L...
This allows for some cool stuff when deploying your software. Suppose you import just the flags module from this repo. That means that your built `py_binary` artifact will only contain just the modules that you're actually importing. You can also see the dependancy graph for all of your source code by talking to Bazel's query API. Find a bug in a library? You can now instantly query every single `binary` that those source files went into without false positives. That's just an example of something you may want to do but really you now have a way to query the dep graph for all languages and tools so the sky is the limit.
> instead of needing a monorepo with every piece of software you can just grab a reproducible build from nixpkgs
You also don't need a monorepo for Bazel to work. You can use `http_archive` or `git_repository` to load specific WORKSPACEs. For example: https://abseil.io/docs/cpp/quickstart#set-up-a-bazel-workspa...
Also bzlmod is being worked on (a package manager that automates this stuff). This also has provisions for running all of the `_test` targets on deps after they're compiled by your toolchain and on your hardware. This validates that all importing and compiling worked as expected (which most build systems can't accommodate).
Showing the 15 most recent of 112 sources. Enable JavaScript to search and browse every indexed mention.