6 ms·

NixOS solves all of these problems. a) define your entire system state and dependencies in a single, declarative file b) prebake an image based on this file

by q3k 7y ago

NixOS solves all of these problems. a) define your entire system state and dependencies in a single, declarative file b) prebake an image based on this file It's all done and ready, available now, no hacking around required.

dfc 7y ago
(A) is also possible with Debian. OP could just make a pressed file for debinstaller. (B) is probably accomplished with any OS.
pjc50 7y ago
.. but if you discover you need something, you have to go back to (a).
- q3k 7y ago
  Your prebaked image will contain the definition (a), and you can incrementally continue building upon it, then regenerate yet another image if needed.
KirinDave 7y ago
This is precisely what every linux distro does. Nix isn't providing novel functionality for bootable OS images. But a bigger question for the ergonomics of NixOS: Are NixOS and Nix prebuilding for ARM now?
- q3k 7y ago
  > This is precisely what every linux distro does. Nix isn't providing novel functionality for bootable OS images. None of them provide native, single-source-of-truth declarative configuration that is easy to reason about, pure, and guaranteed to deliver sane results every time (vs. something managed via a classic CM system). Oh, also one that it symmetrical to the way the distribution itself is built and managed. > But a bigger question for the ergonomics of NixOS: Are NixOS and Nix prebuilding for ARM now? Yes. https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi Ports to other ARM devices are also very easy.
  - KirinDave 7y ago
    > None of them provide native, single-source-of-truth declarative configuration that is easy to reason about, pure, and guaranteed to deliver sane results every time (vs. something managed via a classic CM system). Firstly: the Nix language isn't pure. And neither are some base Nix library functions. Secondly: You may find it easy to reason about. Many of us have not had that experience. Trying to do work as a developer, I felt it was absolutely miserable the instant I needed to depend on a new package or a new runtime. Every language had slightly different conventions and rules. You had to relearn how any specific package worked to integrate it with another, because there often wasn't sanity. And if you DID need to somehow interface with something outside of Nix (say, a vendor binary not in Nix) you had to use an unreliable environment hack. And of course, the tutorials and docs didn't actually cover the majority of concerns on how to add new stuff folks will inevitably have, except for a trivial C executable. In one case, after spending a week working out how to add a package to enable a Haskell binding to said package correctly, I submitted package updates that took MONTHS to propagate into the main repo, so I had to start pushing my fork of the nix repo from machine to machine via github on my own to manage multiple machines. It was pretty ridiculous and I regretted my choices. I like the Nix philosophy. I respect a lot of the people on the project. But I am not a fan of the "it is all fine and well-baked and I'm sure you can use it too" approach a lot of Nix proponents decide to take. You could absolutely arrive at a solid installable image for ANY major Linux distro. > Yes. https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi That's great! I'll have to try it again there if it has packages I want for SDR work that are not comically ancient.
chme 7y ago
I really like the idea of NixOS and Guix and tried NixOS for half a year on my laptop. Then I changed back to ordinary package based distributions. (Arch, Debian and Gentoo) The issue with NixOS for me was probably quality control. When I did an update and instead of fetching the files from the binary cache it starts to build stuff on its own, I could be reasonably sure that some build error happens. Coupled with sparse documentation, I was very often at a loss at how to fix it and just had to remove the package for a while and try again a couple of days later. Another point is NixOSes path mangling... Do we really need that? Can we not try to use namespaces and OverlayFS etc. to let each process assume it has a normal FHS file-hierachy while in real its 'root' is cobbled together from multiple package installation directories? Instead of patching the paths of every package, letting the kernel do the path calculations seems to be less intrusive.
- huevo5050 7y ago
  You are wrong with build stuff in NixOS, their pure functional approach make easy to guarantee that builds that passed in CI will pass in your machine.
  - chme 7y ago
    In theory you are right, but somehow changes made it into their channels that weren't cleared by the CI and therefor the binary caches didn't have the artifacts in them and I had to build it myself which failed. So in practice updating a Gentoo system is more reliable than updating NixOS.

