I'm going to return to #haskell after a very long time. Back then, the #cabal hell was excruciating. But now, thanks to #nix, setting up a project is like two seconds from the time you decide to create it to the point you start coding.
@lxsameer Not really dependent on Nix, I'd say. You can use Nix if you want to, sure, but also cabal(-install) itself is much better than it used to be.
Wrote a post on how to do reasonable pinning for non-flake configs using a simple shell script, npins, and nixos-rebuild. I also talk about how tools like nixos-rebuild and nix-channel are skeletons in our closet that we need to actually replace and deprecate as a community, to bring people up to modern practices.
@whitequark ok, sure, but that could also be done in a far more scrutible way by a CI job that updates the file and then the machine auto pulls its config or so.
Consider: #Guix / #Nix shared hosting where the cost of storing a store item is shared between the users that depend on it.
Maybe with the new Shepherd on Goblins integration a shared guix-daemon could work.
@csepp That is a cool idea. Maybe a step further - users of such a network could volunteer to build new packages. Because the focus is reproducible packages, peers do not even need to trust each other -- N>1 peers build the same package and get the same hash, it's good. It's like a distributed version of Cuirass, and then the nodes can also act as mini substitute servers like your idea.
A distributed ledger where package builds are the PoW? Maybe too ick for some but, possibly useful?
@shtwzrd Yeah, it definitely should not be turned into another cryptocurrency.
Spot-checking builds is a good idea though.
Offloading doesn't make sense in a shared hosting environment, since the provider already owns all the compute resources. But sharing compute costs for builds could work.
I've been trying to figure out how to do that though. Maybe bill users at the end of the month and divide the cost a build among the users who requested it.
@chfkch@passthejoe@solene ethically I would only suggest nonguix in case of an emergency in order to get a working internet connection due to propietary firmware.
For everything else you can modify 'base-firmware' I think to purge down every other crap.
A little #aux update. As some of you might know we decided to drop our nix{,pkgs} forks and move forwards with our own plans. And as of earlier today we managed to build #lix and #nix within our core repo.
instead of talking so much about what flakes are for, maybe we should talk more about what they do, because it's actually very little. flakes DO the following:
manage a single, top-level lockfile
force a specific entry point for a Nix expression
change the CLI syntax you use
turn on "pure eval" mode by default
make you git track your files (for git repo flakes)
those are the actual things that flakes effect to Nix code