5 ms·

NixOS is a terrible solution rather than a reproducible one. Adding a layer of complexity to simple text files that can be easily edited and having thousands of

by _fsql 2y ago

NixOS is a terrible solution rather than a reproducible one. Adding a layer of complexity to simple text files that can be easily edited and having thousands of links that are links to other links is just stupid. Filling up disk space like crazy and using more machine resources on trivial tasks is not an elegant solution. Editing configuration.nix or any other module, reading all the idiotic variable definitions that were invented to change a simple variable in a text file, is boring. I don't know what the Nix designer (NixOS) had in mind when they thought that putting layer upon layer of complexity was a great solution. If something goes wrong in NixOS at the bottom layer, the nixos-rebuild command will produce weird errors. NixOS is an effort to make Linux complex and, in my opinion, useless. I could go on listing the shortcomings of NixOS, but I'll stop here...

SuperSandro2000 2y ago
[flagged]
anthk 2y ago
Guix, as NixOS, exists when an scientific experiment should have reproducible builds in every stage. On config files, Guile is not that difficult.
- _fsql 2y ago
  Guile and Nix are horrible languages with shitty syntax, the difference is that one is general purpose (Guile) and the other is a mix of yaml and json, while Guile (Lisp) abuses parentheses and you end up lost in spaghetti code, in Nix you end up not knowing what it's doing even if you're an "expert". They are bad solutions and not very reproducible, because in NixOS you have to change every so often the shitty variables they use to set garbage and in Guix you have to fight if you need non-free software with the NonGuix channel and other kind of nonsense.
  - anthk 2y ago
    Losing parentheses is not an issue for any Lisp programmer. I remind you this is HN, guess on what was built on. >non-free software Non-free software should be the issue, not Guix itself. Not free software by default is NOT reproducible. Period. Useless for science.
    - agubelu 2y ago
      The reproducibility crisis in science has nothing to do with the supporting software itself not being reproducible.
      - anthk 2y ago
        Both are needed. Look what happened with Excel in genomics. Once you can control every point of the pipeline, you are set. That means a discrete set of versions, dependencies and being able to rebuild and fix every point of software if bugs show up.
    - poincaredisk 2y ago
      >Non-free software should be the issue, not Guix itself Not the parent, but this approach from Guix maintainers is the reason why it's not an OS I would consider. I use free software almost exclusively, but I appreciate that nixos doesn't try to play the moral police and will let me easily run any non-free software I want. I don't like it, but sometimes using a non free tool is the easiest way to get the job done, and life is too short to get stuck on software idealism (at least for me).
      - opan 2y ago
        You are free to use non-free software on Guix System, it's just not in the main channel or officially recommended. You'd likely figure it out fast enough if you wanted.
    - viraptor 2y ago
      > Not free software by default is NOT reproducible. Changing a licence on some software doesn't change the compilation. The licence is completely orthogonal to whether software is reproducible or not.
  - exe34 2y ago
    > you end up not knowing what it's doing even if you're an "expert" Oh you've tried Haskell then?
    - _fsql 2y ago
      Well, with Haskell you know what it is oriented towards and you know what to expect, but Nix wants to control everything in the system by adding unnecessary complexity to the simple and making the complex even more complex.
      - exe34 2y ago
        Sounds like you want MacOS.
        _fsql 2y ago
        No, I like it practical and without such stupid design choices.
        exe34 2y ago
        If only there were alternatives...
  - IshKebab 2y ago
    I agree. I really think Nix would be a lot more approachable if it didn't have such a weird language. The fact that it is dynamically typed and declarative also means it is completely undiscoverable.
  - creata 2y ago
    Those things (parentheses and free software) don't make Guix a bad solution. It's just not for you.
    - _fsql 2y ago
      If Guix were an optimal solution, many companies would be using it, but that's not happening. It's just a niche experiment. And parentheses don't seem so bad when the code is one line, when tens or hundreds of lines won't be so fun.
      - anthk 2y ago
        HPC under Inria. Giving how young Guix is, lots of companies rely on it. >Tens or hundreds You never wrote a single line or Scheme or Common Lisp and it shows. No one writes thousands of nested lines down. They modularize it into functions because Lisp was basically made literally for that. Get some Emacs modules and code, such as Mastodon.el. Look at the source code. Far easier to understand than any C or C++ codebase, not to mention Rust.
  - prmoustache 2y ago
    Isn't most non-free stuff installed in /opt or in the user homedir these days anyway?
