Download your free issue of Admin magazine thanks to Tuxcare: https://bit.ly/43XnjhTGrab a brand new laptop or desktop running Linux: https://www.tuxedocompu...
And you, what’s your operating system to code ?
Me, I use Arch btw
What… What problems does Nix solve? throws down his beer What value is precision? Why make a cube about 10cm per side when you can make a cube 10.001 cm ± 0.001 cm? Do you want software that’s a collection of found parts that just happens to work? Or a system engineered to precise requirements?
Rant aside: that sums one difference. Both containers and Nix solve an encapsulation problem. They solve them differently. Containers gives software their own namespace. Nix requires software to exist in an a universal namespace. “/bin/bash” may be different between containers. While “/nix/store/bash-82828def8282829whatever/bin/bash” is always the exact same bash in Nix.
Precision has a cost but sometimes the precision is necessary. Eg: nix is great building closures that contain exactly the software requested and no more. While containers are more imprecise: take a base and add on additional stuff. From a software supply line perspective this can be exactly the precision required.
Nixpkgs is (afaik) the closest thing to Amazon’s internal package system. So the issues it solves is definitely valuable… To at least Amazon scale orgs.
As a dev who likes to tweak their system Nix offers an unparalleled ability to alter deep dependencies and correctly propagate those through everything. Wanna alter libc and rebuild everything - jvm and all - for some Java service? Yep. Nix will handle the build no problem.
Excessive? Sometimes - plenty of systems work fine when dependencies are mutated underneath. However, when there is a need there is NixOS in a class of it’s own.
Also, they are complementary solutions: nix is great at building containers.
What… What problems does Nix solve? throws down his beer What value is precision? Why make a cube about 10cm per side when you can make a cube 10.001 cm ± 0.001 cm? Do you want software that’s a collection of found parts that just happens to work? Or a system engineered to precise requirements?
Rant aside: that sums one difference. Both containers and Nix solve an encapsulation problem. They solve them differently. Containers gives software their own namespace. Nix requires software to exist in an a universal namespace. “/bin/bash” may be different between containers. While “/nix/store/bash-82828def8282829whatever/bin/bash” is always the exact same bash in Nix.
Precision has a cost but sometimes the precision is necessary. Eg: nix is great building closures that contain exactly the software requested and no more. While containers are more imprecise: take a base and add on additional stuff. From a software supply line perspective this can be exactly the precision required.
Nixpkgs is (afaik) the closest thing to Amazon’s internal package system. So the issues it solves is definitely valuable… To at least Amazon scale orgs.
As a dev who likes to tweak their system Nix offers an unparalleled ability to alter deep dependencies and correctly propagate those through everything. Wanna alter libc and rebuild everything - jvm and all - for some Java service? Yep. Nix will handle the build no problem.
Excessive? Sometimes - plenty of systems work fine when dependencies are mutated underneath. However, when there is a need there is NixOS in a class of it’s own.
Also, they are complementary solutions: nix is great at building containers.