6 ms·

I recently moved back to Arch from NixOS. I really love the idea, and the execution isn't necessarily bad, but it didn't make sense for me on the desktop. Stray

by __jem 5y ago

I recently moved back to Arch from NixOS. I really love the idea, and the execution isn't necessarily bad, but it didn't make sense for me on the desktop. Straying off the beaten path quickly led to the sense that I was going to have to learn way more about Nix than I wanted to. I hope the documentation and community grows, because I definitely got the sense that it is the future arriving early!

1_player 5y ago
The documentation and the nix language are the worst things about the project IMO. I really hope Guix succeeds because Scheme is, in my opinion, a better DSL and language than this weird, not very well documented, Haskell-like derivative. Unless you've drank the kool-aid, you have to learn a completely new operating system and way of doing things, a weird language that's lacking on documentation, and a ton of system or package-specific options that are even less documented, and requires you to spend too much time reading the source to understand what's going on and how to achieve something a little off the beaten path. Feels a bit cultish IMO, and that only the illuminated ones are able to grok it. That it's my fault I'm not prepared to do the work and see for myself why NixOS is better than any other distro.
- e3bc54b2 5y ago
  I agree on every single point. I'd love to make GuixSD my permanent home. But, Guix is not just Nix with better language. It comes with its own baggage elsewhere. Guix repository has way wayy fewer packages. Some of the most common ones like the plasma-desktop are absent. Proprietary applications are a no-go. Even if I set up nonguix, I'm warned that that cuts off my support in official channels. As an Optimus laptop owner (because my Master's required running Cuda and pytorch) I'm simply left hanging on Guix. I understand and often appreciate Guix's stand on everything above. No. of packages is because of strong stance on bootstrapping, proprietary package unavailability is self a explanatory. But, that doesn't solve my problems, and creates few new ones. Even Debian allows using proprietary firmware blobs with some fiddling and doesn't turn people away for asking. These barriers are so much that I bit the bullet and (mostly) learned the weird Nix DSL. As much as I'd like to go for Guix, for my personal use case, it is a nonstarter.
  - _huayra_ 5y ago
    Yes, if Guix were "Nix but with Scheme" I'd go for it in a second. Unfortunately, although both Nix and Guix make hard choices about things (e.g. the init system), at least the choices made by Nix are more livable day-to-day. As to why Nix wasn't some system written using Haskell (for actual language features that is also lazy) or Prolog (for its whole thing about solving constraint-based problems all over the place), I will never understand...
    - GordonS 5y ago
      Would it be possible to write a CLI tool that translated Scheme into Nix-compatible config files? Presumably then you could alias Nix commands so they piped config 8n through the translator.
      - _huayra_ 5y ago
        It might be possible, but a better approach (and the one Guix used initially, iirc) is to just be compatible with the derivation format (kinda like object files in C/C++ compilation). The end result is basically a big dependency graph, so one may be able to write a different generator in front of it. Anyone who has done the basics in Prolog could "logically" pull this off (e.g. some rule requires another rule, or however Prolog works; it's been a long time since I looked at it), but all of the extra stuff in the library (e.g. all of the systemd tweaking, interface, etc) is a LOT of man hours. I heard about Spack [0] on a recent cppcast episode, which seems like a competitor to Nix (but from the supercomputing side of things), but I don't know if they do the OS-level stuff (vs. nix shell / conda / pip / gem replacement stuff). [0] https://spack.io/ https://spack.io/
    - tgamblin 5y ago
      Guix and Nix don’t actually solve constraint problems, though. By design, they omit the dependency resolution that other package managers do, and humans manage the dependencies. If you want to change versions, you need to do some hacking to update things and propagate requirements through the package graph. You could think of Spack (github.com/spack/spack) as a nix/guix-like model, but with a solver. Spack uses ASP (which is prolog-like but reduces to SAT with optimization) but packages are written in an embedded python DSL.
- acgkmopvvgvmgv 5y ago
  Nix and similar projects are all going to be eaten alive by immutable distributions, Flatpak and new projects - that might work just like Nix but get the user experience right, and make packaging and maintenance easier. And no I'm not saying they do the exact same thing, have all the same features or target the same type of users. For the developer tools side I like what Shopify did but I would never recommend that to my employer. Too many moving parts and not enough people using it that I would feel safe about it.
  - 1_player 5y ago
    I'm out of the loop, what did Shopify do? EDIT: ah, you're probably talking about https://shopify.engineering/shipit-presents-how-shopify-uses-nix https://shopify.engineering/shipit-presents-how-shopify-uses...
    - takeda 5y ago
      I hate that they mentioned about ru.nix, published it on github for short time and then unpublished it[1]. [1] https://github.com/Shopify/runix/ https://github.com/Shopify/runix/
      - pxc 5y ago
        I think they wanted to avoid having people build on it before they stabilize its interfaces, since they still had some big changes planned. As I understand it, the plan is supposedly still to publish it at some point. I hope that if that's true, they publish it soon, because its design is very relevant to ongoing changes in the ecosystem, and it could be a useful reference point. :(
        takeda 5y ago
        I don't think it is. The talk was a year ago and it still isn't available. I created my own version, based on (I think they did that too) on NixOS modules system. But I'm wondering how it compares. Actually looking at https://gist.github.com/burke/72ca46c80e57a25907a75611ee5eb66d https://gist.github.com/burke/72ca46c80e57a25907a75611ee5eb6... I think their goal is slightly different than mine. There's also https://github.com/hercules-ci/project.nix https://github.com/hercules-ci/project.nix but it wasn't touched for a year now.
Jeff_Brown 5y ago
> Straying off the beaten path quickly leads to a terrifying abyss. The contrast is remarkable. When everything you need is packaged and it just works, it's amazing. Hands down the best system management experience I've had. And then one day you learn you've been dancing on the edge of a cliff. I'm hooked; there's no going back now for me. But there's at least one project (TidalCycles) that I simply gave up on ever running, because installing it requires peering deep inside the machine, and my psyche cannot handle it.
- pxc 5y ago
  J/w, have you ever packaged software for other distros? If yes, what made Nix more difficult here? If no, have you tried asking for help packaging TidalCycles on Matrix or Discourse? I'm wondering whether that's some especially oddly-behaved software, or if what's lacking here is some onboarding (that maybe can solved for you with a little community engagement or something).
  - Jeff_Brown 5y ago
    Nix is the only OS I've used where the standard installation instructions available in, say, the READMEs of things I want to install are a bad idea. Granted, whenever something is in nixpkgs it's a piece of cake, and almost everything I need is. But to install something not part of nixpkgs, I had to look under the hood in a way that no other platform has made me do. I've never packaged software on another platform. I packaged serialoscd and monomeserial, and the Discourse channel was critically helpful. It looks like I never tried engaging the community about TidalCycles. I found an old package, tried to fix it, couldn't.
    - pxc 5y ago
      Thanks for sharing your experience in more detail. I think Nixpkgs is easier to package for than a lot of ecosystems/distributions, but the obligation of _having_ to package for the distro in order to get things working in an ideal way is (reasonably!) more than many people want to have to deal with. (There is also a gap, kinda like across the built-in vs. have-to-package barrier, inside the Nixpkgs world, between software with reasonable/standard build systems and software with unique or ill-designed build processes.) I've been daydreaming about how this could be better for a little while now, and wondering what compromises it will require to the ‘purity’ of the system, how worthwhile they'll be for novice and advanced users, etc.

by __jem 5y ago

1_player 5y ago

The documentation and the nix language are the worst things about the project IMO. I really hope Guix succeeds because Scheme is, in my opinion, a better DSL and language than this weird, not very well documented, Haskell-like derivative. Unless you've drank the kool-aid, you have to learn a completely new operating system and way of doing things, a weird language that's lacking on documentation, and a ton of system or package-specific options that are even less documented, and requires you to spend too much time reading the source to understand what's going on and how to achieve something a little off the beaten path. Feels a bit cultish IMO, and that only the illuminated ones are able to grok it. That it's my fault I'm not prepared to do the work and see for myself why NixOS is better than any other distro.

e3bc54b2 5y ago
I agree on every single point. I'd love to make GuixSD my permanent home. But, Guix is not just Nix with better language. It comes with its own baggage elsewhere. Guix repository has way wayy fewer packages. Some of the most common ones like the plasma-desktop are absent. Proprietary applications are a no-go. Even if I set up nonguix, I'm warned that that cuts off my support in official channels. As an Optimus laptop owner (because my Master's required running Cuda and pytorch) I'm simply left hanging on Guix. I understand and often appreciate Guix's stand on everything above. No. of packages is because of strong stance on bootstrapping, proprietary package unavailability is self a explanatory. But, that doesn't solve my problems, and creates few new ones. Even Debian allows using proprietary firmware blobs with some fiddling and doesn't turn people away for asking. These barriers are so much that I bit the bullet and (mostly) learned the weird Nix DSL. As much as I'd like to go for Guix, for my personal use case, it is a nonstarter.
- _huayra_ 5y ago
  Yes, if Guix were "Nix but with Scheme" I'd go for it in a second. Unfortunately, although both Nix and Guix make hard choices about things (e.g. the init system), at least the choices made by Nix are more livable day-to-day. As to why Nix wasn't some system written using Haskell (for actual language features that is also lazy) or Prolog (for its whole thing about solving constraint-based problems all over the place), I will never understand...
  - GordonS 5y ago
    Would it be possible to write a CLI tool that translated Scheme into Nix-compatible config files? Presumably then you could alias Nix commands so they piped config 8n through the translator.
    - _huayra_ 5y ago
      It might be possible, but a better approach (and the one Guix used initially, iirc) is to just be compatible with the derivation format (kinda like object files in C/C++ compilation). The end result is basically a big dependency graph, so one may be able to write a different generator in front of it. Anyone who has done the basics in Prolog could "logically" pull this off (e.g. some rule requires another rule, or however Prolog works; it's been a long time since I looked at it), but all of the extra stuff in the library (e.g. all of the systemd tweaking, interface, etc) is a LOT of man hours. I heard about Spack [0] on a recent cppcast episode, which seems like a competitor to Nix (but from the supercomputing side of things), but I don't know if they do the OS-level stuff (vs. nix shell / conda / pip / gem replacement stuff). [0] https://spack.io/ https://spack.io/
  - tgamblin 5y ago
    Guix and Nix don’t actually solve constraint problems, though. By design, they omit the dependency resolution that other package managers do, and humans manage the dependencies. If you want to change versions, you need to do some hacking to update things and propagate requirements through the package graph. You could think of Spack (github.com/spack/spack) as a nix/guix-like model, but with a solver. Spack uses ASP (which is prolog-like but reduces to SAT with optimization) but packages are written in an embedded python DSL.
acgkmopvvgvmgv 5y ago
Nix and similar projects are all going to be eaten alive by immutable distributions, Flatpak and new projects - that might work just like Nix but get the user experience right, and make packaging and maintenance easier. And no I'm not saying they do the exact same thing, have all the same features or target the same type of users. For the developer tools side I like what Shopify did but I would never recommend that to my employer. Too many moving parts and not enough people using it that I would feel safe about it.
- 1_player 5y ago
  I'm out of the loop, what did Shopify do? EDIT: ah, you're probably talking about https://shopify.engineering/shipit-presents-how-shopify-uses-nix https://shopify.engineering/shipit-presents-how-shopify-uses...
  - takeda 5y ago
    I hate that they mentioned about ru.nix, published it on github for short time and then unpublished it[1]. [1] https://github.com/Shopify/runix/ https://github.com/Shopify/runix/
    - pxc 5y ago
      I think they wanted to avoid having people build on it before they stabilize its interfaces, since they still had some big changes planned. As I understand it, the plan is supposedly still to publish it at some point. I hope that if that's true, they publish it soon, because its design is very relevant to ongoing changes in the ecosystem, and it could be a useful reference point. :(
      - takeda 5y ago
        I don't think it is. The talk was a year ago and it still isn't available. I created my own version, based on (I think they did that too) on NixOS modules system. But I'm wondering how it compares. Actually looking at https://gist.github.com/burke/72ca46c80e57a25907a75611ee5eb66d https://gist.github.com/burke/72ca46c80e57a25907a75611ee5eb6... I think their goal is slightly different than mine. There's also https://github.com/hercules-ci/project.nix https://github.com/hercules-ci/project.nix but it wasn't touched for a year now.

Jeff_Brown 5y ago

> Straying off the beaten path quickly leads to a terrifying abyss. The contrast is remarkable. When everything you need is packaged and it just works, it's amazing. Hands down the best system management experience I've had. And then one day you learn you've been dancing on the edge of a cliff. I'm hooked; there's no going back now for me. But there's at least one project (TidalCycles) that I simply gave up on ever running, because installing it requires peering deep inside the machine, and my psyche cannot handle it.

pxc 5y ago
J/w, have you ever packaged software for other distros? If yes, what made Nix more difficult here? If no, have you tried asking for help packaging TidalCycles on Matrix or Discourse? I'm wondering whether that's some especially oddly-behaved software, or if what's lacking here is some onboarding (that maybe can solved for you with a little community engagement or something).
- Jeff_Brown 5y ago
  Nix is the only OS I've used where the standard installation instructions available in, say, the READMEs of things I want to install are a bad idea. Granted, whenever something is in nixpkgs it's a piece of cake, and almost everything I need is. But to install something not part of nixpkgs, I had to look under the hood in a way that no other platform has made me do. I've never packaged software on another platform. I packaged serialoscd and monomeserial, and the Discourse channel was critically helpful. It looks like I never tried engaging the community about TidalCycles. I found an old package, tried to fix it, couldn't.
  - pxc 5y ago
    Thanks for sharing your experience in more detail. I think Nixpkgs is easier to package for than a lot of ecosystems/distributions, but the obligation of _having_ to package for the distro in order to get things working in an ideal way is (reasonably!) more than many people want to have to deal with. (There is also a gap, kinda like across the built-in vs. have-to-package barrier, inside the Nixpkgs world, between software with reasonable/standard build systems and software with unique or ill-designed build processes.) I've been daydreaming about how this could be better for a little while now, and wondering what compromises it will require to the ‘purity’ of the system, how worthwhile they'll be for novice and advanced users, etc.