https://github.com/CuBeRJAN/nix-problems Skip to content Toggle navigation Sign up * Product + Actions Automate any workflow + Packages Host and manage packages + Security Find and fix vulnerabilities + Codespaces Instant dev environments + Copilot Write better code with AI + Code review Manage code changes + Issues Plan and track work + Discussions Collaborate outside of code Explore + All features + Documentation + GitHub Skills + Blog * Solutions For + Enterprise + Teams + Startups + Education By Solution + CI/CD & Automation + DevOps + DevSecOps Resources + Customer Stories + White papers, Ebooks, Webinars + Partners * Open Source + GitHub Sponsors Fund open source developers + The ReadME Project GitHub community articles Repositories + Topics + Trending + Collections * Pricing Search or jump to... Search code, repositories, users, issues, pull requests... Search [ ] Clear Search syntax tips Provide feedback We read every piece of feedback, and take your input very seriously. [ ] [ ] Include my email address so I can be contacted Cancel Submit feedback Saved searches Use saved searches to filter your results more quickly Name [ ] Query [ ] To see all available qualifiers, see our documentation. Cancel Create saved search Sign in Sign up You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. {{ message }} CuBeRJAN / nix-problems Public * Notifications * Fork 0 * Star 33 The many issues plaguing Nix License GPL-3.0 license 33 stars 0 forks Activity Star Notifications * Code * Issues 0 * Pull requests 0 * Actions * Projects 0 * Security * Insights More * Code * Issues * Pull requests * Actions * Projects * Security * Insights CuBeRJAN/nix-problems This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository. main Switch branches/tags [ ] Branches Tags Could not load branches Nothing to show {{ refName }} default View all branches Could not load tags Nothing to show {{ refName }} default View all tags Name already in use A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch? Cancel Create 1 branch 0 tags Code * Local * Codespaces * Clone HTTPS GitHub CLI [https://github.com/C] Use Git or checkout with SVN using the web URL. [gh repo clone CuBeRJ] Work fast with our official CLI. Learn more about the CLI. * Open with GitHub Desktop * Download ZIP Sign In Required Please sign in to use Codespaces. Launching GitHub Desktop If nothing happens, download GitHub Desktop and try again. Launching GitHub Desktop If nothing happens, download GitHub Desktop and try again. Launching Xcode If nothing happens, download Xcode and try again. Launching Visual Studio Code Your codespace will open once ready. There was a problem preparing your codespace, please try again. Latest commit (l () nil) update incorrect information ... e72df51 Aug 11, 2023 update incorrect information e72df51 Git stats * 7 commits Files Permalink Failed to load latest commit information. Type Name Latest commit message Commit time LICENSE Initial commit May 5, 2023 21:03 README.org update incorrect information August 11, 2023 18:10 View code [ ] Introduction Internal design issues Internal inconsistencies/issues Build system issues Language issues Debugging Package QC issues Missing features User experience issues Documentation nix-env Generally bad UX Conclusion README.org Introduction Let's talk about some of the issues with Nix and NixOS, and how Guix does these things better. I'll say upfront that you shouldn't expect tons of examples - this is a fairly quick writeup, though I might come back later to revise sections and add more points. Internal design issues Internal inconsistencies/issues Build system issues Guix uses so called build systems - these ensure consistency in how packages are actually built across different toolchains and language ecosystems. * Each package ecosystem has its own build system. These define certain dependencies and standard procedures used for handling packages within that ecosystem. + Examples would include the Maven and TeX Live ecosystems. + This ensures consistency within these ecosystems. * All of these build systems are in a single place (see points below) - this helps keep the different build systems consistent in behaviour. + https://github.com/guix-mirror/guix/tree/master/guix/build + https://guix.gnu.org/manual/en/html_node/Build-Systems.html * Combined these ensure global consistency in the approaches used for handling different toolchains across all the definitions. * Nix does have build phases, and even something similar to build systems, but... + These build systems aren't documented anywhere, at least as far as I could tell. + They are scattered all over nixpkgs. o This makes the entire point about consistency void. Language issues * All Guix package definitions are written exclusively in GNU Guile - a Scheme implementation + While system calls do need to be invoked for certain builds, it's done exclusively with Guile too. o There is a mature and well documented set of different build utilities used to do this. # These also make package transformations more straightforward using the flexibility of Scheme macros. o For example rather than calling a sed within a shell script like what Nix definitions sometimes do, Guix uses the procedure substitute* instead. # This keeps build scripts consistent with a single set of build utilities and a single language. * Now for the Nix language. + It's poorly documented. + The tooling is lacking, in part because it's used pretty exclusively for Nix. + It isn't particularly good as a DSL (note: domain specific language). Why? o A proper DSL is not flexible enough for functional package management, so it was an uphill battle from the start. o It's too complicated - the main point of DSLs is to simplify configuration. o Quote from the "inventor" of the language 1: TLDR: the Nix language has all the problems of a general purpose language (namely too much expressiveness, allowing people to build new abstractions that make it harder for other people to understand their code, and making evaluation slow), while not having the features you would expect from a general purpose language, and at the same time not having many domain-specific features (indeed string contexts are one of the few). So it's not that great as a DSL or a GPL. + It isn't good as a general purpose language either (no libraries, no interest in using it outside of Nix). + There exist attempts to address these issues with different languages, for example Nickel has such aspirations. o I recommend reading this blogpost, it goes over some of the issues of Nix. + Guix addresses these issues by using a language that's properly general purpose and more flexible with its very powerful macro system. o Guix's init system, GNU Shepherd is also written in Scheme, along with the entire CLI interface and every other part of the Guix system, aside from the daemon - further proving it's capability as a GPL. Debugging * Nix is also known for being rather difficult to debug (see discussion here). + Recursion is used heavily - in practice this makes stuff like copying objects rather difficult. o Infinite recursion can be difficult to debug and is rather easy to introduce - see below. + https://nix.dev/anti-patterns/language Package QC issues * Nixpkgs commits aren't signed - see NixOS/rfcs#100 (at least it's being worked on... slowly). * Overall quality of definitions in Nixpkgs isn't always great - many R packages are autogenerated and thus broken. + Many packages also aren't bootstrapped properly, instead patching and repackaging .deb packages and the like. o Guix focuses on proper bootstrapping heavily. + These is a ton of patching going on to resolve FHS incompatability issues (Guix is also affected by this). * Nixpkgs is unreliable - this speaks for itself... Missing features First of all grafts. What are they? Grafts are Guix' way of not rebuilding the world when an important security is rolled out. Basically, they allow you to build and link against old versions of a library while running the program against a new one. Traditional distros do that all the time and you don't even notice, but on Guix you actually have two versions of that library still lying around. The ungrafted one and the grafted one. - Guix documentation [DEL:To my knowledge Nix has no such thing.:DEL] * Thank you to user dali99 for correcting me here - Nix does in fact have a mechanism similar to Guix's grafts, however it isn't used and it doesn't seem recursive application is supported either. [DEL:Nix also doesn't have an equivalent to ~guix pack~.:DEL] * https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack.html * https://guix.gnu.org/blog/2023/ the-filesystem-hierarchy-standard-comes-to-guix-containers/ * Nix does in fact have nix bundle now as a part of the flake CLI (thanks again to dali99 for the correction). User experience issues Documentation * As I have mentioned multiple times before, the Nix documentation is infamously bad, see the blogpost below. + https://ostina.to/posts/ 2019-03-29-why-nixos-is-hard-and-how-to-fix.html * The Nix manual is also comparatively poor compared to what Guix offers (which includes a "cookbook" full of examples) + https://nixos.org/manual/nix/stable/ + https://guix.gnu.org/en/manual/en/guix.html + https://guix.gnu.org/en/cookbook/en/guix-cookbook.html nix-env * nix-env is considered bad by a big part of the community (1) (2). Yet the documentation doesn't mention any of it's shortcomings and it doesn't exactly have a great replacement. + nix-env has a problem with RAM usage, it's extremely inefficient. + What should we use instead? o flakes are experimental and not all too well documented ( 1). o nix profile isn't quite a 1/1 replacement and lacks documentation (1). o home-manager? Has it's own issues. It's also not well documented. # besides that, some people don't want to use it - using an entire complex system like this to replace nix-env is silly. Generally bad UX * Many tools are considered deprecated, yet are kept around for legacy compatability and referenced in the documentation, or they don't have good replacements (see nix-env section above). + Searching for packages can be done using nix-env - but it's extremely slow as it lazily evaluates the entire package database. o There's a new experimental method, it's better as it uses caching but it's far from perfect. o Guix has a proper search implementation. + The CLI experience is bad (this issue is closed, but it's far from resolved in practice) - many different tools all behaving differently, all with their own pitfalls and "gotcha"s. o There's usually multiple approaches for one task. o There's third party tools trying to clean the experience but many of these only make the issue worse by further splitting the efforts. (1 2 3) Conclusion WARNING: opinionated conclusion! Overall Nix is a very flawed piece of software and far inferior to Guix. Years and years of technical issues plague the project and there seems to be little interest in actually resolving these issues. Guix is comparatively much newer, yet the UX is much better and there are constant improvements in many areas. It also has the advantage of being built from the ground up with a clear design mind. This isn't the complete document, I might come back and add more - for now I have already spent too long on this, and I think I outlined many of the issues rather clearly. If you find incorrent information please contact me and I'll be happy to correct myself :)! About The many issues plaguing Nix Resources Readme License GPL-3.0 license Activity Stars 33 stars Watchers 4 watching Forks 0 forks Report repository Releases No releases published Packages 0 No packages published Contributors 2 * @CuBeRJAN CuBeRJAN (l () nil) Footer (c) 2023 GitHub, Inc. Footer navigation * Terms * Privacy * Security * Status * Docs * Contact GitHub * Pricing * API * Training * Blog * About You can't perform that action at this time.