womfoo 2y ago
Can you recommend tools you prefer/use for achieving reproducibility/determinism?
- im3w1l 2y ago
  I enjoyed thinking about the "how would I do it differently question", note would, as I have never actually tried it. Maybe something like this? All packages are defined as a tuple (dependencies, dev dependencies, base image, command list, file list). Builds are done by loading the base image into a virtual machine, copying the dev dependencies into the vm, running the commands, and then pulling the listed files out into the host. All packages of a given OS edition would use the same base image, I suppose. If a user wants to configure a package it will be done by putting a patch file in his configuration directory. The patch is applied to the built files.
  - viraptor 2y ago
    You're describing nixpkgs with an external builder in a VM. That's exactly what it would do. And that tuple is what nixpkgs packages really are (with some macros on top, but you're not forced to use them).
    - im3w1l 2y ago
      My impression of configuration in nix is that a lot of configuration that in any other distro would be handled by changing some /etc/file is instead done in a completely separate way by editing some nix file. So that's one user-visible way it differs from what I mentioned of using a patch for the /etc/file. Some simple example I found just now: https://unix.stackexchange.com/questions/489509/how-do-i-modify-my-hosts-file-in-nixos https://unix.stackexchange.com/questions/489509/how-do-i-mod...
      - viraptor 2y ago
        There are patches which need to live in the repo by default anyway, so that's already supported, just not as random /etc location. https://github.com/NixOS/nixpkgs/tree/master/pkgs/by-name/aw/aws-gate https://github.com/NixOS/nixpkgs/tree/master/pkgs/by-name/aw...
teh 2y ago
I feel you (like many people) got burned by the steep learning curve. Empirically some pretty high powered companies use nix successfully. It's of course always difficult to know the counterfactual (would they have been fine with ubuntu) but the power to get SBOMs, patch a dependencies deep in the dependency stack, roll back entire server installs etc. really helps these people scale. nixpkgs is also the largest and most up to date package set (followed by arch) so there's clearly something in the technology that allows a loosely organised group of people to scale to that level.
- attendant3446 2y ago
  I know it's not a proper measurement, but I can't remember the last time I missed something in AUR, but in my short time on NixOS I missed 2 apps and 1 app that disappeared in the NixOS channel upgrade.
- _fsql 2y ago
  NixOS has very limited usage, with few companies adopting it for critical or commercial tasks. It is more common in experimental niches. One of the main issues with nixpkgs is that users have to rely on overlays for a package. This can lead to obscure errors because if something fails in the original package or a Nix module, it's hard to pinpoint the problem. Additionally, the overuse of links in the directory hierarchy further complicates things, giving the impression that NixOS is a patched and poorly designed structure. As someone who has tried Nix, uses NixOS, and created my own modular configuration, I made optimizations and wrote some modules to scratch my own itch. I realized I was wasting time trying to make one tool configure other tools. That’s essentially what NixOS does through Nix. Why complicate a Linux system when I can just write bash scripts and automate my tasks without hassle? Sure, they might say it’s reproducible, but it really isn’t. Several packages in NixOS can fail because a developer redefined a variable; this then affects another part of the module and misconfigures the upstream package. So, you end up struggling with something that should be simple and straightforward to diagnose.
attendant3446 2y ago
I agree with everything you just said. I really like the idea behind NixOS - write a config and apply it, all containerised, but I never had a chance to try it until recently when I got a new laptop at work. But after 3 months I updated my Ansible playbook, added things I needed for work, went back to Arch and couldn't be happier. With NixOS it felt like there was an extra maintenance fee for doing regular Linux things. It just wasn't worth it for me.
- poincaredisk 2y ago
  I'm a bit surprised to read it - for me I configured my system years ago and it just "keeps working" (I very rarely need to edit my configuration, for trying new programs I just spawn a nix-shell). Though I agree that first time doing anything has an additional cost - for example configuring my HP printer was maybe three lines of nix code, but I had to spend some time with forums to write them. On the other hand, I now just reuse these lines everywhere and don't have to think about it at all. For me that's a lot of time saved. It's entirely possible you're using OS differently than I do, and cost/benefit calculation is different for you.
  - _fsql 2y ago
    If NixOS works well for you, that's great! But from my perspective, the whole NixOS model adds unnecessary complexity and makes you learn ways to do things that don’t really translate to other Linux systems. The directory structure in NixOS is different and doesn't follow the FHS (Filesystem Hierarchy Standard) and the system uses a bunch of symbolic links that feel like "hacks" to keep some kind of compatibility with the FHS. For example, if you want NixOS to recognize paths like /bin or /usr/bin in your scripts, you have to enable services.envfs.enable in your configuration.nix or in a .nix module. If something goes wrong in NixOS, you might run into multiple issues because the problem could be within NixOS, the underlying system, nixpkgs, upstream packages, or a mix of all these factors. Sure, it might save you time in some situations, but when a problem pops up, you'll find yourself in a tricky spot since you’ll have to dig through all the layers of the system to find the root cause. On top of that, you’ll have to sift through the options and the documentation, which can often be pretty confusing.

by _fsql 2y ago

SuperSandro2000 2y ago

[flagged]

anthk 2y ago

Guix, as NixOS, exists when an scientific experiment should have reproducible builds in every stage. On config files, Guile is not that difficult.

_fsql 2y ago
Guile and Nix are horrible languages with shitty syntax, the difference is that one is general purpose (Guile) and the other is a mix of yaml and json, while Guile (Lisp) abuses parentheses and you end up lost in spaghetti code, in Nix you end up not knowing what it's doing even if you're an "expert". They are bad solutions and not very reproducible, because in NixOS you have to change every so often the shitty variables they use to set garbage and in Guix you have to fight if you need non-free software with the NonGuix channel and other kind of nonsense.
- anthk 2y ago
  Losing parentheses is not an issue for any Lisp programmer. I remind you this is HN, guess on what was built on. >non-free software Non-free software should be the issue, not Guix itself. Not free software by default is NOT reproducible. Period. Useless for science.
  - agubelu 2y ago
    The reproducibility crisis in science has nothing to do with the supporting software itself not being reproducible.
    - anthk 2y ago
      Both are needed. Look what happened with Excel in genomics. Once you can control every point of the pipeline, you are set. That means a discrete set of versions, dependencies and being able to rebuild and fix every point of software if bugs show up.
  - poincaredisk 2y ago
    >Non-free software should be the issue, not Guix itself Not the parent, but this approach from Guix maintainers is the reason why it's not an OS I would consider. I use free software almost exclusively, but I appreciate that nixos doesn't try to play the moral police and will let me easily run any non-free software I want. I don't like it, but sometimes using a non free tool is the easiest way to get the job done, and life is too short to get stuck on software idealism (at least for me).
    - opan 2y ago
      You are free to use non-free software on Guix System, it's just not in the main channel or officially recommended. You'd likely figure it out fast enough if you wanted.
  - viraptor 2y ago
    > Not free software by default is NOT reproducible. Changing a licence on some software doesn't change the compilation. The licence is completely orthogonal to whether software is reproducible or not.
- exe34 2y ago
  > you end up not knowing what it's doing even if you're an "expert" Oh you've tried Haskell then?
  - _fsql 2y ago
    Well, with Haskell you know what it is oriented towards and you know what to expect, but Nix wants to control everything in the system by adding unnecessary complexity to the simple and making the complex even more complex.
    - exe34 2y ago
      Sounds like you want MacOS.
      - _fsql 2y ago
        No, I like it practical and without such stupid design choices.
        exe34 2y ago
        If only there were alternatives...
- IshKebab 2y ago
  I agree. I really think Nix would be a lot more approachable if it didn't have such a weird language. The fact that it is dynamically typed and declarative also means it is completely undiscoverable.
- creata 2y ago
  Those things (parentheses and free software) don't make Guix a bad solution. It's just not for you.
  - _fsql 2y ago
    If Guix were an optimal solution, many companies would be using it, but that's not happening. It's just a niche experiment. And parentheses don't seem so bad when the code is one line, when tens or hundreds of lines won't be so fun.
    - anthk 2y ago
      HPC under Inria. Giving how young Guix is, lots of companies rely on it. >Tens or hundreds You never wrote a single line or Scheme or Common Lisp and it shows. No one writes thousands of nested lines down. They modularize it into functions because Lisp was basically made literally for that. Get some Emacs modules and code, such as Mastodon.el. Look at the source code. Far easier to understand than any C or C++ codebase, not to mention Rust.
- prmoustache 2y ago
  Isn't most non-free stuff installed in /opt or in the user homedir these days anyway?

womfoo 2y ago

Can you recommend tools you prefer/use for achieving reproducibility/determinism?

im3w1l 2y ago
I enjoyed thinking about the "how would I do it differently question", note would, as I have never actually tried it. Maybe something like this? All packages are defined as a tuple (dependencies, dev dependencies, base image, command list, file list). Builds are done by loading the base image into a virtual machine, copying the dev dependencies into the vm, running the commands, and then pulling the listed files out into the host. All packages of a given OS edition would use the same base image, I suppose. If a user wants to configure a package it will be done by putting a patch file in his configuration directory. The patch is applied to the built files.
- viraptor 2y ago
  You're describing nixpkgs with an external builder in a VM. That's exactly what it would do. And that tuple is what nixpkgs packages really are (with some macros on top, but you're not forced to use them).
  - im3w1l 2y ago
    My impression of configuration in nix is that a lot of configuration that in any other distro would be handled by changing some /etc/file is instead done in a completely separate way by editing some nix file. So that's one user-visible way it differs from what I mentioned of using a patch for the /etc/file. Some simple example I found just now: https://unix.stackexchange.com/questions/489509/how-do-i-modify-my-hosts-file-in-nixos https://unix.stackexchange.com/questions/489509/how-do-i-mod...
    - viraptor 2y ago
      There are patches which need to live in the repo by default anyway, so that's already supported, just not as random /etc location. https://github.com/NixOS/nixpkgs/tree/master/pkgs/by-name/aw/aws-gate https://github.com/NixOS/nixpkgs/tree/master/pkgs/by-name/aw...

teh 2y ago

I feel you (like many people) got burned by the steep learning curve. Empirically some pretty high powered companies use nix successfully. It's of course always difficult to know the counterfactual (would they have been fine with ubuntu) but the power to get SBOMs, patch a dependencies deep in the dependency stack, roll back entire server installs etc. really helps these people scale. nixpkgs is also the largest and most up to date package set (followed by arch) so there's clearly something in the technology that allows a loosely organised group of people to scale to that level.

attendant3446 2y ago
I know it's not a proper measurement, but I can't remember the last time I missed something in AUR, but in my short time on NixOS I missed 2 apps and 1 app that disappeared in the NixOS channel upgrade.
_fsql 2y ago
NixOS has very limited usage, with few companies adopting it for critical or commercial tasks. It is more common in experimental niches. One of the main issues with nixpkgs is that users have to rely on overlays for a package. This can lead to obscure errors because if something fails in the original package or a Nix module, it's hard to pinpoint the problem. Additionally, the overuse of links in the directory hierarchy further complicates things, giving the impression that NixOS is a patched and poorly designed structure. As someone who has tried Nix, uses NixOS, and created my own modular configuration, I made optimizations and wrote some modules to scratch my own itch. I realized I was wasting time trying to make one tool configure other tools. That’s essentially what NixOS does through Nix. Why complicate a Linux system when I can just write bash scripts and automate my tasks without hassle? Sure, they might say it’s reproducible, but it really isn’t. Several packages in NixOS can fail because a developer redefined a variable; this then affects another part of the module and misconfigures the upstream package. So, you end up struggling with something that should be simple and straightforward to diagnose.

attendant3446 2y ago

I agree with everything you just said. I really like the idea behind NixOS - write a config and apply it, all containerised, but I never had a chance to try it until recently when I got a new laptop at work. But after 3 months I updated my Ansible playbook, added things I needed for work, went back to Arch and couldn't be happier. With NixOS it felt like there was an extra maintenance fee for doing regular Linux things. It just wasn't worth it for me.

poincaredisk 2y ago
I'm a bit surprised to read it - for me I configured my system years ago and it just "keeps working" (I very rarely need to edit my configuration, for trying new programs I just spawn a nix-shell). Though I agree that first time doing anything has an additional cost - for example configuring my HP printer was maybe three lines of nix code, but I had to spend some time with forums to write them. On the other hand, I now just reuse these lines everywhere and don't have to think about it at all. For me that's a lot of time saved. It's entirely possible you're using OS differently than I do, and cost/benefit calculation is different for you.
- _fsql 2y ago
  If NixOS works well for you, that's great! But from my perspective, the whole NixOS model adds unnecessary complexity and makes you learn ways to do things that don’t really translate to other Linux systems. The directory structure in NixOS is different and doesn't follow the FHS (Filesystem Hierarchy Standard) and the system uses a bunch of symbolic links that feel like "hacks" to keep some kind of compatibility with the FHS. For example, if you want NixOS to recognize paths like /bin or /usr/bin in your scripts, you have to enable services.envfs.enable in your configuration.nix or in a .nix module. If something goes wrong in NixOS, you might run into multiple issues because the problem could be within NixOS, the underlying system, nixpkgs, upstream packages, or a mix of all these factors. Sure, it might save you time in some situations, but when a problem pops up, you'll find yourself in a tricky spot since you’ll have to dig through all the layers of the system to find the root cause. On top of that, you’ll have to sift through the options and the documentation, which can often be pretty confusing.