51–60 of 64 posts
Something I have never understood is why the hard-on with Nix, and Guix is not heard of even a tenth of the times. Is GPL really so repulsive to the masses? Or the libre kernel default?
The future of software is Nix in the same sense that the future of software was Bitkeeper. It was readily apparent to anyone using Bitkeeper that this was the right way for version control software to work. Similarly, the Nix model is clearly correct. But just as Bitkeeper was a clumsy early attempt at implementing that paradigm, so is Nix. The article says that "Nix is declarative" which could not be further from th…
Back in the day, adopting Git was also clumsy and hard to implement. It was buoyed significantly by the investments GitHub made into its usability. I agree Nix is going to have to evolve to gain wider adoption. It's part of the work we're seeing in the ecosystem, and also work we're already doing :).
The future of software is Nix in the same sense that the future of software was Bitkeeper. It was readily apparent to anyone using Bitkeeper that this was the right way for version control software to work. Similarly, the Nix model is clearly correct. But just as Bitkeeper was a clumsy early attempt at implementing that paradigm, so is Nix. The article says that "Nix is declarative" which could not be further from th…
I remember being enamored by Haskell in college and I asked my professor why pure functional languages aren't more popular. His answer really stuck with me. He said: because reality is stateful.
Reality is stateful. As a consequence, declarative configuration leaks like a sieve, and leaky abstractions suck. When you think about it, declarative configuration is just a DSL for implementing idempotent deployment flow, and idempotent deployment flows in general are quite successful (e.g., Docker, Flatpak, Ansible), and so declarative configuration tends to work okay for restricted subsets of those domains.
We have Nixstan on "Ops Team" who keeps pushing us to use it. We haven't seen need that much. So can someone give me elevator pitch that if we are CRUD Web App, why Nix instead of Puppet/Ansible + Docker Containers? Also, this from the blog article: "What if adopting Nix didn’t irritate your IT or security teams?" Too late, security team is already pissed. They did some scan, we pinned a package, it has 3 high severi…
For better or worse, Nix forces you to work out the exact dependency tree of your entire system. It can be a pain but once you have it, if one part of that tree changes, nix can rebuild only and exactly the parts of the system that depend on it. That goes all the way through from packages and libraries to systemd services and application config files. That happens safely, reliably, is extremely cacheable, and is done in a way that can actually be perfectly reverted to a previous version. You can build docker images with nix and the result is very small minimal images (it's effectively a `FROM scratch` every time but with a potentially even better layer structure that again can be more cacheable than a typical Dockerfile setup).
From a security perspective, Nix can be a huge win since it gives you such precise control over what's installed on your system and makes it simple to track, every part of it checks cryptographic hashes, etc. But yeah, most security teams don't know what to do with it yet and probably don't have the tools to deal with it yet.
The future of software is Nix in the same sense that the future of software was Bitkeeper. It was readily apparent to anyone using Bitkeeper that this was the right way for version control software to work. Similarly, the Nix model is clearly correct. But just as Bitkeeper was a clumsy early attempt at implementing that paradigm, so is Nix. The article says that "Nix is declarative" which could not be further from th…
Outside Nix, there's Brioche (my project!), and there's also Vorpal and Tangram, all of which are "Nix-like" but are from-scratch projects instead of using any Nix tooling
So I definitely agree that Nix as an _idea_ is right, and I definitely also agree that NixLang is a blocker for mass adoption. Personally though, I think if you dig deeper, there are other places that could use improvement beyond just the language itself (but nothing that would necessarily be a show-stopper for adoption IMO). But that's why my project is a "Nix-like"-- there are things that I think Nix could / should do, but which aren't really compatible with the way Nix itself works. One example: Brioche works without having a global store path-- it's per-user instead so that it can be installed rootlessly-- which doesn't really map well to how Nix itself handles store paths and dependencies
So point is, I agree Nix is the right model, but I think the _real_ gold lies outside Nix itself (...with the side note that I'm obviously biased!)
I really like Nix package management. I really hate Nix configuration management. I already know how to configure everything. I don't want to have to figure out whatever abstracted config options some random package maintainer decided on.
I wouldn't be mad if opening the system preferences and setting my timezone also updated my timezone in Nix. I am mad that I can't change my timezone when I travel, because the GUI picker doesn't know that Nix has taken ownership, so only changes in Nix take effect.
Earlier quoted context omitted.
As a response to (ii), I assure you that things are most certainly not moving very fast with experimental stuff like flakes. Flakes were first released as "experimental" almost 3 years ago and have been stuck in feature purgatory ever since.
To be blunt, this is driven by the rejection of flakes by a significant group of the contributor base, despite it being much more adopted by the user base at large. Even as someone who does think Flakes are better than the prior solutions, I'm increasingly of the opinion that Flakes would be better moved to a layer outside the core Nix project - advancing them within core Nix at this stage seems pretty impossible wit…
Earlier quoted context omitted.
As a response to (ii), I assure you that things are most certainly not moving very fast with experimental stuff like flakes. Flakes were first released as "experimental" almost 3 years ago and have been stuck in feature purgatory ever since.
To be blunt, this is driven by the rejection of flakes by a significant group of the contributor base, despite it being much more adopted by the user base at large. Even as someone who does think Flakes are better than the prior solutions, I'm increasingly of the opinion that Flakes would be better moved to a layer outside the core Nix project - advancing them within core Nix at this stage seems pretty impossible wit…
I posted some information and metrics about that on Discourse:
https://discourse.nixos.org/t/announcing-determinate-nix/547...
Earlier quoted context omitted.
> Kill the language and replace it with configuration No. Hard no. Please don't tell me you are going to kill a fine (even though awkward) configuration language and replace it with (potentially text-templated) yaml.
I think I would rather replace it with a spec for derivation files implementable in any language that existing build systems can hook into and use as outputs. make derivation python -m build derivation Trying to package software with dependencies that don't exist in nixpkgs is painful despite the tooling existing to build and install them.