141–150 of 259 posts
It's true that Docker is often abused in very creative ways to do what Nix does, but it still remains a different tool with a different goal in mind.
Does Nix have an answer to Docker's support for Windows containers? The ability to mix legacy Windows applications with cloud-native ones is a huge boon for those interested in migrating to a modern stack.
For now you can cross-compile to Windows using Nix and you can run Nix in WSL
Oh god I hope not. Having worked in > 100kloc nix environments I am completely turned off of the idea. I really really tried, I installed NixOS as my main OS and used Nix whenever I could to try and pick it up, but it's such a complex beast I felt it slowed everything down. Simple tasks that would take 10 minutes in Docker suddenly became DevOps tickets. I suddenly had to write bindings for tools rather than apt-get…
> Nix built the entire world
You're comparing apples to oranges.
Docker just runs commands. If you want to run commands, you can do that in Nix using e.g. nixpkgs.runCommand.
apt-get just fetches prebuilt binaries. If you want to fetch prebuilt binaries, you can do that in Nix using e.g. nixpkgs.fetchurl.
You can even use runCommand to run apt-get (I do this to use Debian's Chromium package on 32bit NixOS)
In contrast, it sounds like you were using Nix as a build tool, to define your entire OS from scratch (presumably using Nixpkgs/NixOS). In which case apt-get isn't a comparable command; instead, the Debian equivalent would be:
apt-build world
Earlier quoted context omitted.
For context, I'm referencing our (legacy) base image for projects on Replit: Polygott ( https://github.com/replit/polygott/ ). The image contains dependencies needed for 50+ languages. This means repls by default are packed with lots of commonly used tools. However, the image is massive, takes a long time to build, and is difficult to deploy. Unfortunately, slimming the image down is not really an option: people rely…
> For context, I'm referencing our (legacy) base image for projects on Replit: Polygott ( https://github.com/replit/polygott/ ). May I ask why you didn't use something like Ansible to build such a complex image? With appropriate package version pinning (which it's the real crux here) it should work well enough to get a reproducible build. I understand it would already have been something different from a pure Dockerf…
They did; it's called Nix, and they wrote a blog post about it ;)
Earlier quoted context omitted.
I like to compare Nix to ice-nine from Cat's Cradle, in that it tends towards restructuring whatever it comes into contact with.
Funny you mention that. Guix which is a fork (of sorts) of Nix is written in Guile Scheme which uses ice-9 as it's namespace in a lot of places. https://lists.gnu.org/archive/html/guile-devel/2010-07/msg00...
Aside from this one executable there is no relationship between the two projects.
The daemon takes .drv files that list what preconditions a build has (= other .drv files), what build script to run (= a generated Guile script), and what outputs will exist when the .drv file has been processed. It processes these .drv files in an isolated environment (chroot + namespaces) where only the inputs mentioned in the .drv file are made available.
The drv files are not shared among the projects; they are not generated in even superficially similar ways. Guix is not a fork of Nix. "guix-daemon" is a fork of "nix-daemon".
Both are implementations of the same idea: functional package management.
Earlier quoted context omitted.
Lots of people seem to be building containers with non-Dockerfile based things though, especially in the JVM world.
You mean through maven configuration? At the end of the day it is still a dockerfile but constructed using Maven's xml. I hate it haha
It also builds into the Gradle lifecycle neatly. I don't need a separate tool for building images.
I'm sure writing Maven xml wouldn't be fun though!
Guix supports exporting to Docker containers. A guix.scm file then becomes a reproducible alternative to a Dockerfile. However, Guix has its own container implementation. And this is significantly lighter than Docker (instead of layers, links to /gnu/store) and is root-less. If Guix containers had a runc-compatability layer and better docs/tutorials, it would be hard to go back to Docker/podman.
Could you please elaborate what you mean by "runc-compatability layer"? And what about the docs requires clarification?
(I wrote the original Docker export backend for "guix pack", so I have an interest in improving this feature where necessary.)
I think people are missing the forest for the trees with this. In my view, the reason Docker has all the hype is because I can look at a Dockerfile, and know what's up. In seconds. Sometimes in milliseconds. It's a user experience thing. Yes, Nix is better for 'technical people that spent the time learning the tool', but Dockerfiles rely almost entirely on existing System knowledge. Yes, Nix is 'better', but the fact…
Agreed with your opinion about `Dockerfile`. The article had me for a second until I saw the script code. I mean, my time is not infinite and I rather spend it to do things that are really important to me, not learning to write "yet-another build script" for a small system. So unless it's mainstream already, I'm not going to touch it. `Dockerfile` is light enough for me to not hate it too much. For the `docker-compos…
You don't have to jump into the deep end with Nix. If you're happy to just run shell commands (like Dockerfiles provide), then all you need is this:
(import {}).runCommand "my-package" {} ''
PUT YOUR BASH CODE HERE
''Earlier quoted context omitted.
I don't understand how these are comparable. I also don't understand what you mean by "bindings". Do you mean writing nix derivations for new packages? I would much rather do that than fiddle with Debian packaging. Or do you mean writing nix modules to configure a service? There are certainly some (IMO) over engineered nixos modules, but there are also some dead simple ones.
> I don't understand how these are comparable They fulfill similar business functions - allowing you to run the same code on a bunch of dev machines and on prod (modulo modifications for e.g. database storage in Docker's case). Nix people get hung up on the fact that Docker runs containers, but it doesn't really matter that much. Often Docker is the shortest path to getting software running on multiple machines repro…
with import {};
runCommand "my-python-package" { buildInputs = [ pythonPackages.pip ]; } ''
cd ${/my/project/dir}
pip install
''Along my life, i have worked with a lot of build systems, but I find Nix syntax and commands to be completely awful! I see that it could be useful, but it completely turns me down immediately.
What do you dislike about the language?