3 ms·

You can write Chef targeting OpenBSD and run it in local mode. Get to use plain Ruby instead of a hodgepodge functional programming language. NixOS modules tend

by vngzs 5y ago

You can write Chef targeting OpenBSD and run it in local mode. Get to use plain Ruby instead of a hodgepodge functional programming language. NixOS modules tend to be more "batteries included" than your average Chef cookbook, but if you stick to using native Chef resources you get something (pseudo-)declarative and powerful. Disclaimer: I use NixOS every day and I love functional programming. But boy do I wish Nix had picked Haskell, OCaml, or Lisp instead of inventing a programming language.

dr-neptune 5y ago
Have you considered GNU Guix? It's modeled after nix but uses guile as a configuration language: https://guix.gnu.org/ https://guix.gnu.org/ I also used nix for a while and found the transition painless on my non-nvidia machine
- grawp 5y ago
  Heavy Nix user here. Since month two I've been using flakes for everything: In projects to holds packages and devshells together with inputs locked via lock files, for holding system configuration, raspberry pi images, nixpkgs overlays etc.. Does GUIX have some similiar thing which can provide a standard formal structure and lock resouces? Thx.
  - LanternLight83 5y ago
    Not that I know of, but ideas continue to trickle down, so I look forward to a reimplemention for Guix in the future. Something like nix-index would be great too, but all in due time, as the project admittedly doesn't have quite as many resources. edit: to be clear, I'm taking about flakes, Guix does have plenty of mechanisms and utilities regarding direnv-esque project manifests, lockfiles, and even "inferiors" which let you install outdated packages that the distribution has otherwise moved on from by actually building and using the version of guix that the package would have been built with at the time
- anthk 5y ago
  I guess it's an Intel iGPU. Radeon it's worse than Nouveau, the first one depends on semi free drivers... with non-free firmware.
- vngzs 5y ago
  I like the design of Guix more than NixOS, but I haven't gotten around to actually trying it. The tricky thing about GNU distros is they often make it very difficult to install nonfree packages like Discord. I don't use proprietary software very often, but when I do I prefer to have it available in my distro's package manager. Besides that, I look forward to giving it a chance.
  - _emacsomancer_ 5y ago
    It's pretty trivial to install whatever you like with Guix. The ability to add channels (~repos) makes it particularly easy. There's, for instance, the nonguix channel: https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix and the (nonfree) Guix Gaming Channels: https://gitlab.com/guix-gaming-channels https://gitlab.com/guix-gaming-channels etc.
soraminazuki 5y ago
Chef isn't an alternative to NixOS. Chef is imperative and stateful as it could possibly get. The whole thing is piles upon piles of unrestricted Ruby code that gets evaluated during deployment. NixOS has the exact opposite design. Compared to NixOS, Chef's design allows for flexible deploy time decisions, but it comes at a price. With Chef, it's hard to ever predict everything that's going happen during deployment. Chef code takes a bunch of external inputs in the form of Chef attributes and also has full visibility into server state. All of this happens during deployment. So to make sense of what would happen during deployment, you'd have to run your Chef code in the exact same environment as your target server. To make things even more challenging, Chef code can easily mutate server state irreversibly unless you go to extreme lengths to prevent it. NixOS, on the other hand, prioritizes predictability and reproducibility. It builds the files required for deployment beforehand in a sandboxed environment before the deployment phase, with all the necessary inputs fed upfront. During deployment, it mostly copies those files into an isolated location under /nix/store and creates symlinks to them in /etc and elsewhere to activate the system. Figuring out what would happen during deployment beforehand is a matter of inspecting the built files. Furthermore, unlike Chef configuration, NixOS configuration doesn't concern itself with deploy time actions. Its focus is on expressing static configuration. The Nix language is used for this purpose, so comparing it the against unrestricted general purpose programming languages is a mistake. A better comparison would be languages like JSON, YAML, Jsonnet, and Dhall.

by vngzs 5y ago

dr-neptune 5y ago

Have you considered GNU Guix? It's modeled after nix but uses guile as a configuration language: https://guix.gnu.org/ https://guix.gnu.org/ I also used nix for a while and found the transition painless on my non-nvidia machine

grawp 5y ago
Heavy Nix user here. Since month two I've been using flakes for everything: In projects to holds packages and devshells together with inputs locked via lock files, for holding system configuration, raspberry pi images, nixpkgs overlays etc.. Does GUIX have some similiar thing which can provide a standard formal structure and lock resouces? Thx.
- LanternLight83 5y ago
  Not that I know of, but ideas continue to trickle down, so I look forward to a reimplemention for Guix in the future. Something like nix-index would be great too, but all in due time, as the project admittedly doesn't have quite as many resources. edit: to be clear, I'm taking about flakes, Guix does have plenty of mechanisms and utilities regarding direnv-esque project manifests, lockfiles, and even "inferiors" which let you install outdated packages that the distribution has otherwise moved on from by actually building and using the version of guix that the package would have been built with at the time
anthk 5y ago
I guess it's an Intel iGPU. Radeon it's worse than Nouveau, the first one depends on semi free drivers... with non-free firmware.
vngzs 5y ago
I like the design of Guix more than NixOS, but I haven't gotten around to actually trying it. The tricky thing about GNU distros is they often make it very difficult to install nonfree packages like Discord. I don't use proprietary software very often, but when I do I prefer to have it available in my distro's package manager. Besides that, I look forward to giving it a chance.
- _emacsomancer_ 5y ago
  It's pretty trivial to install whatever you like with Guix. The ability to add channels (~repos) makes it particularly easy. There's, for instance, the nonguix channel: https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix and the (nonfree) Guix Gaming Channels: https://gitlab.com/guix-gaming-channels https://gitlab.com/guix-gaming-channels etc.

soraminazuki 5y ago

Chef isn't an alternative to NixOS. Chef is imperative and stateful as it could possibly get. The whole thing is piles upon piles of unrestricted Ruby code that gets evaluated during deployment. NixOS has the exact opposite design. Compared to NixOS, Chef's design allows for flexible deploy time decisions, but it comes at a price. With Chef, it's hard to ever predict everything that's going happen during deployment. Chef code takes a bunch of external inputs in the form of Chef attributes and also has full visibility into server state. All of this happens during deployment. So to make sense of what would happen during deployment, you'd have to run your Chef code in the exact same environment as your target server. To make things even more challenging, Chef code can easily mutate server state irreversibly unless you go to extreme lengths to prevent it. NixOS, on the other hand, prioritizes predictability and reproducibility. It builds the files required for deployment beforehand in a sandboxed environment before the deployment phase, with all the necessary inputs fed upfront. During deployment, it mostly copies those files into an isolated location under /nix/store and creates symlinks to them in /etc and elsewhere to activate the system. Figuring out what would happen during deployment beforehand is a matter of inspecting the built files. Furthermore, unlike Chef configuration, NixOS configuration doesn't concern itself with deploy time actions. Its focus is on expressing static configuration. The Nix language is used for this purpose, so comparing it the against unrestricted general purpose programming languages is a mistake. A better comparison would be languages like JSON, YAML, Jsonnet, and Dhall.