3 ms·
The primary value in nix is in the packages, not the configuration language and not the prebuilt cache system. If one were to fork the project, the sensible wa
by Borealid 2y ago
The primary value in nix is in the packages, not the configuration language and not the prebuilt cache system.
If one were to fork the project, the sensible way to do that would be to build a nixpkg-compatible alternative system that doesn't have some of the design flaws (such as a global non-discoverable configuration namespace and an underdocumented custom functional programming language...).
I don't think anyone's gotten together the hours to do that. But I'd certainly love to build an immutable, repeatable system using a Python or Kotlin config myself.
- rijoja 2y agoRight but the people complaining doesn't seem to think that an "underdocumented custom functional programming language", is a design flaw. So given those assumptions, why don't they fork it? Also when you say that the value in nix lies in the packages what exactly do you mean by that? Do you mean the totality of all the prebuilt and checksummed packages? If you where to fork-fork, and not rebuild nix, wouldn't you still be able to use them? Apart from what is built afterwards?
- Borealid 2y ago"The packages" are the "the files describing how to go from source code to an organized filesystem hierarchy containing the useful portions of a particular piece of software". That's the good part of nix, much like it's the good part of the Arch User Repository (AUR), and the BSD Ports system. I think the people who think the nix language is the valuable part are trying to save it, not fork it. But that's a generalization. A fork would be able to use nixpkgs even if it didn't use nix-the-language itself, with some careful planning for migration.