How fast is nix on delivering security patches? I am looking for arguments to use it in an enterprise setting given the declarative nature but unless there is somebody who will sell you a support contract and Guarantee security updates it seems like a hard sell
Zero to Nix, an unofficial, opinionated, gentle introduction to Nix
121–130 of 227 posts
Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix
#122I would love to see a discussion from somebody who really likes Nix on why it isn't ready for prime time yet/just play devil's advocate aloud on why it isn't the greatest thing since sliced bread. I feel like I must not be doing anything "serious" enough to need package reproducibility at that high level. I'm aware of things like git checkout/tags, package-lock.json, Cargo.lock, Docker image tags. What is a real worl…
> ... why it isn't ready for prime time yet ...
I think for a professional / team setting, its learning curve is sufficiently steep enough that it'd be risky to adopt with only one or two team members familiar with Nix.
Writing Nix code for your own packages varies in difficulty from 'trivial' to 'demands you know a lot about Nix, the compiler, Linux, and your software package'.
> What is a real world use case where Nix isn't overkill? ...
I'd rephrase this as "nix is 2nd best at everything".
So, yeah.. to setup tools you could use asdf; provision a system you could use ansible; to build an image you could use packer; etc. -- But, if you've already paid the (steep) learning curve for nix, it's going to be a better choice when doing anything that involves packages.
I'd put emphasis on "declarative" more than I'd emphasise "reproducible", though.
> It feels like the Kubernetes of package management/build if you will complexity wise.
This is an apt comparison.
However, there Kubernetes alternatives are often simpler with 80% of the power.
With Nix, there's nothing that's simpler that handles as many use cases.
Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix
#123Earlier quoted context omitted.
> Why should I invest time? It's not for everyone. Specifically, because Nix's 'costs' are upfront (for likely future benefit), nix isn't well suited to just-get-it-done pragmatic attitudes. -- e.g. if you'd prefer to just launch VMs from the web console, over using a tool like Terraform, then Nix isn't going to be for you. Nix isn't too difficult to use . I'd say it's 95% wonderful, 5% huge pain to deal with. (Writi…
How does Nix compare to Environment Modules: https://modules.sourceforge.net/ Am I correct in understanding they are similar, except Nix has the "pure" package building?
This is not Nix, but in showing the Environment Modules support for Guix the blog post also shows how functional package management (as implemented in Nix and Guix) differ:
https://hpc.guix.info/blog/2022/05/back-to-the-future-module...
Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix
#124I wish guides like these contained screenshots. Do people use Nix for desktop OSes? As a VM they SSH into? A collection of config scripts that they don't directly issue commands to? I certainly can't tell from a quick glance of this guide
Been using it as my desktop for about 5 years and have never looked back.
Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix
#125I'm trying Nix this weekend, and I'm surprised that many part of the core nixpkgs library are mostly undocumented. For example, searching with `"stdenv.isLinux" site:nixos.org -site:discourse.nixos.org -site:releases.nixos.org` returns a single result in total, which only contain the one usage of the function but no other list of available stdenv.is* functions.
Maybe `isLinux` is not the best example, as it's pretty much a self-documented boolean. But when I'm in the general situation you describe, I tend to just search github.com/NixOS/nixpkgs in order to figure out usage, if it's not documented elsewhere already.
Here is an example for isLinux specifically: https://github.com/NixOS/nixpkgs/search?q=isLinux
Reading through how the stdenv stuff is working might help as well, the generic lists a bunch of "is" booleans: https://github.com/NixOS/nixpkgs/blob/7e325cb89453651dbe9a17...
In general I agree, things are vastly under-documented, and that makes it kind of hard, and only solution I've found is digging deeper into sources. Which had the happy side-effect of me understanding NixOS better as well.
Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix
#126I would love to see a discussion from somebody who really likes Nix on why it isn't ready for prime time yet/just play devil's advocate aloud on why it isn't the greatest thing since sliced bread. I feel like I must not be doing anything "serious" enough to need package reproducibility at that high level. I'm aware of things like git checkout/tags, package-lock.json, Cargo.lock, Docker image tags. What is a real worl…
I love Nix, all of my machines run NixOS, but I think it's 5-10 years out from widespread adoption. Currently the biggest issues have to do with severely lacking documentation, lack of developer tooling (missing things like LSP), very slow iteration cycles, confusing or impossible to understand errors, and even naming (Nix refers to the language, package manager, cli, community, etc). That said, right now it's still…
> I think it's 5-10 years out from widespread adoption
To quote Andy Warhol, "They always say that time changes things, but you actually have to change them yourself."
I don't mean you personally! I mean that it's not clear how time is going to fix Nix's documentation.
My guess is that at some point a big company will either clone or copy NixOS and enforce some discipline on the documentation. At that point it'll take over the world.
Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix
#127I would love to see a discussion from somebody who really likes Nix on why it isn't ready for prime time yet/just play devil's advocate aloud on why it isn't the greatest thing since sliced bread. I feel like I must not be doing anything "serious" enough to need package reproducibility at that high level. I'm aware of things like git checkout/tags, package-lock.json, Cargo.lock, Docker image tags. What is a real worl…
I think you get that in most posts advocating for nix: its hard to spinup on as a concept/system.
At least for me personally, I've always tried to add that disclaimer, and very few nix-accolades recommend nix _wholesale, no questions asked_ to a random viewer. Almost everyone I know who is all-in on nix recommends nix with caveats, and only after doing some vetting of who you are recommending it to.
That said, even though it is hard... the pain is worth it in the end. Once you get over the hump, its a refreshing ecosystem to rely on overall. One of the main reasons I say that is because it is uniquely positioned to hit both the throwaway script and the production system. You can use it to do all of the following:
- Install things to the system temporarily
- Write scripts that are copy-pasteable between machines
- Setup monorepos with multiple languages targeted
- Run "bare metal" docker-like systems directly on the host
- Build bare-minimum docker containers
- Configure your host OS in a reproducible way
- Build prod servers in a reproducible way
- Safely upgrade/rollback a computer
- Share computer configuration in a simple data-driven mannerRe: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix
#128Earlier quoted context omitted.
# What's opinionated about Zero to Nix Zero to Nix is opinionated because it advocates learning and using flakes and treating channels as deprecated. Zero to Nix also deviates from official recommendations in that it recommends installing Nix using Nix Installer rather than the official Nix installation script. https://zero-to-nix.com/about#whats-opinionated-about-zero-t...
To me using the word opinionated is a deterrent. Any time I hear the word opinionated used it usually means the opinion(s) expressed are overly strong, stubborn, and/or negative. I was expecting the guide to call out issues with the official documentation in a way that could upset the people working on the official docs. But this is just an alternative method. Hardly opinionated.
As a nix user I agree. Nix needs to make flakes stable ASAP. It creates a lot of confusion for new users and friction for getting started. "Do I use the thing that's deprecated but stable or the thing that's unstable but is the future of nix?"
Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix
#129Earlier quoted context omitted.
I love Nix, all of my machines run NixOS, but I think it's 5-10 years out from widespread adoption. Currently the biggest issues have to do with severely lacking documentation, lack of developer tooling (missing things like LSP), very slow iteration cycles, confusing or impossible to understand errors, and even naming (Nix refers to the language, package manager, cli, community, etc). That said, right now it's still…
> I think it's 5-10 years out from widespread adoption To quote Andy Warhol, "They always say that time changes things, but you actually have to change them yourself." I don't mean you personally! I mean that it's not clear how time is going to fix Nix's documentation. My guess is that at some point a big company will either clone or copy NixOS and enforce some discipline on the documentation. At that point it'll tak…
> I mean that it's not clear how time is going to fix Nix's documentation.
This is my estimate based on the work that has happened over the last two years. There is steady movement in the right direction and the community is organized alongside the NixOS Foundation members to make things happen. Just not at a break-neck pace. Places like Determinate Systems, Tweag, etc are the largest forces currently, but there are plenty of others that are trying to move things along. Over time, that steady movement will land Nix in a place where its pains have been largely dealt with. I don't think we're there yet and, at this pace, won't be for a while.
Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix
#130Earlier quoted context omitted.
Do you symlink your config repo to /etc/nixos or something else? So far, I've just been rsyncing my config repo folder after I modify it.
I don't; my config lives in ~/flake, and I run `nixos-rebuild ... --flake ~/flake` whenever I update it.
You don't have to specify the nixosConfiguration name (e.g ~/flake#my-configuration)? Do you just name it "default" or something for that to work? I've never tried that.