Update once per year.
> brew, distrobox, flatpak
You can have that stuff on Nix if you need it.
Nix is bad because the language is very limited and extremely hard to debug and the module system is fragile and obscure (just try to write a recursion-safe mkMerge and prove it won't magically drop some parts of your config because the values in the module system are always magic attrsets, not values), but, unfortunately, there is nothing better around.
In other words, the old adage still rings true. The beauty of Nix is that you can do anything. The ugliness of nix is that you can do anything
Everything is a battle and nix battle is bit less hopeless than the imperative distro battle, but again, nix is bad but noone wants to build a better thingy.
I've seen countless attempts and I'm trying to make my own build system (not targeting linux distros though). The problem is extremely hard. Essentially you have to build a general purpose PL which is better (more introspectable/debuggable/extensible) than other GPPLs.
It turned out to be ansible... which is a pure python tool. Beats me.
There's also some cases where it wants to build Android Studio from source. I've just removed it and now run it in a VM.
I'm sure I'm doing it wrong, and I'm sure nixos-rebuild has a reason to build things from source, and maybe I'm not RTFMing hard enough. But good god, I just need my system to update.
I guess our system's nixpkgs moves forward while the nixpkgs in our project flake.nix stays the same. So eventually the nixpkgs of the project is garbage collected, because it isn't pinned by the system, and it needs to redownload and rebuild?
I don't know.
I try to `nix flake update` my system configuration every 2-3 months.
Arguably, running Arch and not updating frequently is a pain, too.
You should manually create a garbage collection root (that pesky 'result' symlink, --out-link)
You can use hydra to observe the ebb and flow of broken packages getting fixed and pick good git hashes to pin to. Once I figured that out I was very happy and had a good time glancing through hydra to monitor this. Now I can make informed decisions about what hash I build from and still keep unstable train, upgrading more often then I was before.
There are introspection tools for that.
> Build from source
That's not an issue unless you stay on master or use config flags (there is just a handful of them, but they are imortant, eg cudaSupport=true can easily give you 5-6 hours of build time, rocmSupport can easily give you a couple of days)
Nonetheless, in case those assumptions are off - GNU Guix exists, and is written in and extended in (Guile) Scheme. Guile is general purpose, has the excellent Andy Wingo powering a lot of improvements to the language the last years, and some people are very fond of it. Perhaps you'd be interested in investigating, if Nix's DSL wasn't to your liking.
However, after these last few years, I have a few gripes that I'd like to check with a guix user to see if they're represented in guix.
1) I can't easily pin a software I'm using to a specific version, it seems like everything has to be from a specific hash of nixpkgs
2) Relatedly, I can't upgrade firefox without upgrading every single piece of software installed on my computer
3) Dynamic linking doesn't work. I can get around it with steam-run, but that's hacky and I worry it won't be supported forever
I was more a happy Guix user and computing beginner, rather than an expert, I didn't do anything overly fancy. I was starting to dabble with more advanced topics, but had to leave that system unfortunately for unrelated reasons. Looking forward to a glorious return though, I must say, as soon as I can manage it.
Don't hesitate to try the official documentation with your problems, it's excellent. No answer there, try a full description of your issues on the mailing list, they're a great bunch too.
Search the help-guix archive here before emailing them -- https://lists.gnu.org/archive/html/help-guix/
Details on joining the help-guix mailing list, and/or where to send questions, here -- https://lists.gnu.org/mailman/listinfo/help-guix
Yes, the Scheme programming language doesn't solve any those problems I mention.
> improvements to the language
Despite of the language, if we speak about Linux distros, I need all those pesky blobs to get my desktop running. And, by the way, is there anything alike to flakes, so I can have an actually reproducible build, not a mess of channels?
You can even do this multiple times (don’t do it too many times though as it will increase evals times) and doing this you can run all kinds of different software at different versions.
> Nix is bad because the language is very limited and extremely hard to debug and the module system is fragile and obscure
-- Limited :: here's a collection of Guile software https://sph.mn/foreign/guile-software.html. It's not Python, but it is a general purpose language used by lots of people for serious software work, with a nice library of lovely Scheme books for learning, too
-- Hard to debug :: Guile has built-in debugging support, and there are interfaces like Geiser in Emacs with extra tools, and also support for interacting with GDB
-- Module system :: Guile's module system was first implemented in 1996, I learned from browsing there. Anyway https://www.gnu.org/software/guile/manual/html_node/Modules....
So yes, if you don't like Lisps, or don't have time to learn new things, or don't like something else about Guix, by all means, steer clear. But the statement: "there's no Nix but with a general purpose, powerful programming language" is, I think, demonstrably false.
I don't like impure languages with weak type systems. Ironically, I mostly use Scala, which is an impure language but it has a very powerful type system, unlike any other.
You wrote a comment implying what's wrong with Nix is the language, and stating that there's unfortunately "nothing better" out there.
It is true in this universe that there is a software project called GNU Guix, which is 13 years old, whose literal origin idea is - what if we take the general idea behind Nix, but write it all afresh in a fully featured programming language, and make it extensible and configurable with that language.
There are a host of reasons you might not want to get into that personally, as I stated - but it really does exist, regardless of your personal feelings?
1) Nix language is ugly but it's pure. Scheme is not. To my taste it's even harder to reason about/debug/introspect because of lack of purity.
2) Guix itself lacks any nonfree software/blobs, which is essential to run a real desktop. That is a showstopper for newcomers and in my opinion that's what prevent the community growth, so there are much less packages, docs, etc.
2.1) There were channels to add nonfree blobs, but channels make system less reproducible and they were unofficial. Maybe I'm not up to date with the Guix developments, but as far as I'm aware there is no replacement for Flakes and a system with multiple channels is not reproducible and easy to break.
> You can have that stuff on Nix if you need it.
In fact, I'd openly recommend such a solution: NixOS base, most applications via flatpak, and dev work in distrobox. Gives you 80% of the benefits for 20% of the work.
(Although I will also happily agree that Fedora's Silverblue or OpenSUSE MicroOS as the base is also pretty good; I think that's just a trade if you need to actually tweak the base layer)