6 ms·

The many issues plaguing Nix

75 points by lambdaba 3y ago

scolby33 3y ago
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.
- autumn-antlers 3y ago
  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/ https://packages.guix.gnu.org/packages/zfs/ 2: https://www.reddit.com/r/GUIX/comments/s7qu25/guide_using_zfs_on_guix/ https://www.reddit.com/r/GUIX/comments/s7qu25/guide_using_zf... 3: https://issues.guix.gnu.org/45692 https://issues.guix.gnu.org/45692 *: Accessing ZVOLS through `/dev/zvol/foo/bar` takes additional setup.
bsder 3y ago
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.
- m463 3y ago
  That sounds like what I've always said about make. :) s/nix/make/ It's hard when your gut gets wrapped up in the useful <-> insufferable conundrum
- soraminazuki 3y ago
  > 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 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 https://github.com/NixOS/nix/pulse/monthly
  - bsder 3y ago
    > May I ask why? Because it breaks the universe? https://github.com/NixOS/nixpkgs/issues/24744 https://github.com/NixOS/nixpkgs/issues/24744 https://discourse.nixos.org/t/using-mold-as-linker-prevents-libraries-from-being-found/18530 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-nix/part-10 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?
heyoni 3y ago
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.
- CameronNemo 3y ago
  CUDA on Guix might be a challenge, I imagine.
  - db48x 3y ago
    The Nongnu repository has a package for the nvidia drivers if you need them.
yarekt 3y ago
Also new to nixos but the first few hours was a breeze: installed x and i3, commented out, installed waylaid and sway, realised that my configs aren’t ready to switch yet (mainly custom xmodmap) so commented that back out, and i3 back in. I’m still left with a perfectly working system. Such experiments on Ubuntu normally left numerous irreversible changes (granted, mostly through lack of knowledge). 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
- CameronNemo 3y ago
  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
- tomberek 3y ago
  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-nix-ecosystem-tell-me-your-story/31415 https://discourse.nixos.org/t/where-did-you-get-stuck-in-the...
paradox460 3y ago
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
- rgoulter 3y ago
  > 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.
  - happens 3y ago
    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?
    - rgoulter 3y ago
      `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 https://github.com/direnv/direnv/wiki/nix Another option is to use `nix develop --command fish`.
- assbuttbuttass 3y ago
  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
nightowl_games 3y ago
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?
- Aerbil313 3y ago
  You can safely mutate your system instead of using an immutable one.
- rgoulter 3y ago
  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.
- kwk1 3y ago
  Nix (contrasted with NixOS) can be used on macOS as an alternative to and escape hatch from the Homebrew ecosystem.
- FireInsight 3y ago
  I myself use Fedora Silverblue with a https://ublue.it/ 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.
- 3y ago
deleted 3y ago
[deleted]
bfrog 3y ago
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.
- ndiddy 3y ago
  See https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix
Aerbil313 3y ago
I'd very much like it if Nix and NixOS were rewritten with lessons learnt so far.
- schemescape 3y ago
  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.
  - Aerbil313 3y ago
    Yeah, but Guix shows its age too (has learned lessons unimplemented) and it’s not as usable atm afaik.
whateveracct 3y ago
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
guilhas 3y ago
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
soraminazuki 3y ago
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 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/ 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 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.
sharts 3y ago
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.
herewulf 3y ago
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.

75 points by lambdaba 3y ago

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.

autumn-antlers 3y ago
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/ https://packages.guix.gnu.org/packages/zfs/ 2: https://www.reddit.com/r/GUIX/comments/s7qu25/guide_using_zfs_on_guix/ https://www.reddit.com/r/GUIX/comments/s7qu25/guide_using_zf... 3: https://issues.guix.gnu.org/45692 https://issues.guix.gnu.org/45692 *: Accessing ZVOLS through `/dev/zvol/foo/bar` takes additional setup.

bsder 3y ago

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.

m463 3y ago
That sounds like what I've always said about make. :) s/nix/make/ It's hard when your gut gets wrapped up in the useful <-> insufferable conundrum
soraminazuki 3y ago
> 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 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 https://github.com/NixOS/nix/pulse/monthly
- bsder 3y ago
  > May I ask why? Because it breaks the universe? https://github.com/NixOS/nixpkgs/issues/24744 https://github.com/NixOS/nixpkgs/issues/24744 https://discourse.nixos.org/t/using-mold-as-linker-prevents-libraries-from-being-found/18530 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-nix/part-10 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?

heyoni 3y ago

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.

CameronNemo 3y ago
CUDA on Guix might be a challenge, I imagine.
- db48x 3y ago
  The Nongnu repository has a package for the nvidia drivers if you need them.

yarekt 3y ago

Also new to nixos but the first few hours was a breeze: installed x and i3, commented out, installed waylaid and sway, realised that my configs aren’t ready to switch yet (mainly custom xmodmap) so commented that back out, and i3 back in. I’m still left with a perfectly working system. Such experiments on Ubuntu normally left numerous irreversible changes (granted, mostly through lack of knowledge). 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

CameronNemo 3y ago
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
tomberek 3y ago
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-nix-ecosystem-tell-me-your-story/31415 https://discourse.nixos.org/t/where-did-you-get-stuck-in-the...

paradox460 3y ago

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

rgoulter 3y ago
> 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.
- happens 3y ago
  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?
  - rgoulter 3y ago
    `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 https://github.com/direnv/direnv/wiki/nix Another option is to use `nix develop --command fish`.
assbuttbuttass 3y ago
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

nightowl_games 3y ago

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?

Aerbil313 3y ago
You can safely mutate your system instead of using an immutable one.
rgoulter 3y ago
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.
kwk1 3y ago
Nix (contrasted with NixOS) can be used on macOS as an alternative to and escape hatch from the Homebrew ecosystem.
FireInsight 3y ago
I myself use Fedora Silverblue with a https://ublue.it/ 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.
3y ago

deleted 3y ago

[deleted]

bfrog 3y ago

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.

ndiddy 3y ago
See https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix

Aerbil313 3y ago

I'd very much like it if Nix and NixOS were rewritten with lessons learnt so far.

schemescape 3y ago
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.
- Aerbil313 3y ago
  Yeah, but Guix shows its age too (has learned lessons unimplemented) and it’s not as usable atm afaik.

whateveracct 3y ago

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

guilhas 3y ago

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

soraminazuki 3y ago

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 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/ 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 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.

sharts 3y ago

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.

herewulf 3y ago

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.