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, 5:05:26 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
72 sourcesNix actually has far better than average documentation compared to other typical open source projects. I started using Nix years ago on Ubuntu to quickly install a package that wasn't present in Ubuntu's repository. Eventually, I began customizing packages using Nix expressions. Before I knew it, I migrated my existing systems over to NixOS. What I can say is it wasn't at all the uphill struggle that's associated with Nix in online discussions. Even though the documentation isn't perfect and going through active improvements, there's a considerable gap between Nix's reputation regarding documentation and my own actual experience.
What surprises me is that people tout RPM/Chef as easier replacements to Nix/NixOS. The assumption about those being "replacements" of each other is questionable because they address different needs. What's even
Read the rest
more questionable is the part about RPM or Chef being easy. I have dealt with those two for years as part of my day job, and they're both far from easy. I still have troubles with them to this day. Documentation is far more lacking than Nix, and it's not because things are obvious. If you encounter any trouble, you almost always have to dive into the source code. Navigating the source code of RPM or Chef is a nightmare because the code is scattered across countless different repositories and it's impossible to guess where to look for to begin with. Choice of programming languages doen't help here too. Chef is written in Ruby, which has a tendency of making code ungreppable due to its metaprogramming features. RPM has its own macro syntax which works similar to the C preprocessor. It's very terse and full of gotchas. Navigating around Nix code is much, much easier in comparison. Everything you need is in a single repo, https://github.com/NixOS/nixpkgs, and written in a JSON-like language.
Many people also claim that Nix is hard because it requires a functional programming background. That too doesn't match my experience. Nix expressions are basically JSON with functions. Learning the syntax is a non-issue if you know JSON and some common programming language constructs like conditionals, functions, map, filter and reduce. The only functional programming exposure I had prior to Nix was LISP, in a university classroom. Yet I didn't experience problems learning the syntax. The hard part is learning how to actually utilize the language. The documentation and some grepping around of the Nixpkgs codebase helped a lot with this.
I've had to resort to doing the same a lot of the time as I await the merge process. Even after merge, it may take Hydra 3 days to get your changes from the default branch to even nixos-unstable for general usage. I find a fork a bit easier than piling overlays and forgetting to move on from them.
My favorite was when the GNOME ISOs got so bloated it no longer fit on a DVD size-wise and nothing could move to unstable for over a week while folks hem and hawed about what to do with that situation. Not saying a little bikeshedding + solution digging isn't good for the long-term, but it seemed so odd that this was preventing anything from going to unstable. (https://github.com/NixOS/nixpkgs/issues/159612)
In Nix and NixOS, my pain pointsIt still doesn't have a concept akin to use-flags, which is what distinguishes Gentoo from Linux from Scratch, see https://github.com/NixOS/nixpkgs/issues/12877. The fact that Nix doesn't have these is also one reason why it's easier to cache than Gentoo packages.
In Nix on the Steam DeckFinding a way to install a specific version - not git commit or git tag, version - of a package is the problem.
https://github.com/NixOS/nixpkgs/issues/93327
Nix before flakes used channels, each with a flat global namespace. Flakes are intended to sit inside the git repo, so that's even less discoverable.
Nix solves practically every technical problem, but has terrible UX and documentation.
In Devbox 0.2.0: Automatic Nix installer, plugins, and background servicesThere's often a bunch of different versions in nixpkgs. For example, postgres currently has 11 through 15 available (https://github.com/NixOS/nixpkgs/blob/e7f345ca81f4f5513c4e73...). Nodejs has 14, 16, 18, and 19 (https://github.com/NixOS/nixpkgs/blob/e7f345ca81f4f5513c4e73...).
In Devbox 0.2.0: Automatic Nix installer, plugins, and background servicesAnother advantage of the gomod2nix approach concerns long term build reproducibility [1]. Having each source dependency in its own derivation would make easier source code mirroring. Since Nix knows the hash of each sources, we could imagine to teach Nix how to get the source code from some other places than GitHub. For instance, Nix could use the hash of the dependency to query Software Heritage [2].
Note there is also an opened issue to restrict Nix fixed output derivation which would make impossible the buildGoModule "hack".
[1] https://github.com/NixOS/nixpkgs/issues/84826
[2] https://www.tweag.io/blog/2020-06-18-software-heritage/
In Building Go programs with Nix flakesNo.
A main reason people use containerisation is to work around the problem that different versions of libraries and binaries cannot coexist in classical Linux distributions. This problem does not exist in NixOS.
The services are declared as NixOS modules, which manifest as plain systemd services on the server.
Systemd has its own set of options for resource/security isolation, and some NixOS modules use them where possible, for example: https://github.com/NixOS/nixpkgs/blob/8d559672bedd54034b711d...
In NixOS 22.11 “Raccoon”Plugging my own thing here, but I have been experimenting with a Nix configuration for gaming only. My configuration is here (for Nvidia, which does not work without tinkering as AMD does) : https://github.com/jhvst/nix-config/blob/main/nvidia.nix
First, this is a whole system specification. This means that executing this on Nix will build you a whole OS image. You can build the image if you have Nix by running the first line on file. You can also use Docker with the instruction on my README: https://github.com/jhvst/nix-config (however, kexec will not likely work, read more how to run it later)
Back to elaborating on the Nix file from the gaming perspective. First, we have the overlays. These are like patches to the packages, and really useful for gaming because it allows building important packages like mesa from the source tip. This is
Read the rest
particularly useful when new games or GPUs are released. Same thing for wayland: Nvidia and its proprietary drivers need some patching, but it's possible to get wayland (and sway) to work this way.
Then, I have taken the reproducibility of Nix to a next step in my opinion, and made the system stateless. This means that it runs from the RAM. It is easy to create installation media like kernel, initrd, and rootfs because you have all the steps to create the distribution. This means that here, Nix works as a meta-distro like Gentoo, on top of which you develop your own. Running from the RAM means that theoretically, if you have a working config, and two people with different hardware runs it, then they should have the same experience. If you look at ProtonDB, you often find that some people claim that game X works on their machine with drivers and mesa of Y and Z, but there is no way to copy their configurations because it's certain that the user has made some stateful changes which they have forgotten hence left undocumented, which is the reason it works for them. If everyone would be using Nix, you could reproduce their system and possibly fix your own, but this is not tractable with most OSs.
If you like to test my changes, you can read more about my approach here: https://github.com/NixOS/nixpkgs/pull/203750
For testing I distribute Nvidia as documented here: https://github.com/jhvst/jhvst.github.io/blob/main/ramdisk.m...
However, I have developed it bit further: if you manage to get into an iPXE shell, you can write `boot -a http://boot.ponkila.com/menu.ipxe`, then select the second option which is Nvidia (proprietary drivers), and with some waiting you will get into a shell prompt to which you can write `sway --unsupported-gpu`, which will launch sway. Cmd+Enter opens a prompt to which you can write `steam`, which will open Steam. Then, you have to mount some drive on another shell with `mount`, and add this as a Steam library via Steam's UI. Then you can play games. I use this on AMD and I have been very happy.
To get iPXE, the easy option is to go along with https://netboot.xyz. You will find the `iPXE shell` option here to which to write the boot option from the previous paragraph.
I also added AMD to the iPXE menu for whomever decides to test it. Sway is launched by writing `sway`. Steam should be started with `AMD_VULKAN_ICD="RADV" VK_ICD_FILENAMES="/run/opengl/driver/share/vulkan/icd.d/radeon_icd.x86_64.json" steam` to use the faster RADV driver.
If it's an Intel iGPU + an Nvidia dGPU setup beware there's a bug with the implementation of the Nvidia driver currently which breaks connecting external displays on X11 depending on your hardware. See https://github.com/NixOS/nixpkgs/issues/199024 and the comments of https://github.com/NixOS/nixpkgs/pull/165188.
Also setting Coolbits doesn't seem to work either on my end, which means no overclocking support for the Nvidia GPU (if that's something you care about).
In NixOS 22.11 “Raccoon”I started working on https://github.com/NixOS/nixpkgs/pull/82131 because the idea that different kernel => reshuffled userland is a stupid an a massive source of unneeded switching costs.
I am not mad at Linux, but monoliths at the 10M LoC order always need competition. Otherwise we have a major source of unchecked complexity growth with no escape.
In Migrate from Linux to FreeBSD> Several applications that were apparently built for Linux, so they did not compile on Freebsd (and no alternatives available).
There's a PR hopefully landing soon in nixpkgs to add freebsd building: https://github.com/NixOS/nixpkgs/pull/82131
I was wondering if there's a builder at some point, it may improve the compatibility for the whole ecosystem. There's definitely a lot of fixes going upstream from darwin build failures.
In Migrate from Linux to FreeBSDAlas, nixos does not support homed:
https://github.com/NixOS/nixpkgs/issues/91243
In Hard User Separation with NixOSNixOS 22.11 – Release schedule #193585
3 points · Open discussionThe NixOS update has some details: https://github.com/NixOS/nixpkgs/pull/198999
### Changes between 3.0.6 and 3.0.7 [1 Nov 2022]
* Fixed two buffer overflows in punycode decoding functions.
A buffer overrun can be triggered in X.509 certificate verification,
specifically in name constraint checking. Note that this occurs after
certificate chain signature verification and requires either a CA to
have signed the malicious certificate or for the application to continue
certificate verification despite failure to construct a path to a trusted
issuer.
In a TLS client, this can be triggered by connecting to a malicious
server. In a TLS server, this can be triggered if the server requests
client authentication and a malicious client connects.
An attacker can craft a malicious email address to overflow
an arbit
Read the rest
rary number of bytes containing the `.` character (decimal 46)
on the stack. This buffer overflow could result in a crash (causing a
denial of service).
([CVE-2022-3786])
An attacker can craft a malicious email address to overflow four
attacker-controlled bytes on the stack. This buffer overflow could
result in a crash (causing a denial of service) or potentially remote code
execution depending on stack layout for any given platform/compiler.
([CVE-2022-3602])
*Paul Dale*
Showing the 15 most recent of 72 sources. Enable JavaScript to search and browse every indexed mention.