3 ms·
The people at nixos and guix are doing it differently. No longer is the configurarion just state in files, scattered who knows where that cannot be understood f
by f1refly 4y ago
The people at nixos and guix are doing it differently. No longer is the configurarion just state in files, scattered who knows where that cannot be understood fully by anyone. Insteady everything is defined centrally and then neatly versioned and managed by the system. If you think the unix way of throwing files in a directory sucks, check them out!
- nomel 4y agoThis sounds incredible, assuming there's a clean way to pin versions/source of applications. It might make the fabled idea of a reproducible system possible.
- f1refly 4y agoGuix makes a big deal out of being fully reproducible. It is possible to pin versions, you basically state "I want package X while the guix repository is at commit hash Y". Every dependency of the package will be built and made available at the appropriate version and everything will work out. I used this to roll back fprintd when it broke due to a broken dependency and it worked without problems.
- momentoftop 4y agoThey're already getting decent reproducibility of their curated package set, but some of us want to pin to a particular version of this, especially when creating our own private packages. That's where I'm finding I really want pinning. The latest release has included "flakes", promoted from an add-on to an opt-in feature and which, among other things, lets me pin my dependencies and the environment I need to build my private projects. I then don't have to worry about going out of sync with the main package set, and I can share private projects in a (hopefully) fully reproducible way, with people using different versions of nix. https://xeiaso.net/blog/nix-flakes-1-2022-02-21 https://xeiaso.net/blog/nix-flakes-1-2022-02-21
- behnamoh 4y agoUnfortunately, Nix's documentation sucks. Plus, there's a steep learning curve to the Nix programming language. I don't understand why they couldn't just use a language instead of inventing one that is only usable within the Nix system. Overall, really cool idea (dropped my jaw when I first saw it in action), but poorly implemented.
- _piif 4y agoWouldn't say there's a steep learning curve for the language itself, it's pretty easy to get a grasp around it imo. Here's a helpful page I used to quickly get familiar with the language: https://github.com/tazjin/nix-1p https://github.com/tazjin/nix-1p What's rather messy about Nix is nixpkgs with its helper functions all over the place alongside pretty shallow / non-existent documentation (which is unrelated to the language). Thankfully they've started to work on that recently: https://discourse.nixos.org/t/documentation-team-flattening-the-learning-curve/20003 https://discourse.nixos.org/t/documentation-team-flattening-...
- momentoftop 4y agoI think it's all too easy to say they should have just used an existing language. The most obvious feature of the nix language is that it's lazy, because they want their enormous collection of configuration dictionaries computed on demand. There are no mainstream languages that are lazy. Well, there's Haskell, and I expect any Haskell programmer to be able to pick up Nix very quickly. Guix has gone with a strict language, Scheme, but I understand they have their own monadic DSL to cope with the peculiarities of following the Nix model. So again, not something that a mainstream language can do well, and even as a Schemer, you're going to have to learn their macro language.