[deleted]
The Curse of NixOS
31–40 of 361 posts
Re: The Curse of NixOS
#32In the footnote:
> borgcfg ... Truly one of the worst languages I have ever seen.
I'll see your borgcfg and raise you a reverse-Polish notation stack based one, written in a couple of hours and supporting a repo trading system for an investment bank for years.
Re: The Curse of NixOS
#33"""The first is relatively simple: they developed their own programming language to do configuration, which is not very good and is extremely difficult to learn. The vast majority of people using NixOS do not understand the language, and simply copy/paste example configurations, which mostly works until you need to do something complicated, at which point you're completely high and dry.""" Maybe this is nitpicking, b…
> Maybe this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions". Maybe that is difficult for people who haven't had an experience with pure/functional programming? I've programmed professionally in Lisp (SBCL) and Clojure, and done a lot of hobby work in Haskell and Rust. I found Nix the language utterly incomprehensible largely because of documentation and tooling reasons.
I've programmed professionally in Haskell, I find Nix the Language to be one of the nicest DSLs for defining build pipelines. It's lazy, pure, and it's sandboxed. Whenever you need types on top of it you just pick Dhall and dhall-nix and continue with a productivity gain.
Re: The Curse of NixOS
#34I tried using NixOS on a laptop for a month and switched back to Arch a couple of months ago. It was an interesting experience - I never used functional programming language before, but nix was pretty ok as a configuration language. It looks like funny version of JSON with functions. Debugging it was a real pain though - I was trying to write (or copy from someone else config) a function to recursively import all mod…
> I haven't found a clear list of packages that were going to be updated.
The ideal here, IMO, is to use flakes and the nix-diff to compare the build before switching. E.g.
nixos-rebuild --flake '.#myhost' build
nix-diff /nix/var/nix/profiles/system result
sudo nixos-rebuild --flake '.#myhost' switch
Re: The Curse of NixOS
#35Earlier quoted context omitted.
> Maybe that is difficult for people who haven't had an experience with pure/functional programming? I found my understanding of the Nix language became a lot better once I started learning some Haskell. Specifically once I understood what currying was about. My real gripe with Nix is the lack of a complete, easy to find, documentation of its "standard library". Nix Pills & a few wiki pages are far from enough.
> My real gripe with Nix is the lack of a complete, easy to find, documentation of its "standard library". Nix Pills & a few wiki pages are far from enough. How hard have you tried? It's literally two clicks and one scroll away from the official home page: https://nixos.org/ -> click "Learn" -> Scroll down -> click "Full Nix Manual": https://nixos.org/manual/nix/stable/expressions/builtins.htm...
Nix is wonderful, but absolutely is under-documented. (In part due to a small community, etc.).
A couple of examples I've run into:
https://github.com/NixOS/nix/issues/2259 showed people trying to make use of the "hello world" package which was given in the NixPkgs manual, but couldn't quite figure out how to get it to build.
e.g. if you want a package that's a simple script, "writeScriptBin" seems like what you'd want. -- But it's really not clear how to use it from the manual; you'd have to read the nixpkgs source. https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri...
Re: The Curse of NixOS
#36Earlier quoted context omitted.
There is also a nix store query to find this information. I’m on my phone so I can’t get it right now, but I’ll try to remember to grab it later. You can query all the dependencies of any derivation… this is how I verify the full suite of software that nix-direnv installs for local projects, by querying the store for its cached derivation’s deps.
i think “statically” means without executing the nix language stuff
Oh, I see, thank you for the clarification. I figure it’s just as hard to get a list of transitive packages dependencies without apt or whatever as it is without nix, though. And there’s an argument to be made that a pure function on a derivation can be considered static. But I don’t disagree with any of the general points: especially that nix the language, or more specifically nix in practice as it’s used in nixpgs, is very hard to learn.
Re: The Curse of NixOS
#37NixOS and Guix are nice! Guix folks are doing some wonderful work off late.
I have used NixOS for a while. But for casual desktop GNU/Linux users, it seem like solving a problem that doesn't exist. Have been using Debian on all my computers since 1998. Unless you are using Debian unstable and updating it daily, I hardly hit any breakage.
Servers and deployments is another story.
Re: The Curse of NixOS
#38> But at the same time, I can patch the Python interpreter and then have some software running on my system actually use the patched version, since all of this stuff is configured through the same configuration system. If I want to do that, then I have to rebuild the entire system so as to use my patched version. This is because the NixOS "dependencies" are basically expressed as hashes of binaries. That is for me th…
This can be avoided my not overriding the package attribute, but instead creating a new one and then only using that as-needed.
What you describe as a deal-killer is just purity and safety. Updating a build input gives no guarantee that the build output will be the same or even work. Sure, as smart humans we can say “I know this change does not impact X, so it’s fine”, but NixOS is based partly on the claim that we do not do that reliably or consistently, and tries to save us from ourselves. Yes, it means more rebuilding, but it also means less debugging, confusion, etc., when things do go awry.
Re: The Curse of NixOS
#39I always found Guix more appealing, because it uses a programming language that is useful for other things as well (GNU Guile). I really can't stand having to learn a new language for each thing I want to manage.
I completely agree, but the main benefit nix has over guix is some amount of MacOS compatibility. I don’t currently use a Mac, but I know that next time I have to use one for work, my home-manager-mediated config, which contains almost all of my user-specific configuration, will port right over just fine. The guix team doesn’t seem particularly interested in supporting MacOS, and I can’t blame them.
The other benefit is mindshare, so things tend to get updated more quickly in nix than in guix.
I do really wish I could use guile rather than the nix language though. I’ve gotten used to it, but the complicated abstractions in nixpkgs are still often inscrutable.
Re: The Curse of NixOS
#40> but the connection between those two things is essentially undocumented
I often think documentation would be vastly improved if the author was simply answering the question _what problem did you solve, and how?_, but that seems like it would reveal too much of the dirty details of the design process somehow, so they try to describe the all the neatly encapsulated abstractions and metaphors they've come up with to describe the system (and to encode their own eventual understanding of it) instead. Basically - give us the dirty details and we can make the generalisations ourselves, instead of trying to load the generalised structures into our minds in the most efficient way possible.