Guix is a functional package manager, Flatpak is not. Flatpak is based on the idea of runtimes (a collection of libraries and toolchains). There is no dependency bundling with Guix and there are no "runtimes" against which binaries are deployed.
Guix provides the tools for bit-reproducible builds, which is why it's used in some HPC environments (including the institute where I work).
I read up a little on Guix, but I can't reconcile what I read with what you wrote.
Guix clearly does track and even bundle dependencies.
The part I'm missing is how different packages can rely on different dependencies without stepping on each others' toes. And if a certain package relies on a dependency with known vulnerabilities, do I have to wait for the package to change its dependency, or can I upgrade the dependency as soon as it issues a fix?
> Guix clearly does track and even bundle dependencies.
No, it really does not. What part of the documentation made you come to this conclusion?
Each package is installed into its very own prefix. The prefix is derived from the hash of all of the package's inputs. Inputs mean: the package description itself (including configure flags and the like), the package sources, and all packages it depends on, recursively. This means that every package closes over the complete directed acyclic graph of its dependencies.
Change any of the inputs and the output prefix will change, i.e. the package will end up in a different, separate directory.
Packages keep references to other packages. Instead of bundling all dependencies under the package's prefix, packages can reference other packages directly. We use the RUNPATH feature to embed absolute file names of e.g. libraries.
A big part of Guix itself is a collection of package definitions. These definitions are just Scheme values. Taken together, these Scheme values describe a lazy graph of dependencies. Guix instantiates parts of this lazy graph when installing packages.
As I wrote above, any change to a node in the graph affects all other nodes upstream of it. If there's a security fix that needs to be applied to, say, the glibc it will cause a rebuild of all packages that depend on it. (There is an optimisation called grafts, which allows us to deliver security fixes without actually rebuilding the world.) Packages that have been installed already, however, will remain untouched. To benefit from a security fix these packages have to be upgraded.
Guix makes it trivial to find the users of any given package in the store, so it's easy for example to figure out if you have software that uses a vulnerable library.
What is the current position of guix Vs mix? Is one clearly more popular? Is one "winning" or is this more of a Debian Vs redhat, where both can continue to exist?
Disclaimer: I have been working on Guix since 2014 and use it in production.
Guix and Nix are both implementations of the functional package management idea. Nix has been around for quite a few more years than Guix.
In Guix package expressions are first-class and the DSL is embedded in Guile, a general purpose language, so packaging has a very different feel to it. It also allows for fun tools like "guix graph".
Guix is used in scientific environments (e.g. where I work); I don't know if there are deployments of Nix in HPC environments. I do think that there are more bioinformatics tools packaged for Guix.
Another difference is in how the two projects approach certain problems, such as bootstrapping from binaries. (Guix just got a new Java bootstrap from C.)
There is no rivalry between these projects and members of both projects cooperate in the reproducible builds efforts.
It's all possible to do, but the Guix developers do not provide assistance. From a purely technical perspective, software provided in binary form only impedes one of the main goals of Guix, 100% reproducible builds, because there is no source code.
But would they provide resistance? As nice as the idea of a fully-free distro is, I have the impression that free distros have a minuscule userbase compared to their non-free counterparts. For an already niche distro, this sounds like a significant handicap.
If someone came along and offered a hardware-compatibility repo or redistribution, would the Guix community work with them, or would the relationship be more distant, or even adversarial?
I'm personally very interested in the project, and have no desire to poison the pure core of Guix, but I need my hardware to work.
We don't want to have discussions about non-free software on the project channels, because they really are off-topic. We won't do anything to sabotage third-party repositories (no matter what they might contain); in fact, we're working on implementing mechanisms to make it easier to load software from third-party channels.
But as a project following the Free System Distribution Guidelines (GNU FSDG) we will not recommend third-party channels providing proprietory software, nor would we want our project's communication channels (mailing list, IRC, etc) to be used to steer users to channels that provide non-free software.
True, however, I've not seen an ounce of animosity towards SystemD in the Guix community. GuixSD merely uses GNU Shepherd because it is being developed specifically to work with Guix and is also written in Guile Scheme.
I've had good fun learning to program with Guix lately. It's easy to start packaging software and get contributions into a real project, But it's also a large system, with complex internals that I'm gradually learning more about, like G-Expressions[1]. I'm also studing SICP on the side, so it's nice that they use essentially the same language.
I have high hopes for Guix. I conjecture that GuixSD can become the distro-makers goto basis for creating new systems. Other distros have simpler sh-like languages for building packages, which creates a system which is very much a house of cards. Every time I look at debian package definitions for help, I come out with one extra grey hair.
I think Guix can build a much taller house of cards than other packaging systems. For example, suppose you want to build a Audio focused distro, and you'd like a PREEMPT_RT patched kernel, I haven't bothered making this myself but it basically just requires `inherit'-ing the linux-libre package definition, and then adding the PREEMPT_RT patch to the list of patches to be applied. Whenever linux-libre is updated, your linux-libre-lts will automatically include those changes too and be updated. Naturally, incompatible updates can happen that break things, but that is unavoidable.
Then, you would create in your git repo all the package definitions and customisations needed, and then finally a file containing the system definition that is the actual distro. Other GuixSD users can try out your distro by running sh $(guix system vm my-super-distro.scm --fallback) to boot up a virtual machine running your system. Or guix system reconfigure my-super-distro.scm will install it on the system in a non destructive way than can be rolled back or reconfigured back to the previous system definition.
What's else? Scientific Guix? Educational Guix? One can share git repos including .scm file that can easily be launched to show of their riced desktop without borking other peoples systems? I admit I haven't looked at how debian based distros are made, but I imagine it's not so simple to convert one dpkg based distro into another one and then back again without any destructive changes.
Congrats on the release. I use GNU Guix ontop of Fedora to use some extra packages as well as commands like `guix environment` to set up a dev environment to work on projects.
It is completely isolated from other package managers. So you can use them in harmony, and if you decide that you don't like Guix there's like 2 directories to delete.
I assume unless you use software which installs it's cache/other stuff into the user home directory, right? Then you would also need to delete these dirs as well?
Software like that exists (e.g. ibus, which creates a database and cache in the home directory), but generally I haven't had any problems with Guix on other distributions.
Ah, good to know. Just tried sbt (build tool for scala) with Nix (have no experience with Guix, but like that everything is in the same language) and it indeed creates .ivy and .sbt caches in the home directory. Everything else goes into the store like it should.
Any experiences with using GuixSD as a main distribution for a standard laptop working environment? I have been using Debian Sid for more than a decade but the idea of having a system fully configured via reproducible pure Scheme functions is tempting for sure...
I have been using GuixSD on my Thinkpad X220 for about 2 years now and it is has been good overall. I have fairly simple needs: GNOME 3, Emacs, Firefox (called IceCat in GuixSD). The full system rollback feature has been very handy at times when I do something terrible to my OS configuration file and just want to move on to other things.
I I may (I hope I'm not coming across as rude, I'm genuinely interested in running GuixSD):
How 'recent' are the packages?
I care for little things, but say.. libvirt or Firefox would be something I'd like to keep quite up to date.
Is it possible to run Firefox (not Iceweasel)?
Do you use any 'unfree' packages and how much hassle is it to acquire those?
Packages are kept very up-to-date in general. The contributors try their best to keep up with the latest stable releases, so freshness resembles a distro like Arch more than Debian. I don't use any nonfree packages and Guix provides none because it conforms to the GNU FSDG, so there is no Firefox package available. Someone could provide a nonfree package collection that users could install separately but I don't know of any. The IceCat project is based on the extended support releases of Firefox and Guix provides updates quickly. I hope that someday Firefox will become FSDG compliant so there's no longer a need for IceCat.
> Someone could provide a nonfree package collection that users could install separately but I don't know of any.
This is the main think holding me back from switching to GuixSD (from NixOS). While I do like the prospect of running a 100% free OS, I'm not 100% sure I can with my current hardware. If I install GuixSD, and find out that I need a non-free driver or kernel, the responsibility of getting that falls on my completely inexperienced lap. I would be much more inclined to run a partially non-free system to get used to GuixSD, then start cutting out the non-free parts.
It's the only place I know of where you can currently get GCC 7.1. [0]
> Is it possible to run Firefox (not Iceweasel)?
If you spun up your own package, and didn't distribute, probably. The IceCat package is 746 lines of Scheme at the moment, so porting it might not be complete hell. [1]
That being said, the current IceCat is based on Firefox 52, so that's a fairly close version-parity, even if you miss out on the nonfree aspects of FF.
> libvirt
Guix currently has libvirt 3.2.0, whereas the very latest is 3.3.0. A fairly close parity, and I'd expect an update to the Guix package soon-ish.
Most of the "core" packages are very recent. Guix typically has zero-day updates for popular software such as git, kernel, ffmpeg etc, and obviously most of the GNU portfolio.
The only "unfree" package I use is the vanilla Linux kernel (for non-free wifi firmware), which is fairly easy to tie into the system configuration.
I tried to use it on top of my Ubuntu install to manage dependencies, and the very first thing I wanted to do didn't work. I wanted to set up Java so I could run Clojure, and the version of Java they build can't make any https requests. There was also a subtext of "you should just build everything in Guix; don't use leiningen or maven". It was pretty disappointing. I hope they can get things to work better; it would be fantastic to have a declaration of all the things I want to install on my computer.
> the version of Java they build can't make any https requests
This is no longer true.
Our approach to Java is a bit ... unusual. Nobody in the Java world appears to be building everything from source, so bootstrapping the environment is a pretty tough job.
Now we bootstrap the JDK itself from Jikes and GNU Classpath, and we have quite a few more Java packages than before, but still not enough to get Maven packaged without resorting to using pre-built binaries.
There's still a long way to go, but we're walking it.
I'm very excited for this. I think that a fantastic use case for GUIX, which would solve a large pain point for companies, is initial computer setup. And, at least for me, that means Java. Having a single config file that installs and sets up a computer that's human-editable? Amazing.
I'm not using Maven, but Clojure, so perhaps that's enough. I'll see if I can try it out.
I just installed GuixSD 0.12 last week on a Dell 13 7000. Went mostly smoothly (had to use Grub BIOS instead of UEFI, that's been fixed in 0.13) after I replaced the Intel WiFi card with an Atheros based one.
My needs are simple: emacs, Clojure (with Icedtea), Icecat and StumpWM. Plus all the guile goodness!
Just realized I'm living in a system with four Lisps front and center (guile, Common Lisp, elisp, and Clojure)
I have been using GuixSD on a variety of systems for a couple of years:
* my x86_64 laptop (X200S with libreboot)
* two i686 laptops (a T60 and a netbook "server")
* an x86_64 audio workstation for music recording
* virtual servers at work
It's really convenient to have the system configuration declared in a Scheme file under version control. Rolling back to older variants in case of upgrade failures has also been very useful.
Im gunna give guixsd a go (i run Ubuntu now). I do almost everything in emacs, and I have all my configs/elsip (and plenty of scripts and other stuff) in a big git repo. Setting up a new box is as simple as installing emacs and checking out my repo. I look forward to rolling package installs and init scripts etc into my repo (its init system is scheme based, no systemd).
Funny thing about guixsd, intel wifi chips wont work out of the box. Even if you provide the firmware, the kernel wont load blobs. Im sure you could install a new kernel... But it just feels dishonest. I bought a $10 usb atheros card.
36 comments
[ 5.0 ms ] story [ 91.4 ms ] threadGuix provides the tools for bit-reproducible builds, which is why it's used in some HPC environments (including the institute where I work).
Guix clearly does track and even bundle dependencies.
The part I'm missing is how different packages can rely on different dependencies without stepping on each others' toes. And if a certain package relies on a dependency with known vulnerabilities, do I have to wait for the package to change its dependency, or can I upgrade the dependency as soon as it issues a fix?
No, it really does not. What part of the documentation made you come to this conclusion?
Each package is installed into its very own prefix. The prefix is derived from the hash of all of the package's inputs. Inputs mean: the package description itself (including configure flags and the like), the package sources, and all packages it depends on, recursively. This means that every package closes over the complete directed acyclic graph of its dependencies.
Change any of the inputs and the output prefix will change, i.e. the package will end up in a different, separate directory.
Packages keep references to other packages. Instead of bundling all dependencies under the package's prefix, packages can reference other packages directly. We use the RUNPATH feature to embed absolute file names of e.g. libraries.
A big part of Guix itself is a collection of package definitions. These definitions are just Scheme values. Taken together, these Scheme values describe a lazy graph of dependencies. Guix instantiates parts of this lazy graph when installing packages.
As I wrote above, any change to a node in the graph affects all other nodes upstream of it. If there's a security fix that needs to be applied to, say, the glibc it will cause a rebuild of all packages that depend on it. (There is an optimisation called grafts, which allows us to deliver security fixes without actually rebuilding the world.) Packages that have been installed already, however, will remain untouched. To benefit from a security fix these packages have to be upgraded.
Guix makes it trivial to find the users of any given package in the store, so it's easy for example to figure out if you have software that uses a vulnerable library.
Guix and Nix are both implementations of the functional package management idea. Nix has been around for quite a few more years than Guix.
In Guix package expressions are first-class and the DSL is embedded in Guile, a general purpose language, so packaging has a very different feel to it. It also allows for fun tools like "guix graph".
Guix is used in scientific environments (e.g. where I work); I don't know if there are deployments of Nix in HPC environments. I do think that there are more bioinformatics tools packaged for Guix.
Another difference is in how the two projects approach certain problems, such as bootstrapping from binaries. (Guix just got a new Java bootstrap from C.)
There is no rivalry between these projects and members of both projects cooperate in the reproducible builds efforts.
If someone came along and offered a hardware-compatibility repo or redistribution, would the Guix community work with them, or would the relationship be more distant, or even adversarial?
I'm personally very interested in the project, and have no desire to poison the pure core of Guix, but I need my hardware to work.
But as a project following the Free System Distribution Guidelines (GNU FSDG) we will not recommend third-party channels providing proprietory software, nor would we want our project's communication channels (mailing list, IRC, etc) to be used to steer users to channels that provide non-free software.
I have high hopes for Guix. I conjecture that GuixSD can become the distro-makers goto basis for creating new systems. Other distros have simpler sh-like languages for building packages, which creates a system which is very much a house of cards. Every time I look at debian package definitions for help, I come out with one extra grey hair. I think Guix can build a much taller house of cards than other packaging systems. For example, suppose you want to build a Audio focused distro, and you'd like a PREEMPT_RT patched kernel, I haven't bothered making this myself but it basically just requires `inherit'-ing the linux-libre package definition, and then adding the PREEMPT_RT patch to the list of patches to be applied. Whenever linux-libre is updated, your linux-libre-lts will automatically include those changes too and be updated. Naturally, incompatible updates can happen that break things, but that is unavoidable. Then, you would create in your git repo all the package definitions and customisations needed, and then finally a file containing the system definition that is the actual distro. Other GuixSD users can try out your distro by running sh $(guix system vm my-super-distro.scm --fallback) to boot up a virtual machine running your system. Or guix system reconfigure my-super-distro.scm will install it on the system in a non destructive way than can be rolled back or reconfigured back to the previous system definition. What's else? Scientific Guix? Educational Guix? One can share git repos including .scm file that can easily be launched to show of their riced desktop without borking other peoples systems? I admit I haven't looked at how debian based distros are made, but I imagine it's not so simple to convert one dpkg based distro into another one and then back again without any destructive changes.
[1] https://www.gnu.org/software/guix/manual/html_node/G_002dExp...
How 'recent' are the packages?
I care for little things, but say.. libvirt or Firefox would be something I'd like to keep quite up to date. Is it possible to run Firefox (not Iceweasel)?
Do you use any 'unfree' packages and how much hassle is it to acquire those?
This is the main think holding me back from switching to GuixSD (from NixOS). While I do like the prospect of running a 100% free OS, I'm not 100% sure I can with my current hardware. If I install GuixSD, and find out that I need a non-free driver or kernel, the responsibility of getting that falls on my completely inexperienced lap. I would be much more inclined to run a partially non-free system to get used to GuixSD, then start cutting out the non-free parts.
It's the only place I know of where you can currently get GCC 7.1. [0]
> Is it possible to run Firefox (not Iceweasel)?
If you spun up your own package, and didn't distribute, probably. The IceCat package is 746 lines of Scheme at the moment, so porting it might not be complete hell. [1]
That being said, the current IceCat is based on Firefox 52, so that's a fairly close version-parity, even if you miss out on the nonfree aspects of FF.
> libvirt
Guix currently has libvirt 3.2.0, whereas the very latest is 3.3.0. A fairly close parity, and I'd expect an update to the Guix package soon-ish.
[0] https://www.gnu.org/software/guix/packages/g.html
[1] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages...
The only "unfree" package I use is the vanilla Linux kernel (for non-free wifi firmware), which is fairly easy to tie into the system configuration.
This is no longer true.
Our approach to Java is a bit ... unusual. Nobody in the Java world appears to be building everything from source, so bootstrapping the environment is a pretty tough job.
Now we bootstrap the JDK itself from Jikes and GNU Classpath, and we have quite a few more Java packages than before, but still not enough to get Maven packaged without resorting to using pre-built binaries.
There's still a long way to go, but we're walking it.
I'm not using Maven, but Clojure, so perhaps that's enough. I'll see if I can try it out.
My needs are simple: emacs, Clojure (with Icedtea), Icecat and StumpWM. Plus all the guile goodness!
Just realized I'm living in a system with four Lisps front and center (guile, Common Lisp, elisp, and Clojure)
I'm just here with two NixOS machines playing with ML languages.
Have you tried NixOS & do you have an opinion regarding it? Or was it just straight to GuixSD?
* my x86_64 laptop (X200S with libreboot) * two i686 laptops (a T60 and a netbook "server") * an x86_64 audio workstation for music recording * virtual servers at work
It's really convenient to have the system configuration declared in a Scheme file under version control. Rolling back to older variants in case of upgrade failures has also been very useful.
Funny thing about guixsd, intel wifi chips wont work out of the box. Even if you provide the firmware, the kernel wont load blobs. Im sure you could install a new kernel... But it just feels dishonest. I bought a $10 usb atheros card.