Nix is a tool that takes a unique approach to package management and system configuration. Learn how to make reproducible, declarative and reliable systems.
Okay, folks. NixOS needs your help. No bull. I’m talking documenters, designers, coders, package maintainers. Why? Because the NixOS community has a lot on it’s plate right now.
Like I can understand why flakes haven’t become standardised, why it’s still marked as unstable, even though it’s pretty much feature complete, and that’s because nix is a complex environment builder and the current contributes are taxed to the max.
But what is nix?
Nix’s job is to create reproducible environments where you can put any library, any service, any application. It does this through compile time flags and modifying ELF headers to isolate applications on a system to their own, exclusive UNIX path. These are linked together as clojures, or a dependency graphs, that can share libraries, applications and services intetchangably with each othet, or use another version or patched version without causing any dependency conflicts.
You can fire up pretty much whatever you want and it will be reproducible elsewhere. It’s like if you took a package manager, build environments, as well as VMs and micro services and make them kiss.
You can spin up a nix environment on any supported system and expect it to run 1:1. This however breeds complexity and there’s a lack of NixOS contributors.
If only you spin up a nix environment on a VM or use it to replace your current build systems (because nix can use several build systems in one single environment), and then contribute back with some changes to nixpkgs, then you are helping to bring about the most powerful deployment tool since kubernetes.
No joke. Check out how you can contribute, because at the end of the day learning nix is gaining a new superpower.
Okay, folks. NixOS needs your help. No bull. I’m talking documenters, designers, coders, package maintainers. Why? Because the NixOS community has a lot on it’s plate right now.
Like I can understand why flakes haven’t become standardised, why it’s still marked as unstable, even though it’s pretty much feature complete, and that’s because nix is a complex environment builder and the current contributes are taxed to the max.
But what is nix?
Nix’s job is to create reproducible environments where you can put any library, any service, any application. It does this through compile time flags and modifying ELF headers to isolate applications on a system to their own, exclusive UNIX path. These are linked together as clojures, or a dependency graphs, that can share libraries, applications and services intetchangably with each othet, or use another version or patched version without causing any dependency conflicts.
You can fire up pretty much whatever you want and it will be reproducible elsewhere. It’s like if you took a package manager, build environments, as well as VMs and micro services and make them kiss.
You can spin up a nix environment on any supported system and expect it to run 1:1. This however breeds complexity and there’s a lack of NixOS contributors.
If only you spin up a nix environment on a VM or use it to replace your current build systems (because nix can use several build systems in one single environment), and then contribute back with some changes to nixpkgs, then you are helping to bring about the most powerful deployment tool since kubernetes.
No joke. Check out how you can contribute, because at the end of the day learning nix is gaining a new superpower.