GNU Guix 1.0 System Distribution & Transactional Package Manager Released

[Michael_S]

Sorry for my ignorance but what problems does Guix solve that isn't yet solved by other package managers?

Guix borrows a lot of ideas from Nix, but Nix has a custom configuration file syntax while Guix uses GNU Guile Scheme for its configuration files.

The relatively uncommon thing that Nix and Guix should give you is atomic transactions. Rolling back to previous versions should always work and be almost instant, since it just involves changing a few symlinks.

The unique thing they give you is bit-for-bit reproducible builds. I don't think they have it working for all packages, but for many software packages if you built libfoo version 3.4.5 for x86_64 on Guix anywhere it should be bit-for-bit identical to everyone else's build of libfoo version 3.4.5 for x86_64. Likewise the same is true for Nix, though I don't know if the same version built on Nix and Guix would be identical. That kind of reliably reproducible thing is huge.

The Debian project, among others, has work ongoing about reproducible builds but as far as I know - and I could be wrong - they haven't made as much progress as the Nix and Guix teams.

Guix and Nix are also good for devops stuff. If you want two Ubuntu Linux VMs with complex configuration to be identical, you need to clone one to the other or do some work with other tools that automate the steps you need with files under /etc/ and the apt and deb tools for you (Chef, Puppet, Ansible, Saltstack, Sparrowdo, etc...) With Guix and Nix, the whole system configuration - packages, users, service settings, etc... - is managed by the configuration file for your package manager. So if you want a copy of a Guix installation you just copy the config.scm file from the source machine to the other Guix machine and then run "guix system reconfigure" and when you're done the two boxes are identical.

[chithanh]

Sorry for my ignorance but what problems does Guix solve that isn't yet solved by other package managers?

To add to the previous poster:

• Installing packages as user inside the home directory, on GuixSD/NixOS leveraging packages that are already installed system-wide
• Managing multiple versions of a package on one system
• Distribution of a package and its dependencies to other systems, in a way that is transparent to the package manager
• Can use binary package repositories, or build from source, or a combination of these

Compared to snap/flatpak, which bundle all dependencies and are mostly opaque from the outside, guix/nix can track the stuff that comes as dependencies with a package.

For example, if some snap/flatpak contains a bundled outdated and vulnerable library, that is a problem. And in many cases you have no way to tell even.
If however some guix/nix package depends on an outdated and vulnerable library, it will be visible to the package manager. The user can track which packages require the vulnerable version, they can patch and recompile the library (if feasible), and once the last dependent package is removed from the system, the vulnerable library can be automatically removed too.

[Bsdisbetter]

I have Guix running in a VM, it's nice.



That's the benefit of free software: if you don't like it, you're free to not use it or to fork it and make something you do like.

We can't win. Everything converges on one solution, like systemd, and you get people screaming that choice is being taken away. Everything diverges into dozens of choices, you get people screaming that there is so much wasteful duplication.

And as it turns out GuixSD uses the GNU Shepherd init system. It seems to work fine, though I haven't done anything mission-critical with it.

Yep, because comparing a package manager to systemd is valid. Not. One does 1 thing the other wants to absorb everything.
I guess it's just a symptom of linux being only a kernel.

[c117152]

Another feature is that you can git disect your whole system and spin VMs of your system deceleration file with one liners. So, combined, you can gradually remove unrelated packages and pin point the problematic package and commit without having any idea what they actually do and how they do it. Eventually you'll be posting a dozen lines deceleration file and a git hash saying "this package got slow in that commit" and there won't be any room for ambiguity.

Alone, this justifies abandoned every other package manager except for Alpine's and maybe Openwrt's that have low-RAM requirements that can't be met by Nix and Guix. But everything between Debian, Arch and RPM has really outlived its usefulness.

[Guest]

Alone, this justifies abandoned every other package manager except for Alpine's and maybe Openwrt's that have low-RAM requirements that can't be met by Nix and Guix. But everything between Debian, Arch and RPM has really outlived its usefulness.

Debian, and especially Debian based distributions like Ubuntu, suit nicely for simple desktop end-users. DEB packages are simple, and with fixed distribution releases, it makes perfectly stable system.

[starshipeleven]

Yep, because comparing a package manager to systemd is valid. Not. One does 1 thing the other wants to absorb everything.

yes it is valid, regardless of what you think.

[starshipeleven]

Debian, and especially Debian based distributions like Ubuntu, suit nicely for simple desktop end-users.

No they don't. end users want to install random software or latest software, and this is usually not possible with traditional package managers.

DEB packages are simple, and with fixed distribution releases, it makes perfectly stable system.

the same can be said for any other package used by linux distros

[c117152]

Debian, and especially Debian based distributions like Ubuntu, suit nicely for simple desktop end-users. DEB packages are simple, and with fixed distribution releases, it makes perfectly stable system.

With conventional package managers you often run into library version conflicts even in desktop use cases. A CAD program wanting one version of qt that breaks compatibility with the one your WM / music player requires...A closed source game that has a whole list of out-of-date libraries that can't be installed next to updated versions... A python script that... well, any python script since they all break over a short period of time over package versions.

Arch solves this by forcing everyone to update immediately whether their user software can keep up or not. Debian forces everyone to stay with old stuff and hopes the maintainers and devs would backport patches. Ubuntu is half way in between and twice the breakage. Only Guix and Nix keep up without disrupting the system and your productivity since they can upgrade everything that's possible to upgrade while letting the stuff that hasn't updated yet work with the old dependencies.

Desktop wise it can be made as simple as Android's Play store + Settings menu rolled up into one GUI in the same way you can have XML editors since it's all functional languages. I believe Guix has a side project working towards that. Not sure about Nix. Either way, if a serious player like Canonical or Red Hat wanted, they could spin a very desktop friendly version under a few months.

[S.Pam]

No they don't. end users want to install random software or latest software, and this is usually not possible with traditional package managers.

the same can be said for any other package used by linux distros

Except perhaps for Gentoo and systems with portage.

[chithanh]

DEB packages are simple, and with fixed distribution releases, it makes perfectly stable system.

No they don't. end users want to install random software or latest software, and this is usually not possible with traditional package managers.

the same can be said for any other package used by linux distros

Except perhaps for Gentoo and systems with portage.

Creating and customizing Gentoo ebuilds is a pleasure, and users often directly attach ebuilds or ebuild diffs to bug reports with their suggested fixes. I think with Arch pkgbuilds it is similar.
Creating .deb and .rpm packages however is a pain. You will not see end users doing it to any significant degree.

Guix/nix are a bit more involved getting your head wrapped around in comparison, but nowhere near as painful as .deb and .rpm.