3 ms·

I've been using it for 9 months on laptop. I really love the idea. But had to ditch it and use ubuntu instead, because it routinely turned a 3-minutes-long-oper

by hexo 6y ago

I've been using it for 9 months on laptop. I really love the idea. But had to ditch it and use ubuntu instead, because it routinely turned a 3-minutes-long-operation into 6 hours. I had to do work, not mess with configuration and read 6 A4 pages worth of text only to install some python package. I strongly feel like it needs to take the idea to a new level, ditch the messy language and completely refactor it. Don't get me wrong, NixOS is 17 years old and it still feels like alpha version.

toyg 6y ago
Damn, I was tempted by it some time ago and found it required way too much investment, so I thought “I’ll check back once they build enough stuff on top to make most of these tasks easily-manageable without being an expert”. But if it has not happened in 17 years, it probably never will...
- Shoue 6y ago
  I'm not sure it's fair to say because it hasn't happened in the 17 years of NixOS' lifespan, that it never will, when the last 5 years of NixOS have been the most active by large: https://github.com/NixOS/nixpkgs/graphs/code-frequency https://github.com/NixOS/nixpkgs/graphs/code-frequency
  - danieldk 6y ago
    Also, there are some large recent initiatives to improve Nix and NixOS, such as Flakes (which give Nix package sets a standard layout and improves hermatic evaluation). Eelco Dolstra has also presented a proposal at NixCon 2020 to improve the module system's usability: https://www.youtube.com/watch?v=7sQa04olUA0&t=1h24m18s https://www.youtube.com/watch?v=7sQa04olUA0&t=1h24m18s
throwaway894345 6y ago
Wait until you try to write your own package definitions. It’s a completely uphill battle, not least of all because nixpkgs is incredibly difficult to parse as a reference (no static types so good luck guessing what any given function takes for arguments, precious little documentation, no decipherable code organization, few if any direct imports to help you find dependency definitions, etc).
- siraben 6y ago
  It's not so bad actually. To add a new package there's only two files you have to touch, add a new default.nix somewhere in the pkgs/ tree and add your package to pkgs/top-level/all-packages.nix. Looking at any of the 60,000 packages in Nixpkgs should give one an idea of what to write.
  - throwaway894345 6y ago
    This comment reminds me of the "How to draw an owl" meme: 1. Draw some ovals 2. Draw the rest of the effing owl Yes, you only have to write your Nix expression code in a couple of files; of course, the issue is "how to write that Nix expression code correctly". > Looking at any of the 60,000 packages in Nixpkgs should give one an idea of what to write. This is exactly the fallacy I addressed in my comment--Nixpkgs is a really brutal reference for a variety of reasons. Let's say you're building a Python project--first of all, good luck finding a good reference package in nixpkgs if you don't already know where the Python packages are. Secondly, the general scheme seems to be "import nothing, write some function that takes dependencies as arguments", which means you'll have no import statements pointing you to the source files for the dependencies. Further, because nixpkgs doesn't believe in docstrings or static types, you'll have nothing that helps you infer the shape of the thing you're searching for or otherwise provide you with reliable grep criteria. You'll need to grep for the call site for your function to determine what gets passed in, and that thing might be the result of calling some other function with its own args, so you end up recursing through this process for the whole dependency tree. It's needlessly tedious, and this example is just the tip of the painful iceberg.
    - lakecresva 6y ago
      This was exactly my experience. They have manuals that are very comprehensive reference texts, but complete lack of structure (no types, no docstrings, no enforced conventions/standards, extremely poor discoverability) makes it a nightmare in practice.
      - throwaway894345 6y ago
db48x 6y ago
I agree about the language. Guix is in many respects the same as Nix, but it benefits quite a lot by using Scheme instead.
- wwright 6y ago
  Specifically Guile
globular-toast 6y ago
> I strongly feel like it needs to take the idea to a new level, ditch the messy language and completely refactor it. Don't get me wrong, NixOS is 17 years old and it still feels like alpha version. That's what Guix is for. https://guix.gnu.org/ https://guix.gnu.org/

by hexo 6y ago

toyg 6y ago

Damn, I was tempted by it some time ago and found it required way too much investment, so I thought “I’ll check back once they build enough stuff on top to make most of these tasks easily-manageable without being an expert”. But if it has not happened in 17 years, it probably never will...

Shoue 6y ago
I'm not sure it's fair to say because it hasn't happened in the 17 years of NixOS' lifespan, that it never will, when the last 5 years of NixOS have been the most active by large: https://github.com/NixOS/nixpkgs/graphs/code-frequency https://github.com/NixOS/nixpkgs/graphs/code-frequency
- danieldk 6y ago
  Also, there are some large recent initiatives to improve Nix and NixOS, such as Flakes (which give Nix package sets a standard layout and improves hermatic evaluation). Eelco Dolstra has also presented a proposal at NixCon 2020 to improve the module system's usability: https://www.youtube.com/watch?v=7sQa04olUA0&t=1h24m18s https://www.youtube.com/watch?v=7sQa04olUA0&t=1h24m18s

throwaway894345 6y ago

Wait until you try to write your own package definitions. It’s a completely uphill battle, not least of all because nixpkgs is incredibly difficult to parse as a reference (no static types so good luck guessing what any given function takes for arguments, precious little documentation, no decipherable code organization, few if any direct imports to help you find dependency definitions, etc).

siraben 6y ago
It's not so bad actually. To add a new package there's only two files you have to touch, add a new default.nix somewhere in the pkgs/ tree and add your package to pkgs/top-level/all-packages.nix. Looking at any of the 60,000 packages in Nixpkgs should give one an idea of what to write.
- throwaway894345 6y ago
  This comment reminds me of the "How to draw an owl" meme: 1. Draw some ovals 2. Draw the rest of the effing owl Yes, you only have to write your Nix expression code in a couple of files; of course, the issue is "how to write that Nix expression code correctly". > Looking at any of the 60,000 packages in Nixpkgs should give one an idea of what to write. This is exactly the fallacy I addressed in my comment--Nixpkgs is a really brutal reference for a variety of reasons. Let's say you're building a Python project--first of all, good luck finding a good reference package in nixpkgs if you don't already know where the Python packages are. Secondly, the general scheme seems to be "import nothing, write some function that takes dependencies as arguments", which means you'll have no import statements pointing you to the source files for the dependencies. Further, because nixpkgs doesn't believe in docstrings or static types, you'll have nothing that helps you infer the shape of the thing you're searching for or otherwise provide you with reliable grep criteria. You'll need to grep for the call site for your function to determine what gets passed in, and that thing might be the result of calling some other function with its own args, so you end up recursing through this process for the whole dependency tree. It's needlessly tedious, and this example is just the tip of the painful iceberg.
  - lakecresva 6y ago
    This was exactly my experience. They have manuals that are very comprehensive reference texts, but complete lack of structure (no types, no docstrings, no enforced conventions/standards, extremely poor discoverability) makes it a nightmare in practice.
    - throwaway894345 6y ago

db48x 6y ago

I agree about the language. Guix is in many respects the same as Nix, but it benefits quite a lot by using Scheme instead.

wwright 6y ago
Specifically Guile

globular-toast 6y ago

> I strongly feel like it needs to take the idea to a new level, ditch the messy language and completely refactor it. Don't get me wrong, NixOS is 17 years old and it still feels like alpha version. That's what Guix is for. https://guix.gnu.org/ https://guix.gnu.org/