The many issues plaguing Nix(github.com)
github.com
The many issues plaguing Nix
https://github.com/CuBeRJAN/nix-problems
14 comments
There are some efforts underway to address the people problems in the Nix community; empowering the various teams, spreading out knowledge among more people, making it easier to participate. In fact, this is a current topic of discussion; trying to better understand the blockers and address them: https://discourse.nixos.org/t/where-did-you-get-stuck-in-the...
I don't think sway plans to support xmodmap, but it does support custom XKB layouts.
https://github.com/swaywm/sway/issues/4250
https://github.com/swaywm/sway/issues/4250
The idea of Nix is quite solid--controlling your dev environment is a good thing.
The implementation of Nix feels extremely shaky. Nix has genuine deficiencies that several different projects all attempt to address. When you have to patch things at the level of ELF, your basic architecture needs work.
The project management of Nix feels like a disaster. For example, when fixing the basic, inscrutable error message for the fact that your "flake.nix" hasn't been checked into version control has been extant for two years in spite of people handing you PRs, something is broken in your project.
The implementation of Nix feels extremely shaky. Nix has genuine deficiencies that several different projects all attempt to address. When you have to patch things at the level of ELF, your basic architecture needs work.
The project management of Nix feels like a disaster. For example, when fixing the basic, inscrutable error message for the fact that your "flake.nix" hasn't been checked into version control has been extant for two years in spite of people handing you PRs, something is broken in your project.
> When you have to patch things at the level of ELF, your basic architecture needs work.
May I ask why? It might sound uncommon, but that doesn't mean it's wrong. Nix only patches pre-built binaries targeting other distros. It patches the expected path of shared libraries so that the patched binaries can use versions of libraries that work best.
This is not even a Nix thing. It's standard practice when packaging pre-built binaries. You can see this for yourself in Debian code search:
https://codesearch.debian.net/search?q=patchelf&literal=1
All Nix does is automate the process that other distros end up doing anyways.
> The project management of Nix feels like a disaster
That's not a fair take when the reason for that is a single issue you care about not being fixed fast enough. Nix has merged 41 PRs in the past month alone, so it's not like there hasn't been any progress. The devs are doing the best they can with the resources available.
https://github.com/NixOS/nix/pulse/monthly
May I ask why? It might sound uncommon, but that doesn't mean it's wrong. Nix only patches pre-built binaries targeting other distros. It patches the expected path of shared libraries so that the patched binaries can use versions of libraries that work best.
This is not even a Nix thing. It's standard practice when packaging pre-built binaries. You can see this for yourself in Debian code search:
https://codesearch.debian.net/search?q=patchelf&literal=1
All Nix does is automate the process that other distros end up doing anyways.
> The project management of Nix feels like a disaster
That's not a fair take when the reason for that is a single issue you care about not being fixed fast enough. Nix has merged 41 PRs in the past month alone, so it's not like there hasn't been any progress. The devs are doing the best they can with the resources available.
https://github.com/NixOS/nix/pulse/monthly
> May I ask why?
Because it breaks the universe?
https://github.com/NixOS/nixpkgs/issues/24744
https://discourse.nixos.org/t/using-mold-as-linker-prevents-...
And presumably this rattles into glibc vs musl, too.
patchelf is a working hack short term, but what's the long term solution? There is no long term plan as far as I can tell.
> That's not a fair take when the reason for that is a single issue you care about not being fixed fast enough. Nix has merged 41 PRs in the past month alone, so it's not like there hasn't been any progress. The devs are doing the best they can with the resources available.
That's just the most visible to newbies and one of the most popular of the errors. When a Nix tutorial has to go out of it's way to point out the inscrutable error message as well (see: https://fasterthanli.me/series/building-a-rust-service-with-...) and it's still not fixed--well, that speaks volumes.
When flakes can't get either killed, fixed, or stabilized after how long, that speaks volumes.
Nix has more than a few deficiencies. Nix flakes also has a quite a few deficiencies. And the most recent announcement just simply kicks the can down the road.
The problem is that project management doesn't seem to be able to corral things sufficiently to make progress rather than just gaining more problems on a rewrite (flakes and the new command line).
I mean, if a simple error message change can sit open for more than a year, is there really any hope for fixing anything truly substantial?
Because it breaks the universe?
https://github.com/NixOS/nixpkgs/issues/24744
https://discourse.nixos.org/t/using-mold-as-linker-prevents-...
And presumably this rattles into glibc vs musl, too.
patchelf is a working hack short term, but what's the long term solution? There is no long term plan as far as I can tell.
> That's not a fair take when the reason for that is a single issue you care about not being fixed fast enough. Nix has merged 41 PRs in the past month alone, so it's not like there hasn't been any progress. The devs are doing the best they can with the resources available.
That's just the most visible to newbies and one of the most popular of the errors. When a Nix tutorial has to go out of it's way to point out the inscrutable error message as well (see: https://fasterthanli.me/series/building-a-rust-service-with-...) and it's still not fixed--well, that speaks volumes.
When flakes can't get either killed, fixed, or stabilized after how long, that speaks volumes.
Nix has more than a few deficiencies. Nix flakes also has a quite a few deficiencies. And the most recent announcement just simply kicks the can down the road.
The problem is that project management doesn't seem to be able to corral things sufficiently to make progress rather than just gaining more problems on a rewrite (flakes and the new command line).
I mean, if a simple error message change can sit open for more than a year, is there really any hope for fixing anything truly substantial?
> Because it breaks the universe?
It does not. People use packages that has binary patches applied all the time, and they work just fine.
The issues you linked to refers to a fixable issue that's completely unrelated to binary patching. It's what happens when you directly use the linker without supplying the required flags.
> patchelf is a working hack short term, but what's the long term solution?
Patching binaries isn't a short term solution. It's the only solution for retargeting proprietary binaries to make it run on distros it wasn't built for. Besides, making a few edits to ELF metadata isn't the end of the world. It's the universally accepted solution across distros.
> I mean, if a simple error message change can sit open for more than a year, is there really any hope for fixing anything truly substantial?
My point still stands. All software other than the most trivial ones has non-zero number of unresolved issues at any given moment in time. This is true even for software made by multi-billion dollar companies. Yet you seem to expect much more from a volunteer-run project with limited resources.
You have a legitimate point regarding flakes, except that issues are constantly being fixed. It's just that some issues you happen to care about are receiving less attention than you'd like given the limited amount of resources available.
It does not. People use packages that has binary patches applied all the time, and they work just fine.
The issues you linked to refers to a fixable issue that's completely unrelated to binary patching. It's what happens when you directly use the linker without supplying the required flags.
> patchelf is a working hack short term, but what's the long term solution?
Patching binaries isn't a short term solution. It's the only solution for retargeting proprietary binaries to make it run on distros it wasn't built for. Besides, making a few edits to ELF metadata isn't the end of the world. It's the universally accepted solution across distros.
> I mean, if a simple error message change can sit open for more than a year, is there really any hope for fixing anything truly substantial?
My point still stands. All software other than the most trivial ones has non-zero number of unresolved issues at any given moment in time. This is true even for software made by multi-billion dollar companies. Yet you seem to expect much more from a volunteer-run project with limited resources.
You have a legitimate point regarding flakes, except that issues are constantly being fixed. It's just that some issues you happen to care about are receiving less attention than you'd like given the limited amount of resources available.
That sounds like what I've always said about make. :)
s/nix/make/
I've wanted to use nix for a very long time, but every time I devote a few hours to using it, some intractable issue always stops me. Years ago it was a lack of any support for shells other than bash and zsh. I've been using fish for over a decade.
I'm sure that's been fixed, but the issue for attempting to use it again is that something else will come up. I'm not expecting it to work perfectly, but I'd prefer the bugs be small, not showstoppers.
I love the idea, having everything as config layers, but still think the process needs more iteration. Frankly, I like guix more, in theory anyways, but haven't given it a chance. Maybe it's choice paralysis, and I need to just rip that bandaid off one of these days
I'm sure that's been fixed, but the issue for attempting to use it again is that something else will come up. I'm not expecting it to work perfectly, but I'd prefer the bugs be small, not showstoppers.
I love the idea, having everything as config layers, but still think the process needs more iteration. Frankly, I like guix more, in theory anyways, but haven't given it a chance. Maybe it's choice paralysis, and I need to just rip that bandaid off one of these days
> Years ago it was a lack of any support for shells other than bash and zsh. I've been using fish for over a decade.
It used to be that running `nix-shell --package` would drop you into bash. With the newer nix command equivalent, `nix shell` retains the same SHELL.
When writing Nix packages, practically the only supported shell is bash. But, that's less of an issue, since it doesn't affect what interactive shell you use.
It used to be that running `nix-shell --package` would drop you into bash. With the newer nix command equivalent, `nix shell` retains the same SHELL.
When writing Nix packages, practically the only supported shell is bash. But, that's less of an issue, since it doesn't affect what interactive shell you use.
Really? `nix develop` still drops me into a bash shell, even though I pretty much always want to use zsh. Is there an option I have to enable somewhere?
`nix develop` is for entering an environment to build the packages, and packages are built with bash.
For "I use fish shell, and I want to load the shell.nix", it's more convenient to use direnv (which uses `nix print-dev-env`). https://github.com/direnv/direnv/wiki/nix
Another option is to use `nix develop --command fish`.
For "I use fish shell, and I want to load the shell.nix", it's more convenient to use direnv (which uses `nix print-dev-env`). https://github.com/direnv/direnv/wiki/nix
Another option is to use `nix develop --command fish`.
FWIW I use fish with NixOS with no issue. The new "nix shell" command uses the default shell, and you can use "nix develop -c fish" to get a dev shell
I will say as a nixos newbie coming from arch linux, I am seeing a lot of overlap between different functions and I'm probably not reading the docs carefully enough but I'm still sorting out the differences between nix-env, profiles, and this "home" thing which I still haven't figured out.
I get nix-shell though lol.
Probably not worth switching to guix just yet so long as I can get my emacs and cuda environment up and running.
I get nix-shell though lol.
Probably not worth switching to guix just yet so long as I can get my emacs and cuda environment up and running.
CUDA on Guix might be a challenge, I imagine.
The Nongnu repository has a package for the nvidia drivers if you need them.
I haven't used Nix but I do use Guix extensively. I love the system philosophy of both distros. Rollbacks have saved a lot of time when something went wrong (when I was already reaching for my USB rescue stick to chroot into the OS but then remembered that I could just boot the previous config from the GRUB menu!). Having the system config in a file is awesome and one ups third party configuration management tools that I have been using for years. Those tools like Puppet and Salt don't have the base OS config, so you're kind of only halfway there and you're not rolling back mistakes, you're applying new code to fix it.
As I've gotten into some Guix development lately, I've come to better understand the inspiration that Guix has taken from Nix and still does (and perhaps vice versa). I wish the Nix project the best in working through its issues (real or perceived) because I think a healthy Nix is healthy for both projects.
As I've gotten into some Guix development lately, I've come to better understand the inspiration that Guix has taken from Nix and still does (and perhaps vice versa). I wish the Nix project the best in working through its issues (real or perceived) because I think a healthy Nix is healthy for both projects.
I think fedora silverblue is far easier to get into, if your into the "safety" and portability benefits. What is Nix offering above Fedora Silverblue's model?
Nix is a package manager. NixOS makes use of the nice features of that package manager to form a systemd based OS configuration around that.
Nix has a steep learning curve, but nix ends up being useful for all sorts of things related to software packages.
Regarding NixOS, the safety of being able to do rollbacks for any system change is neat. A NixOS configuration is declarative, which means the OS' configuration can be described in a single file. (Or you can compose the OS configuration into multiple modules). -- Declaring OS configuration programmatically in a file is useful if you want to manage more than one or two machines.
That NixOS can be configured from a file also lends Nix to being a tool for building VM images. (e.g. AWS AMIs).
For software development, Nix allows for declaring a development environment such that the host will get the same versions of tools (and libraries) that are declared. -- This is immensely useful for e.g. sideprojects. This is like a more powerful version of asdf-vm.
Nix has a steep learning curve, but nix ends up being useful for all sorts of things related to software packages.
Regarding NixOS, the safety of being able to do rollbacks for any system change is neat. A NixOS configuration is declarative, which means the OS' configuration can be described in a single file. (Or you can compose the OS configuration into multiple modules). -- Declaring OS configuration programmatically in a file is useful if you want to manage more than one or two machines.
That NixOS can be configured from a file also lends Nix to being a tool for building VM images. (e.g. AWS AMIs).
For software development, Nix allows for declaring a development environment such that the host will get the same versions of tools (and libraries) that are declared. -- This is immensely useful for e.g. sideprojects. This is like a more powerful version of asdf-vm.
I myself use Fedora Silverblue with a https://ublue.it/ -based custom image, and I use home-manager for shell configuration. Sure, my GNOME layout isn't declarative, but basically everything else is. Pair that with one of the best NVIDIA driver experiences and the strong feeling of stability, it's better than most other Linuxes rn.
Nix (contrasted with NixOS) can be used on macOS as an alternative to and escape hatch from the Homebrew ecosystem.
You can safely mutate your system instead of using an immutable one.
I'm growing increasingly convinced Fedora Silverblue is the future and most end-user "noob friendly" distros will be using its model by default in 10 years.
I agree. I really like using containers for development environments. Taking that a step further to the OS is natural.
How many of us Linux users have a collection of scripts and configs to set stuff up on a new install? Let's make that stuff automatic and more robust. Seems great.
How many of us Linux users have a collection of scripts and configs to set stuff up on a new install? Let's make that stuff automatic and more robust. Seems great.
Nix the idea is great. That it works with proprietary closed source stuff is a must. Does guix support these sorts of things? How would I package up a big tar of stuff from a vendor? Patchelf and nix have some tools, although perhaps overly clever at times, for doing just that.
I think both Nix and Guix are great and ready for prime time. Everyone should test one at least
The initial installation is a standard 'next,next,next', and the result is apparently similar to a Debian installation
All distros have strengths and shortcomings
Nix support more packages natively, but guix also supports nix packages
It gives me a lot of peace having all my system defined in one file. Very easy to rollback, or re-generate in another drive. Not really worrying if the root gets corrupted or misconfigured
The initial installation is a standard 'next,next,next', and the result is apparently similar to a Debian installation
All distros have strengths and shortcomings
Nix support more packages natively, but guix also supports nix packages
It gives me a lot of peace having all my system defined in one file. Very easy to rollback, or re-generate in another drive. Not really worrying if the root gets corrupted or misconfigured
This is mostly opinions by someone who prefers Guix. Nothing better than ignoring people's opinions they spent a lot of time writing and publishing online :P what a high
I would use Guix over Nix in a second if only Guix had support for ZFS. I don't even need root or /home on ZFS, which I admit can be tricky.
Guix absolutely supports ZFS[1] without root or /home on it.
The user-space daemon for auto-mounts might take some setup, but there's a guide[2]*. I've personally gone all-in and use Guix with ZFS-on-Root, but this isn't an officially supported configuration due to an unfortunate cluster-truck[3] of an issue, and I haven't shared my configuration publicly yet (might soon for other reasons, but it's just not there yet).
1: https://packages.guix.gnu.org/packages/zfs/
2: https://www.reddit.com/r/GUIX/comments/s7qu25/guide_using_zf...
3: https://issues.guix.gnu.org/45692
*: Accessing ZVOLS through `/dev/zvol/foo/bar` takes additional setup.
The user-space daemon for auto-mounts might take some setup, but there's a guide[2]*. I've personally gone all-in and use Guix with ZFS-on-Root, but this isn't an officially supported configuration due to an unfortunate cluster-truck[3] of an issue, and I haven't shared my configuration publicly yet (might soon for other reasons, but it's just not there yet).
1: https://packages.guix.gnu.org/packages/zfs/
2: https://www.reddit.com/r/GUIX/comments/s7qu25/guide_using_zf...
3: https://issues.guix.gnu.org/45692
*: Accessing ZVOLS through `/dev/zvol/foo/bar` takes additional setup.
I'd very much like it if Nix and NixOS were rewritten with lessons learnt so far.
My impression is that Guix is sort of that, just written by a different group. Disclaimer: I haven’t used Guix yet, but I’d like to.
Yeah, but Guix shows its age too (has learned lessons unimplemented) and it’s not as usable atm afaik.
Isn’t there a way to achieve the same intended goodness that these tools aspire to with libs for plain functional languages that already exist and at battle tested?
I’ll never understand the obsession with DSLs.
I’ll never understand the obsession with DSLs.
[deleted]
While the author raises a number of legitimate points, many of them are debatable and some are just pure hyperbole.
> Guix uses so called build systems ... 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.
Nix has stdenv.mkDerivation and various functions based on it in Nixpkgs. Documentation leaves a lot to be desired, but they do at least exist in the Nixpkgs manual:
https://nixos.org/manual/nixpkgs/stable/#part-builders
> All Guix package definitions are written exclusively in GNU Guile - a Scheme implementation. ... For example rather than calling a sed within a shell script like what Nix definitions sometimes do, Guix uses the procedure substitute* instead.
Nixpkgs does use Nix functions to abstract away shell commands, but it doesn't attempt to replace shell commands entirely. Since build scripts are generally based on shell commands, I find the Nix approach of making it easy to embed shell commands reasonable.
> Now for the Nix language. It’s poorly documented. ... It isn’t particularly good as a DSL
I disagree with this assessment. Nix the language is a very small and conceptually simple language. It's basically JSON with functions. Its main competitor is JSON and YAML, and Nix does a far better job at describing complex data than those two.
The Nix language is documented in the Nix manual. Since the language is small, the relevant section is a quick read and easy to understand.
https://nixos.org/manual/nix/stable/language/
In contrast, Nixpkgs, the standard library of sorts, took more time to understand. But I soon figured out that grepping the Nixpkgs repository generally turns up many useful samples.
> Many packages also aren’t bootstrapped properly, instead patching and repackaging .deb packages and the like.
I can't find a source for this claim. I grepped the entire Nixpkgs repo for references to .deb or .rpm files. There certainly are packages that repackage them, but they're for proprietary software. There's no other possible way.
Using prebuilt binaries when source code is available is frowned upon by the Nix maintainers and won't pass through review unless there's a very good reason.
> Nixpkgs is unreliable - this speaks for itself…
This is highly misleading. The linked discussion mainly refers to the burden placed on Nixpkgs maintainers. While that is a serious problem, summarizing that as "Nixpkgs is unreliable" isn't fair. Or do changes in the Guix master branch not introduce regressions?
> home-manager? Has it’s own issues. It’s also not well documented.
The linked issue is a list of things to consider when getting started. Again, it's not a fair characterization of what is actually written.
Also, every Home Manager option comes with documentation:
https://nix-community.github.io/home-manager/options.html
> Overall Nix is a very flawed piece of software and far inferior to Guix.
Pure hyperbole and also not an acceptable thing to say.
> Years and years of technical issues plague the project and there seems to be little interest in actually resolving these issues.
I get the exact opposite impression when I look at discussions taking place on GitHub and Discourse.
> Guix uses so called build systems ... 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.
Nix has stdenv.mkDerivation and various functions based on it in Nixpkgs. Documentation leaves a lot to be desired, but they do at least exist in the Nixpkgs manual:
https://nixos.org/manual/nixpkgs/stable/#part-builders
> All Guix package definitions are written exclusively in GNU Guile - a Scheme implementation. ... For example rather than calling a sed within a shell script like what Nix definitions sometimes do, Guix uses the procedure substitute* instead.
Nixpkgs does use Nix functions to abstract away shell commands, but it doesn't attempt to replace shell commands entirely. Since build scripts are generally based on shell commands, I find the Nix approach of making it easy to embed shell commands reasonable.
> Now for the Nix language. It’s poorly documented. ... It isn’t particularly good as a DSL
I disagree with this assessment. Nix the language is a very small and conceptually simple language. It's basically JSON with functions. Its main competitor is JSON and YAML, and Nix does a far better job at describing complex data than those two.
The Nix language is documented in the Nix manual. Since the language is small, the relevant section is a quick read and easy to understand.
https://nixos.org/manual/nix/stable/language/
In contrast, Nixpkgs, the standard library of sorts, took more time to understand. But I soon figured out that grepping the Nixpkgs repository generally turns up many useful samples.
> Many packages also aren’t bootstrapped properly, instead patching and repackaging .deb packages and the like.
I can't find a source for this claim. I grepped the entire Nixpkgs repo for references to .deb or .rpm files. There certainly are packages that repackage them, but they're for proprietary software. There's no other possible way.
Using prebuilt binaries when source code is available is frowned upon by the Nix maintainers and won't pass through review unless there's a very good reason.
> Nixpkgs is unreliable - this speaks for itself…
This is highly misleading. The linked discussion mainly refers to the burden placed on Nixpkgs maintainers. While that is a serious problem, summarizing that as "Nixpkgs is unreliable" isn't fair. Or do changes in the Guix master branch not introduce regressions?
> home-manager? Has it’s own issues. It’s also not well documented.
The linked issue is a list of things to consider when getting started. Again, it's not a fair characterization of what is actually written.
Also, every Home Manager option comes with documentation:
https://nix-community.github.io/home-manager/options.html
> Overall Nix is a very flawed piece of software and far inferior to Guix.
Pure hyperbole and also not an acceptable thing to say.
> Years and years of technical issues plague the project and there seems to be little interest in actually resolving these issues.
I get the exact opposite impression when I look at discussions taking place on GitHub and Discourse.
I do see the OP’s points though, people are the weakest point of nix ecosystem, and I wish both projects worked together to solve this, as the tooling/approaches have similarities