GNU's advanced distro and transactional package manager | Hacker News Reader

GNU's advanced distro and transactional package manager

gnu.org

127 pointszzzcpan19 comments

They took a lot of inspiration from NixOS[1], which many people successfully use and it isn't in beta (not meant to badmouth GuixSD of their efforts, just wanted to put it out there)

[1] https://nixos.org/

If you click the about link it does in fact name drop Nix:

>It uses low-level mechanisms from the Nix package manager, but packages are defined as native Guile modules, using extensions to the Scheme language—which makes it nicely hackable.

Though I've never bothered to figure out exactly how much if any code is actually shared between the two.

The only code that is shared is the build daemon which is written in C++. Guix uses a fork of the Nix daemon, occasionally cherry picking patches from Nix. C++ is a pain, so in the future this daemon will be replaced by one written in pure Guile.

They implemented the Nix model in Guile, so inspiration is selling it short. Although Guix have arguably passed Nix in terms of features already, with a much better command-line tool, a linter, importers for several external package registries and grafting[0] which is a real pain point in Nix.

I think part of the reason they are now cruising past Nix (despite 1/10th of the users) is that it's written in a proper programming language, and not a home-made language that relies heavily on bash.

That said, I'm really happy with NixOS after two years, and would not consider going back to any "conventional" distro for my own workstation. Coming from a Gentoo background, there is nothing like screwing up your system and simply booting into the previous generation :)

Having the entire system configuration in one place that can be version controlled is a big plus too. You can create a live CD, VM, container etc from the very same code.

Nix and Guix can also be used standalone (think Homebrew or Gentoo Prefix), and can be very handy shell tools. E.g. `guix environment foo`[1] will drop you to an ephemeral shell environment with all build dependencies of package foo available.

0: https://www.gnu.org/software/guix/manual/html_node/Security-...

1: https://www.gnu.org/software/guix/manual/html_node/Invoking-...

One upside (or downside, depending on your PoV) of Nix is that unfree packages exist (though disabled by default) in the standard repo. Want the actual useful graphics drivers for gaming? Steam? Both easy to install.

I love the idea of using a real language, a real LISP, instead of that Nix-contraoption, but currently having access to FSF-approved free software only is a complete deal-killer for me on my laptop. I still need some unfree software, and I don't care about software patents (ref for instance MP3 and H264 decoding).

If Guix gets to the point where every concern except that surpasses NixOS, we might see a close-to-upstream Guix-fork or third party repo (like MELPA and MARMALADE for Emacs) being established to address that.

Or at least so we can hope.

Honestly, I'm quite fond of Nix. Some of the more complex library code is quite gnarly, but I prefer the almost-JSON-ish nature of Nix for most package definitions over sexps.

Package repositories are just Scheme modules. Guix supports loading of additional package repositories via the GUIX_PACKAGE_PATH environment variable.

The fact that Guix won't distribute packages for non-free software does not mean that it restricts you in using Guix to manage such software packages.

I am a happy NixOS user but am glad to see this project progressing and gaining a wider audience. It shows that the ideas behind Nix are solid and offer more than just theoretical advantages over a traditional OS (and its package manager).

I think a lot of people will get a taste of these advantages through e.g. Docker and Snappy and will eventually go all in with GuixSD or NixOS. These types of stateless software ecosystems will continue to become more common until eventually they are the norm.

Can someone comment on how things like kernels, kernel modules, and bootloaders work in Guix? It seems like these sorts of things wouldn't be possible to handle in a purely functional manner since, for example, you can only install one bootloader to a disk, and you can only boot into one kernel.

Disclaimer: I haven't ever used Guix, but I've used NixOS which builds on the same roots.

Typically your total system-configuration can be divided into a few distinct parts: bootloader and filesystem-partitions, kernel and software.

These features are to some extent dependent on each other, but not in any way which breaks dependency management or causes conflict, and thus can mostly be treated distinctly.

Basically you configure A bootloader, not several. The configuration is about which one that is and where you put it. Depending on if you use UEFI or not, this is either 100% tied to the filesystem layout, or just 99%.

Then the rest of the tooling just uses that info to populate the boot menu. In functional terms, a bootloader should have no side-effects on the system booted, so as long it boots the system, you should be fine.

The kernel doesn't really care about what bootloader you use as, as long as it boots it with the correct parameters. You can have several kernel-configurations in parallell which are accessible from the same bootloader-menu, but as you say, you cannot be booted into several versions at the same time.

That's not really a real-world problem though, because software very rarely depend on a specific kernel-version, they just depend on having a kernel. If a package depends on specific kernel modules, it's free to add these as dependencies, which will be resolved.

This means you can have a 100% functionally constructed system on top of a few config-files, with minimal chance of crafting a configuration which is internally incompatible. If it is, the tooling will tell you, and your system build will fail.

You can also have several mututally incompatible configurations within the same filesystem and boot between or chroot into these. It's an incredibly powerful concept.

The only reason I'm not running NixOS today on my laptop is that I need 100% end-user finish with regard to a "just works" desktop, and I'm not willing to build that myself, one package at a time, with the limited spare-time I have.

So I appreciate and respect both NixOS and GUIX and the work being invested in them, but for now I run Fedora :)

I'm sorry for being so naive but when they say "GNU Operating System" do they mean HURD or is this a GNU/Linux distro?

"As of version 0.10.0, the Guix System Distribution can be installed on an i686 or x86_64 machine. It uses the Linux-Libre kernel and the GNU Shepherd init system. Alternately, its package manager, GNU Guix, can be installed as an additional package manager on top of an installed Linux-based system."

http://www.gnu.org/software/guix/download/

So, in other words, it has all the disorganized chaos of Linux, but lacks the user-friendliness because your wifi, graphics, and sound cards won't work.

Might as well run BSD: Your peripherals still won't work but at least the system underneath is still more coherent.

FreeBSD runs every single driver on my laptop. And most common stuff has OSS drivers implemented for it, and Linux Libre has them.

Is the performance good? Last time I ran BSD on my thinktop, I got 2 hours of battery life and the system ran 10 degrees hotter than debian.

Well part of GuixSD is actually trying to be more coherent. Guile underlies the init system, the package manager and quite a bit of system configuration between the two.

I'm using GuixSD on most of my machines and all peripherals work. It's a matter of choosing hardware that does not require proprietary software.

Thanks, I tried but couldn't find this specific bit of information.

Reply on news.ycombinator.com