Rde: A configuration framework for GNU Guix [video] | Hacker News Reader

Rde: A configuration framework for GNU Guix [video]

youtube.com

49 pointsakkartik23 comments

Guix/GuixSD is great - it has some awesome ideas that still hasn't made it to Nix/NixOS - the only impractical part is number of packages in Guix is really small compared to Nix - and to do anything that is not hardliner FLOSS you have to really grok the entire thing and build everything yourself.

I checked rde almost two years ago - this video was mostly the only documentation back then. IIRC I think now it is even officially part of Guix?

Anyway, I really wish there existed a rewrite of Nix in a saner language, that embraced the new ideas, and still had the pragmatic approach of current nixpkgs.

>Anyway, I really wish there existed a rewrite of Nix in a saner language, that embraced the new ideas, and still had the pragmatic approach of current nixpkgs.

I'd love something like this but in HCL

As a user of Nix for several years who has only recently taken up HCL: why? They're already very similar languages.

Could you share a bit about what new ideas Guix has?

What do you not like about Nixlang? I think it's quite nice and an especially well-suited DSL for the problems it tries to solve.

> the only impractical part is number of packages in Guix is really small compared to Nix

For reference Guix has 21,798 packages while Nix has 80,000+.

I think another issue with Guix is that some packages just seem to go away after a while, and it's a tiny bit inconvenient to get at older versions once they've slipped out:

https://unix.stackexchange.com/questions/698811/in-guix-how-...

That said I'm all for guix over nix (though day to day I use neither) because I think a full programming language is the better tool for this use case (in my mind terraform vs pulumi all over again).

Also there's one more issue which is related to guix's avoidance of binary blobs -- IIRC this means stuff like gfx drivers can be hard to come by/make work and I think this is by design.

Before that just meant that gamers maybe were left out (they weren't really the focus anyway), but now it might leave out a whole bunch of AI enthusiasts as well.

I've given both the package managers a shot with home-manager and Guix home running on Ubunutu. I enjoyed guix a lot, but because it's so focused on building from source installing software took a very long time. Maybe my setup wasn't right, but it would often take several minutes to install a package because it had to compile a bunch of dependencies. I've since moved back to Nix for the day to day, but I may try guix again at some point.

Did you try using “substitution servers”? They supply pre-built artifacts.

Looks like we've found a piece of documentation that needs to be more clearly called out! :)

Guix has more stuff in it now than Nixpkgs did when I started daily driving NixOS. I'd say it's quite usable, especially if you're willing to package whatever extras you need.

Encouragingly, as well, the Guix package collection is growing at an exponential rate (as is Nixpkgs). In a few years there'll be twice as many packages or more, so if you can make it work now, it won't be tough to stick with it.

Nix is a full programming language, just a really idiosyncratic one with syntax only a mother could love.

I've been using lisp for over 20 years now and would much prefer if guile replaced the nix language (or Common Lisp, if I can dream), but I still use NixOS for practical reasons.

I don't mind the nix language, and I far prefer it to lisp.

But something I haven't understood is that nix compiles to derivations. I don't think it would be difficult to have a nix compiler that takes Lisp or whatever and spits out derivations. It would be able to use stuff from nixpkgs as well, at least partially anyway.

The built derivations are an extremely simple format anything can produce.

If I understand correctly, Guix can do this. Of course the derivation is the final output, so you lose all of the nix modules and nix packages, which kind of defeats the purpose of using NixOS.

I don't think you nessairly need to give up interop. Kinda like his JavaScript can call wasm modules. The compiler would need to know how to use nixpkgs, but the user could write their derivations any way they see fit.

You can depend on other derivations rather easily, but interoperating with functions written in the nix language is more challenging. (And without nix language interop, basically all of NixOS that isn't nixpkgs is useless).

> But something I haven't understood is that nix compiles to derivations. I don't think it would be difficult to have a nix compiler that takes Lisp or whatever and spits out derivations

This is originally how Guix worked— it generated .drv files in the same format as Nix and then asked a Nix daemon to build them. But both projects consider the derivation format an implementation detail that should be free for them to change according to the needs of the rest of the stack, rather than a stable interface for downstream consumers (be they end users or other software tools).

The above is not just theoretical— as a result, the derivation formats of the two projects have diverged.

(Tbh I agree with their position, though. I don't think the concept of the derivation should really be visible to end users. The way the term is used is extremely overloaded/ambiguous, and so at the end of the day it's jargon that serves more to obscure than to teach.)

what are these practical reasons -- ecosystem size? tooling/documentation?

ecosystem size and less friction for non-free software.

> build everything yourself

That’s not true; Guix allows you to easily fetch pre-built artifacts from “substitution servers”. This becomes even more foolproof now that the packaging system has mapped the whole derivation and the hashes of each component involved.

> to do anything that is not hardliner FLOSS you have to really grok the entire thing and build everything yourself

There’s now a “nonguix” repository/channel for derivations of non-free software (along with its own substitution server for pre-built artifacts).

https://guix.gnu.org/en/blog/2022/keeping-ones-home-tidy/

Guix home was developed as an outgrowth of RDE and is perhaps a better start.

Are there pre-configured Guix systems akin to a “batteries included” distribution, for newcomers to start with? I know the installer is already quite user-friendly, but it would be nice to start with a whole bunch of useful packages and configuration for a daily driver system, with zero fuss.

RDE seems to be pretty much that, but I guess I’m wondering whether there are differently opinionated alternatives :-)

What I would highly recommend is -

apt install guix

Yes... this is a debian main package that allows you to use guix on top of debian (you can also do this with other distros as well but ymmv).

Get used to how it works, why its cool and then you can explore the system install.

I daily drive bith RDE/GNUguix (personal) and NixOS (with home manager) (work). Both work really well for my needs.

Pros for guix: - guile scheme - better documentation - free software first - strictness means things blow up early - great emacs mode!

Cons for guix: - goofy stack traces (guile debugger is nice but im not very proficient)

Pros for nix: - more packages & services - flakes, which makes it easy to lock in versions, though guix has channels. Flakes just feels easier to me imo. - laziness - sometimes better error messages

Cons for nix: - laziness (infinite recursion) - no debugger afaik, have to use repl which is useful but also sometimes clunky

Good resource on guix is system crafters (David Wilson)

https://systemcrafters.net/

So rde is intended to be a more user friendly variant of Guix System as a Linux distribution? It's quite hard to tell for me... http://trop.in/rde/manual#Introduction is the clearest project description I can find.

Reply on news.ycombinator.com