Threads for matthewcroughan
-
This is quite cool. I notice that Hugging Face downloads appear not to go through Nix; is there a plan for fixing that?
-
There’s a PR to add NixOS modules that will make all of the fetching occur via Nix, yes https://github.com/nixified-ai/flake/pull/7
-
-
-
-
Yes, NixOS may have spotted this particular issue in the following two ways, in order:
- Hydra’s CI via the ZFS integration test.
- Evaluation of Nix code (assertions and errors before deployment) constraining what Kernel Modules are required in the initramfs
if the issue is undetected and bypasses 1 or 2, each
nixos-rebuild switchcreates a new bootloader entry anyway, which allows you to boot from the previous configuration’s initrd/kernel. This means recovery from this scenario is a simple as selecting that old option from the bootloader after rebooting.In short, issues have to bypass 1 and 2 first before it can effect the user, and when it does effect the user they can often just rollback to the old configuration.
-
matthewcroughan
2 months ago
|
link
| on:
nix-init - Generate Nix packages from URLs with dependency inference, hash prefetching, and more
Literally my favourite Nix tool yet written, second only to the nil (nix language server)
-
Ah cool! Reminds me of https://nix.ug
-
but Dockerfile is much more simple and easy to use.
-
simpler to start, harder to get the details right - especially as your matrix of (supported platforms to run and test on * variants of your software to package * external depdencies to handle) grows.
The learning curve with nix is much steeper - far too steep atm IMO, but its being worked on; flakes and the new nix cli are a step forward. - but nix covers much more ground than dockerfiles as well.
Come for the dockerfile replacement, stay for the generic build system, whole-system configurations, home-manager and more.
-
As someone who has made both Dockerfiles and a
flake.nixfor a project, as well as currently use both Nix and Docker/OCI tooling almost daily, I just cannot agree with most of your assertions.Even amongst nix flake enthusiasts there is conflicting info on how to do a nix flake “properly”. The examples in the video showing the problems with Dockerfiles are convoluted. How often do packages go missing from debian or ubuntu? If you’re using “ubuntu:latest” and don’t mean to, then you’re doing something wrong (and also unusual) - normally you would pin to a version (i.e. “ubuntu:20.04”) or even specify the exact hash of the image you want to use.
My feeling is that Nix flakes and Dockerfiles prioritize different strengths and to say one is the replacement for the other is kind of like saying “shoes are better than sandals! you won’t stub your toes and you wont get wet.” okay… well what if that’s not what I prioritize…
-
I’ve worked with both as well, and I can’t disagree ;)
Even amongst nix flake enthusiasts there is conflicting info on how to do a nix flake “properly”.
Yes, this is unfortunate. But to be fair, flakes are still “experimental” and might not be “there” yet for any possible use case, but they do already support a wide variety of use cases. Especially when combined with flake-aware tools such colmena or support libraries such as flake-utils(-plus).
My feeling is that Nix flakes and Dockerfiles prioritize different strengths
That’s a good point, that I’ve tried to make as well. Dockerfiles are definitely more “portable” between your co-workers or community members.
But nix(os) offers a rich eco system, where you can choose tools and parts to build beautiful OCI images (or whole vms, from the same expression!) and which don’t break because some dependency in your ubuntu base image does not match with your third-party repo or npm dependency. We’ve all been there, I guess :D
-
Sidetrack to say that I’ve done the pin to ubuntu sha hash and that ends up not working after a while when a package is renamed or does go away because of version bump in the package name itself or similar. I don’t remember the exact details but it sucked being bitten by pinning of the image but that doesn’t matter when the apt repository changes between image build runs (on the order of months).
-
-
-
-
At a great cost. That cost is reproducibility. And I value that more than anything. Though different people value different things.
-
Reproducibility is a term which means different things to different people. There are plenty of occasions when nix expressions are pulling down binary blobs. So definitely not reproducible from source in all cases. I like Nix, and use it daily, it’s just more pain than benefit in most places where I use Dockerfiles.
-
If you had watched the talk, I explain that Nix is only making the claim that the inputs will be the same every time. That’s all it does, and all it can do. Build determinism is assisted by the sandbox. Read the section of the thesis called “enforcing purity” to learn more. https://edolstra.github.io/pubs/phd-thesis.pdf
-
-
-
Have used this on my phone as a daily driver for a very long time now, I met Daniel Fullmer in Costa Mesa when I went to SCaLE20x, sadly he doesn’t have the time to maintain the project like he once did. I’ve been playing around with Mobile NixOS since I’m getting tired of android. Mobile NixOS is also awe-inspiring as Robotnix is.