by q3k 7y ago

dfc 7y ago

(A) is also possible with Debian. OP could just make a pressed file for debinstaller. (B) is probably accomplished with any OS.

pjc50 7y ago

.. but if you discover you need something, you have to go back to (a).

q3k 7y ago
Your prebaked image will contain the definition (a), and you can incrementally continue building upon it, then regenerate yet another image if needed.

KirinDave 7y ago

This is precisely what every linux distro does. Nix isn't providing novel functionality for bootable OS images. But a bigger question for the ergonomics of NixOS: Are NixOS and Nix prebuilding for ARM now?

q3k 7y ago
> This is precisely what every linux distro does. Nix isn't providing novel functionality for bootable OS images. None of them provide native, single-source-of-truth declarative configuration that is easy to reason about, pure, and guaranteed to deliver sane results every time (vs. something managed via a classic CM system). Oh, also one that it symmetrical to the way the distribution itself is built and managed. > But a bigger question for the ergonomics of NixOS: Are NixOS and Nix prebuilding for ARM now? Yes. https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi Ports to other ARM devices are also very easy.
- KirinDave 7y ago
  > None of them provide native, single-source-of-truth declarative configuration that is easy to reason about, pure, and guaranteed to deliver sane results every time (vs. something managed via a classic CM system). Firstly: the Nix language isn't pure. And neither are some base Nix library functions. Secondly: You may find it easy to reason about. Many of us have not had that experience. Trying to do work as a developer, I felt it was absolutely miserable the instant I needed to depend on a new package or a new runtime. Every language had slightly different conventions and rules. You had to relearn how any specific package worked to integrate it with another, because there often wasn't sanity. And if you DID need to somehow interface with something outside of Nix (say, a vendor binary not in Nix) you had to use an unreliable environment hack. And of course, the tutorials and docs didn't actually cover the majority of concerns on how to add new stuff folks will inevitably have, except for a trivial C executable. In one case, after spending a week working out how to add a package to enable a Haskell binding to said package correctly, I submitted package updates that took MONTHS to propagate into the main repo, so I had to start pushing my fork of the nix repo from machine to machine via github on my own to manage multiple machines. It was pretty ridiculous and I regretted my choices. I like the Nix philosophy. I respect a lot of the people on the project. But I am not a fan of the "it is all fine and well-baked and I'm sure you can use it too" approach a lot of Nix proponents decide to take. You could absolutely arrive at a solid installable image for ANY major Linux distro. > Yes. https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi That's great! I'll have to try it again there if it has packages I want for SDR work that are not comically ancient.

chme 7y ago

I really like the idea of NixOS and Guix and tried NixOS for half a year on my laptop. Then I changed back to ordinary package based distributions. (Arch, Debian and Gentoo) The issue with NixOS for me was probably quality control. When I did an update and instead of fetching the files from the binary cache it starts to build stuff on its own, I could be reasonably sure that some build error happens. Coupled with sparse documentation, I was very often at a loss at how to fix it and just had to remove the package for a while and try again a couple of days later. Another point is NixOSes path mangling... Do we really need that? Can we not try to use namespaces and OverlayFS etc. to let each process assume it has a normal FHS file-hierachy while in real its 'root' is cobbled together from multiple package installation directories? Instead of patching the paths of every package, letting the kernel do the path calculations seems to be less intrusive.

huevo5050 7y ago
You are wrong with build stuff in NixOS, their pure functional approach make easy to guarantee that builds that passed in CI will pass in your machine.
- chme 7y ago
  In theory you are right, but somehow changes made it into their channels that weren't cleared by the CI and therefor the binary caches didn't have the artifacts in them and I had to build it myself which failed. So in practice updating a Gentoo system is more reliable than updating NixOS.