> The worst is, of course, GCL/borgcfg, the (turing complete) configuration language for Google's internal job scheduling software.
“Noone has borgmon readability.”
— Broccoli Man (https://www.youtube.com/watch?v=3t6L-FlfeaI)
The Curse of NixOS
91–100 of 361 posts
Re: The Curse of NixOS
#92I wish someone wrote a GUI for Nix that - System and home manager support - Multi-machine and multi-user support by following the practice of splitting the config up by roles / intent - Provided an "about:config" like experience for well defined fields - Integrated with git hosting for easy backup/restore - Included built-in search of other Nix config repos so you can see how other people did things (I was originally…
There isn't a GUI (although nix-gui [1] is in progress) but there is a very good and decently mature flake template called Devos [2] for accomplishing most of what you ask. It basically lets you write very simple profiles to group configuration settings together and then you can assign those profiles to machines or users.
Things could still be improved but I found Devos to be good enough that NixOS is usable for personal and even some production use.
Once I get around to it, I'll move/mirror my configs to Github which should serve as good examples.
[1] https://github.com/nix-gui/nix-gui [2] https://github.com/divnix/devos
Re: The Curse of NixOS
#93Ranting about Nix being hard is like going to Russia and complaining that the local language doesn't sound English. Like many other things worth your time, it's something you learn through deliberate practice and focus.
Re: The Curse of NixOS
#94I think the author is quite wrong that the nix language is not very good and hard to learn. In fact it's not only the best external DSL I've seen, but also one of the few cases where inventing a new language rather than just repurposing a subset of something already established looks like a good decision to me. In fact, I consider it a marvel of language design. The mix of properties that nix has (laziness, purity, r…
I wish nix would implement the stdlib next to the language, even if it's written in nix and not C++. I hate that so many of the basic building blocks are hidden behind lib in nixpkgs. I feel like that accounts for a good bit of the barrier to learning the language. It's difficult to know the difference between a core language feature for the language's sake and a core language feature for the sake of nixpkgs.
Re: The Curse of NixOS
#95Interesting to see exponential growth in NixOS github stars https://star-history.com/#NixOS/nixpkgs&Date . Perhaps the user base is reaching a tipping point where there will be the resources to address some of these problems.
Re: The Curse of NixOS
#96Earlier quoted context omitted.
It's been a while since I used NixOS, but I never really had an issue with the language. What was frustrating was in package solutions there were all these special functions which as far as I can tell were undocumented and I couldn't figure out what they could do. So there was sort of this gap in terms of documentation between theoretical understanding and tooling/functional understanding which I struggled to cross.
The best way I’ve found around this is to always keep a local clone of nixpkgs so that I can grep for where functions are defined and hope like hell that there are some comments in the vicinity. Definitely not ideal.
If you're using Nix on your system, you can also find nixpkgs symlinked under ~/.nix-defexpr/channels/nixpkgs/pkgs/ or so.
Re: The Curse of NixOS
#97Earlier quoted context omitted.
> 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 Could do the same without flakes after the fact by running nix-diff on different generations in /nix/var/nix/profiles…
There's nothing there that needs flakes (an experimental feature which people should not enable without understanding the implications). You could build a system derivation and run a diff against /run/current-system on it. For what it's worth, nix-diff has very verbose output (it literally diffs everything that is different in the inputs & outputs). A slightly nicer way to diff systems is nvd[0] (example output[1]) w…
Flakes are "experimental" in the sense that gmail was in "beta" for however many years. I feel like it's important to mention that you're attempting to rewrite nix[1] and explicitly ignoring flakes[2]. Many people using nix are coming to the conclusion that flakes make things much easier to use and understand, and they obviate the need for a lot of secondary tooling that has become standard. There's an easy way to gauge support for flakes: look at how many high-profile nix repos have an up-to-date flakes.nix file.
[1] https://tvl.fyi/blog/rewriting-nix
[2] https://lobste.rs/s/ypwgwp/tvix_we_are_rewriting_nix#c_zvtze...
Re: The Curse of NixOS
#98I certainly echo that it's a bit of a curse because as soon as you go off the happy path you start needing to learn the internals & the language neither of which are particularly easy. That being said, the rollback capacity, the ability to include a deterministic set of software needed for any particular software project (the inclusion of shell.nix or build.nix in a repo) is one of the few new pieces of technology that I'm unambiguously excited about becoming wide spread. It doesn't feel like it carries a dual use problem like AI or cryptocurrencies.
This could mean the first time you want to use something that isn't inside nixpkgs, which to be fair has now overtaken AUR to be the biggest single repo of packages: https://repology.org/repositories/statistics/total
Re: The Curse of NixOS
#99Earlier quoted context omitted.
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 wa…
> you'd have to read the nixpkgs source. https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri ... Is it too much to ask from developers in 2022? At source, the function is well documented and is provided with an example [1]. The only missing part is a rendered HTML with the same information. [1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...
In 2022, I think it's a reasonable expectation that API documentation can be accessed as rendered HTML. -- e.g. Haskell's or Rust's documentation even links to the source for the packages.
On the other hand, I think it's fair to say NixOS will sometimes require a high level of involvement from its users. When something goes wrong on another OS, it's easy to search for the answer. With NixOS, you have to understand both the Linux part, and the NixOS part.
Re: The Curse of NixOS
#100"""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…
We already had JSON plus functions. We called it 'JavaScript' :)
Ha, nice!
Seriously though, javascript is not a great language if you are looking for robust determinism. I can understand their decision to go elsewhere, given the domain and design.