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
I’ve been interested in Nix for a while but haven’t devoted any time to it. What do you like about it? What problems does it solve? Why learn the Nix way of doing things when I could make a container using LXD and just transfer the container around?
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.
Package management is the ultimate problem that was previously left unsolved (no, docker just pushes the problem away, doesn’t solve it. That apt install won’t be the same now as it was when you wrote it). Nix is the first thing that actually solves it properly.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
I’ve been interested in Nix for a while but haven’t devoted any time to it. What do you like about it? What problems does it solve? Why learn the Nix way of doing things when I could make a container using LXD and just transfer the container around?
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.
Package management is the ultimate problem that was previously left unsolved (no, docker just pushes the problem away, doesn’t solve it. That apt install won’t be the same now as it was when you wrote it). Nix is the first thing that actually solves it properly.