I have honestly avoided NixOS for quite a while because the situation seemed "unstable". I don't particularly care for the complaints brought about by the open letter, I do however worry if a distribution/community is imploding.
Regarding the stability of the project: The project and distribution is incredibly vibrant, and not going anywhere. There are tens of thousands of organizations that depend on it every day, and projects that are funded on the time scale of decades. It's here to stay.
1. Reducing the number of moving parts, so there are fewer interfaces that need to be documented and understood ... because they don't exist.
2. Resources like https://zero-to-nix.com/, and https://docs.determinate.systems/.
This is a big lift, though, so anything we do here in the near future will definitely not be enough.
I like Nix, but what turns me off most is this kind of hyperbole from its evangelists. "tens of thousands of organizations" depend on Nix every day? How do you even come up with that kind of number? And as someone who has actually worked on projects that are funded for decades: the first rule is that things are changing, so stay flexible, chose boring technology, and always have a plan for migration. Binding yourself to a niche framework that is also strongly opinionated with an arcane syntax is pretty much the worst you could do.
As you say, Nix is already over 20 years old, so yes, it's probably not going anywhere, but that goes both ways: it will probably not vanish in the near future, but it'll probably also not become really popular. And that's fine.
Nix feels similar, but for build systems, package management, and configuration management all at once.
On Monday, we launched Determinate Nix to help make this promise more real: https://determinate.systems/posts/announcing-determinate-nix.... Note: Determinate Nix is not a fork, it is a downstream. Our plan, and intent, is to keep all our patches sent to the upstream project first.
And what happens if the Nix community doesn't pull those patches, and instead goes with a different solution? Will your downstream adapt to the upstream project, possibly breaking things for your customers?
Indeed, part of the motivation for our downstream distribution is to be able to ship some of our patches faster than upstream wants to. However, these patches are generally about usability improvements that are not incompatible.
If the upstream project evolves in a different direction, it will be on us to move with them too.
Everything else we have is, and all of our improvements to Nix are, open source and permissively licensed. That includes Determinate Nix Installer and zero-to-nix, both of which are permissively licensed with the hope and intention of the upstream project adopting or integrating the material as they saw fit.
nix build github:tailscale/tailscale
I point Nix at an "address" and it knows which set of Nix build instructions to use. Basically that Tailscale repo has a flake.nix in the root that Nix looks at, specifically at the flake outputs. From there, it sees that there is an attribute called "packages" and then it sees that there's a package for the current system called "default," and then it builds that. So Nix expressions have universal "addresses" (they also did before flakes but flakes provide a standard structure for outputs and built-in pinning via flake.lock files).
1. Project-specific development environments. You want everyone on your team to have the exact same version of Python, jq, Terraform, Cargo, and Bun in a specific project? Nix can do that. 2. Home environments. You want to replace your dotfiles and Homebrew and apt-get with something declarative that you have an actual language for? Nix can do that.
So yeah, development environments, home environments, whole Linux systems, OCI containers, standard packages (like CLI tools), things like VS Code extension, Neovim plugins... all of this stuff can be built using Nix. Pretty powerful stuff.
1. Enable systemd: https://devblogs.microsoft.com/commandline/systemd-support-i...
2. Install as normal:
curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install --determinate
3. https://zero-to-nix.com/ :)
- I'd update Nixpkgs, and my build would stop working. The logging was awful, so fixing it took hours.
- The mono repo sounds nice, but selective updates are almost impossible.
- Building our Go project in a Nix package was nearly impossible with private GitHub repos, so we moved on.
- Bash scripts never work because binaries are never where they should be in Linux.
I could go on, but my experience with Nix and NixOS left me with significant scars. I’m hopeful that someone will eventually create a more user-friendly deterministic OS.
Yes. This is a nightmare, and is the literal step-one problem FlakeHub is designed to solve.
Regarding the monorepo causing big-bang updates that broke all your stuff: continued, strong, agreement. I think as nixpkgs continues to grow, and usage grows, we'll see a wider adoption of flakes from a pure "how do we all work together?" perspective. That's the flip side of FlakeHub's initial concept.
https://nixos.wiki/wiki/Nix-shell_shebang
It should add everything to $PATH, so unless you've got hardcoded bin paths, there shouldn't be any problems.
Is there anything on the horizon which could embrace the ideas in a better package? Does Guix smooth over enough rough edges?
