What sells me with guix is a few things, in rough order of importance:
I have something of a crush on lispy languages, and I find the scheme I write to configure the system and define packages to be very pleasing to my eye.
The UX is, in my opinion, a lot less jarring than with nix. I rather like saying guix install some-bullshit over nix-env -i some-bullshit, and knowing that guix package -m manifest.scm and guix environment -m manifest.scm intuitively do something similar. Channels are stored in a channels.scm file that can be checked into version control and I’m not sure if that’s something that can be done in nix because
guix install some-bullshit
nix-env -i some-bullshit
guix package -m manifest.scm
guix environment -m manifest.scm
The documentation for nix is just not as good as the documentation for guix. I won’t harp on it because Nix is a wonderful tool, but so much discovery is tied into scouring other people’s source code to see how they did it, for some shifting definition of what it is. I feel like guix (and by extension, guile’s) documentation really help with figuring out solutions to problems on one’s own without necessarily using someone else’s example and trying to work backwards to figure out which parts aren’t needed.
Packaging has yet to require an embedded shell script. The edsl for guix packages is really good and the build systems are really robust and intuitive to use. The tooling for emacs is also really good (I may be dumb, but I can never get nix to commit to autocompleting).
Besides that everything else I love about guix I also love about nix. I’m looking forward to the tooling around it to get more robust (I want a home-manager and lorri equivalent, and I have a few stalled projects playing around with making them myself).
Can’t speak for Guix, but I highly recommend people here who already run Linux of some flavour to give NixOS a try. Being able to declaratively configure your system, and all the way to configuring your development environments is extremely valuable once you see the benefit of it in action.
Here is my config if you are curious what those declarative configuration looks like. I use this config between Linux and macOS (on Mac, I use just Nix). The ./nix/home directory contains stuff shared between OSes (so I don’t need homebrew at all as I can bring the Linux software to Mac), and ./machine is used by Linux machines running NixOS.
I have tried, but I had a heck of a time. It seems like a neat concept, but I was not smart enough to get it working in a weekend. There’s a lot to wrap one’s head around, both conceptually and with respect to the UI (which was not intuitive, but perhaps if I had my head better wrapped around the concepts, it would be intuitive?).
No, the UI is not intuitive. There is the new nix command that has a nicer interface, but only supports a subset of the functionality of the nix-* programs, because it is still in development. Also, if you use Nix/NixOS, you should expect to have to learn the Nix language, Nix will be an uphill battle without knowing the language. That said, the language is a relatively simple functional language and has a repl to play around with.
I would recommend people to start with Nix on some other Linux distribution to get a feel for it, before jumping fully into NixOS.
Though, once you have really mastered Nix, there is no way back ;).
Yeah, we used Nix (package manager) for a time at work to manage our dependencies, and I had mostly grokked the language, but there was a bombardment of other warts–rarely were the packages we needed in nixpkgs and if they were they tended to make assumptions that weren’t valid for our systems. If I needed to write a new package, I needed to understand not only the Nix language but also a whole bunch of Nix conventions and somehow I always ended up having to package some super-low-level C dependency, which meant learning that project’s particular project’s build system and how to call that from Nix in a maintainable fashion. Further, the language is dynamically typed so you have to hop around the file tree to find all of the usages of a given thing to understand what type a given parameter must be, and hopping around the file tree is hard since Nix files rarely use imports (as in Python or other languages) but rather expect some caller to compose everything together (maybe this is reasonable, but it makes it hard to find things). Further nixpkgs itself is not intuitively organized, hard to search, and virtually undocumented. Those are the big issues that jump to mind. There was also a long trail of papercuts, like the unreadable derivation formatting (as opposed to pretty-printed JSON).
Nix is cool conceptually–I really wanted to like it, but I’ve had nothing but problems in practice.
I was quite interested in Guix, but the FLOSS-only attitude put me off. Even though I largely agree with the ideals, I want microcode updates for Intel CPU vulnerabilities, need Skype because my colleagues use it, and I need CUDA because otherwise there is not a lot of machine learning I could do. Of course, one could write derivations for all that software, but there does not seem to be a large, consistently updated repository of non-FLOSS software. So that would put me in a niche of what is already a small niche. And you are not supposed to talk at all about non-FLOSS software on Guix mailing lists, so you are largely on your own, until a larger community for a non-free package set evolves.
I like the pragmatism of Nix, where you can set the allowUnfree attribute, to get access to a wide variety of non-free software that people sometimes just need. I have also come to like Nix as a small, lazy functional language and do not really know what practical benefits I would reap from Scheme.
Put differently, Guix is what attracted me first. I would probably be a Guix user now if the stance on non-free software wasn’t so strict and if submissions of patches was easier (nixpkgs really has a nice GitHub-driven workflow). Of course, it’s perfectly valid to say that I am not in the intended audience of Guix.
And you are not supposed to talk at all about non-FLOSS software on Guix mailing lists,
And you are not supposed to talk at all about non-FLOSS software on Guix mailing lists,
Really? Not even to discuss how to replace it? That’s a bit unusual.
Usually the GNU attitude is it not recommend to others to use non-free software, not to avoid discussing it entirely.
(rekado is a Guix developer)
Yeah, that sounds like what I said: don’t recommend or encourage the use of proprietary software.
Using GNU infrastructure to tell people how to install and distribute non-free software works against GNU’s stated goal. It would be like Greta telling you how to install a new coal power plant.
And like he said, you can discuss it elsewhere. Just don’t use GNU’s resources to do so.
That comment by rekado doesn’t quite give the full story. While people are discouraged from discussing how to use non-free software in guix, there are no restrictions on speaking about non-free software if it is relevant to the discussion or someone is seeking ways to replace it. Here is a chain where the packaging of icecat is discussed and Andy Wingo (lead maintainer for GNU/Guile) makes a suggestion that involves hurdles he has had to jump building firefox..
When it comes to linux development and usage I would say that the vast majority of software a person cares about is free software and has found its way into guix or discussions regarding guix. However some of the software that a user might care about the most is not available as free software by default. This includes the two browsers people who use generally want: chrome and firefox and hardware drivers for graphics, telecom, or whatever. But if someone is trying to build ungoogled chromium, its alright to talk about chrome with respect to that. If someone is trying to get around an issue regarding some proprietary thing they need the discussion isn’t dropped as off topic, but instead steered in the direction of alternatives.
At least that’s what I’ve seen having lurked on the mailing list for the past six months.
What I never really see quite answered is: Why guix if there is nix? Why not just a free-software-only channel?
Guix didn’t have to invent a whole new DSL and associated tooling for configuring the system; it’s just regular Guile.
For one, Nix puts a lot less focus on reproducibility and bootstrapping. Decent reproducibility seems to come rather as a sideeffect, while I’m not aware of attempts at bootstrapping at all.
Another big thing is that it’s written in Scheme, and as such a lot more open to hacking (if you ask me). There is another article by the author, where he goes into the benefits of Guix and the fact that it uses Guile.
Hm, the linked article is long and seems to mostly compare Guix to non-Nix systems; I see only a short fragment comparing explicitly to Nix, and in my understanding it’s just a vague complaint about Nix using a custom language. The thing is, I actually like the Nix language, and I was sincerely hoping the article would tell me about some other benefits of Guix over Nix, or at least some concrete advantages Guile has over Nix language. Not seeing any, I am still not convinced why learn the huge (?) language that I expect R5RS (or is it some other dialect?) to be, instead of just the small Nix DSL?
One thing I’d be curious about: what’s the cross-compiling story in Guix? How hard would it be to replace its kernel with L4Linux? I tried doing this in NixOS and failed miserably, between lazy evaluation and tangled mess of nixpkgs internal architecture. I think maybe Guile could help in the debugging aspect because not lazy (would it?), but internal design of the distro as a whole is tangential to language, so I can only ask for an opinion here.
To replace guix’s kernel you only have to inherit the kernel package and replace the download source with your own, plus a second package to do the same for kernel modules.
Here’s an article on the process of building a custom kernal
Thanks! However, as part of this I’m specifically interested in cross-compilation, and even more specifically, in creating my own new architecture “L4” (it’s kinda virtual/proxy architecture). That’s where I got overwhelmed by Nix internals; do you know if Guix allows easy cross-compilation of the kernel (e.g. building one for Raspberry Pi), and what should I do to add & describe a new cross-compilation architecture?
why learn the huge (?) language
why learn the huge (?) language
It’s actually all a declarative eDSL designed to look like key/value configuration. The most you’d have to learn is probably cons, list, and append.
I would say cons* or list and append. You use them for what often amounts to practically the same purpose.
True, but the linked example contains a mishmash, so it would definitely help when reading the manual and other examples. Maybe there’s room for improvement in consistency there, for the sake of Guile newcomers. Saying that, I still think it’s easier to grok than Nix.
I totally agree there. I know one of the arguments against guile in favor of nix is you don’t need a full language but if you’re living in configuration files then its really nice to have easily accessible docs, examples, and a constant test environment a la the repl.
Not so far below there’s also remove, lambda, eq?… also, what do all those %foo-bar things mean? I’m not asking you here and now to explain, but to know where do I find a complete reference of what’s available (I’m asking for a fishing rod, not a fish)… from my experience with Nix, I’m pretty sure I will quickly need to build my own packages and helper functions (stuff like LuaRocks or Nimble packages, or Love2d, esp. given that I understand Guix packages list to be much smaller than even Nix), won’t I need to know full Scheme for that?
Yeah, it would definitely benefit from a “Just enough Guile to understand all of this” section up-front in the same way the Nix manual has a primer on the expression language (this page includes something of an intro that links to the Guile manual a few times).
Both DSLs are made for the same tasks, and they both provide enough library functions for most cases. You don’t need to know all of Scheme to write a Guix package in the same way you don’t need to know all of bash and coreutils to write a Nix package, even though it needs to shell out to do any patching or funky build steps.
I’ve used NixOS on my main computer for a good few years now, and I maintain a couple of very low-maintenance packages, but I’ve never managed to actually contribute (or even test) a new package! The nixpkgs tree has quite a bit of abstraction-building to do what it can with the limited expression language. Every package is a function returning a function, for instance, and the magic of with means that you almost have to just know which functions are available and when. I understand the Nix expression language in theory, but not what anyone is doing with it, and every time I’ve tried I’ve just given up and stuck to a simple shell.nix.
As used, the Nix language just as complex as a full-blown language such as Guile. However, with Guix, all the complexity is packaged up in normal language libraries, and there’s nothing extra a package author can do that isn’t just normal programming. There’s no surprises and you can refer to the manual(s) when you don’t understand something.
As for Lua packages, it doesn’t seem there’s an importer yet, so you will need to know enough Guile to write one, but there are a few Lua packages you can copy from already (source for LOVE, for instance).
Anyway. I recommend reading the Guix manual to see what you can do with it, even if you’re not planning on installing it. It’s rather well-written.
Early on Nix had a disastrously bad approach towards licensing; if you installed firefox it would actually pull in the Adobe flash plugin as well without even asking the user. (which was probably illegal due to it skipping the step where the user agrees to the license).
It’s been fixed since then, but I can understand why Gnu people would be hesitant to recommend people trust Nix.
I understand that reproducibility is one of the core features of GNU-Guix. How good is it with respect to Maven?
(I investigated Nix sometime back for producing reproducible artifacts for Java (maven) for our research but found that the Maven builds did not result in the same checksums)
I certainly wouldn’t expect Maven builds to result in the same checksums. Either between multiple Maven builds or when comparing to nix builds. Maven makes no attempt to guarantee reproducible builds at all.
Why do you say that? Maven seems to have a page on producing reproducible builds now.
Interesting, that must be new. Historically it wasn’t a thing.
I imagine a lot of work goes into ensuring interpackage compatibility, in a system like this. Does the lack ofpackage maintainers for guix (or nix) result in much breakage?
I knew a guy running nix, and he always seemed to be struggling with one misconfiguration or another, and that’s scared me off niche packaging systems a bit, even though I like the core principle behind nix/guix.
My experience with using Nix for 1.5 years: stable versions rarely break, if ever. Of course, there may be some packages that were broken at the point of the freeze. But fixing them and submitting a patch, practically means that they work for the rest of that stable cycle.
Things do break every now and then unstable (or very frequently if you are on macOS). A lot of things are tested before a channel is pushed, so they are not very often system-breaking changes. But it happens sometimes that I cannot rebuild the system because some package that I use is broken. Since updates are atomic, this has no effect on the running system, it just means that you cannot move forward until the package is fixed or you remove the package from your configuration.
The nice thing is that you can’t really break your system, because you can always go back to a previous generation of your system, as long as you don’t garbage collect them.