16 ms·

Hi there, I'm the person who made the release announcement and I happen to be one of the two co-maintainers of GNU Guix. I'm using Guix in production at a bio

by rekado 10y ago

Hi there, I'm the person who made the release announcement and I happen to be one of the two co-maintainers of GNU Guix. I'm using Guix in production at a bioinformatics institute. If you have specific questions about Guix or functional package management feel free to ask me. To try to answer one common question: we aren't on bad terms with the Nix people or compete with them. We are working towards very similar goals, and the underlying paradigm of functional package management (pioneered by Nix) is the same. Members of both projects are involved in efforts towards reproducibility. We have different sensibilities when it comes to the actual implementation and that leads to different design choices.

Klasiaster 10y ago
Concerning the HURD support: Is there an image with GNU Hurd instead of the Linux kernel?
- rekado 10y ago
  There is not (yet). In functional package management we build everything from source until we hit a small set of common bootstrap binaries. In the case of the Hurd it is now possible to bootstrap all of the Hurd system in this manner. This means that we can use Guix as a package manager on top of a Hurd system (e.g. Debian GNU/Hurd), but GuixSD using the Hurd is not yet available. I think it's close, though.
agumonkey 10y ago
What about the reproducible build project. Is there some regular communication channel with them ? or just friendly acknowledgement ?
- davexunit 10y ago
  Guix developers attend the Reproducible Build Summits, among other collaborative efforts.
- rekado 10y ago
  Both Guix maintainers attended this years reproducible builds summit in Berlin. We're involved with them since before the summit in Athens. At the most recent summit we start a new cross-distro project that I hope we can announce soon.
0xcde4c3db 10y ago
Is something more elegant than grafts [1] on the agenda for any functional package manager? Right now, it seems like the options are: 1) Forego timely and efficient security update deployment because the functional discipline demands that we rebuild the entire system if glibc is updated 2) Forego strictly functional package management and undermine the associated guarantees by deploying hacks that work around the functional model. edited to add: does this perhaps tie into the work on reproducible builds, e.g. could that work yield tools able to prove that a given package need not actually be recompiled? [1] https://www.gnu.org/software/guix/manual/html_node/Security-Updates.html https://www.gnu.org/software/guix/manual/html_node/Security-...
- rekado 10y ago
  Grafts are still functional. We're not modifying existing builds. We generate new artifacts with updated references (think copy-on-write). However, these new artifacts don't need recompilation. They are copies with their embedded references recursively replaced such that they refer to the fixed variant of a library. This mostly just works, but it can lead to problems when upstream introduces ABI changes in security fixes. This is very rare but it happened at least once (I think it was openssl) --- like any other distro that updated the library in place users experienced problems. The assumption with grafts is that this doesn't happen, which is valid in the vast majority of cases that we encountered so far. That said, in Guix we try to minimize the period during which grafts are needed by "ungrafting" as soon as a properly rebuilt artifact is available on the build farm. This doesn't help those users who build everything from source exclusively, of course. But this is where reproducible builds help. Users don't have to be building everything from source if they have the tools to gauge how much they can trust providers of binary substitutes.

by rekado 10y ago

Klasiaster 10y ago

Concerning the HURD support: Is there an image with GNU Hurd instead of the Linux kernel?

rekado 10y ago
There is not (yet). In functional package management we build everything from source until we hit a small set of common bootstrap binaries. In the case of the Hurd it is now possible to bootstrap all of the Hurd system in this manner. This means that we can use Guix as a package manager on top of a Hurd system (e.g. Debian GNU/Hurd), but GuixSD using the Hurd is not yet available. I think it's close, though.

agumonkey 10y ago

What about the reproducible build project. Is there some regular communication channel with them ? or just friendly acknowledgement ?

davexunit 10y ago
Guix developers attend the Reproducible Build Summits, among other collaborative efforts.
rekado 10y ago
Both Guix maintainers attended this years reproducible builds summit in Berlin. We're involved with them since before the summit in Athens. At the most recent summit we start a new cross-distro project that I hope we can announce soon.

0xcde4c3db 10y ago

Is something more elegant than grafts [1] on the agenda for any functional package manager? Right now, it seems like the options are: 1) Forego timely and efficient security update deployment because the functional discipline demands that we rebuild the entire system if glibc is updated 2) Forego strictly functional package management and undermine the associated guarantees by deploying hacks that work around the functional model. edited to add: does this perhaps tie into the work on reproducible builds, e.g. could that work yield tools able to prove that a given package need not actually be recompiled? [1] https://www.gnu.org/software/guix/manual/html_node/Security-Updates.html https://www.gnu.org/software/guix/manual/html_node/Security-...

rekado 10y ago
Grafts are still functional. We're not modifying existing builds. We generate new artifacts with updated references (think copy-on-write). However, these new artifacts don't need recompilation. They are copies with their embedded references recursively replaced such that they refer to the fixed variant of a library. This mostly just works, but it can lead to problems when upstream introduces ABI changes in security fixes. This is very rare but it happened at least once (I think it was openssl) --- like any other distro that updated the library in place users experienced problems. The assumption with grafts is that this doesn't happen, which is valid in the vast majority of cases that we encountered so far. That said, in Guix we try to minimize the period during which grafts are needed by "ungrafting" as soon as a properly rebuilt artifact is available on the build farm. This doesn't help those users who build everything from source exclusively, of course. But this is where reproducible builds help. Users don't have to be building everything from source if they have the tools to gauge how much they can trust providers of binary substitutes.