Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Love Arch, but GNU Guix Is My New Distro

boilingsteam.com

Post reply on HN
Print view View original

31–40 of 318 posts

Re: I Love Arch, but GNU Guix Is My New Distro

#31

Post by masklinn »

NavinF wrote: post #24
masklinn wrote: post #16

Earlier quoted context omitted.

Author is a lisper, is a good reason. And while nix may be battle tested that doesn’t translate to a good experience, the learning curve is high and the documentation while plentiful is not really good or helpful to beginners. Plus the entire thing is in flux right now between flakes, home-manager, and a desire to kill nix-env.

> Author is a lisper, is a good reason. If I read this on any other website I’d assume it’s sarcasm. Only on HN, folks.

I don't understand why it would be sarcasm on any site. That is the original divergence, Guix was a version of Nix built on Guile instead of Nix.

If you're a long-time lisper interested in the ideas embodied by nix/guix, that alone is a lot of points for guix.

Re: I Love Arch, but GNU Guix Is My New Distro

#32

Post by Gentil »

I moved to NixOS and came back to Arch because setting up development environments for general purpose computing felt tricky. I was on a schedule so had to drop it. Is it the same for Guix? I don't know why it should be any different. But still asking.

Also, am guessing people will likely have hardware compatibility issues for Guix which isn't a problem for NixOS since they bundle non-free drivers etc.

Re: I Love Arch, but GNU Guix Is My New Distro

#33

Post by Gentil »

geokon wrote: post #20

Is there a reason neither Guix nor Nix have made an LTS-type repo? A rolling release seems at odds with the stability granted by reproducible builds. Maybe I have a miopic view, but what's nice with Ubuntu LTS is you know everyone and their mothers has built and tested their packages/libraries/executable against the lib versions provided by Ubuntu 18.04 or 20.04 or whatever. You also know those libs, at their given v…

Good points made by others. But another thing is you don't have to? Nix(OS)/Guix installs packages and dependencies separately instead of replacing packages like other OS/package managers do.

This means you have multiple versions of a package installed in your system and that you can use them simultaneously for different applications if I understand it right. You can move back and forth between versions if one breaks without effecting the rest of the system. Also if I remember, nixos-update rebuild switch (or something very similar to this command) which is usually fired after installing new packages or when a major change is made to the nix configuratino file creates a new boot entry and hence a snapshot for you to go back to if something in NixOS breaks. So there is no necessity for an LTS version to be present for stability's sake.

Garbage collection is also left to the end user to deal with. There is a garbage collector command in Nix package manager which will clean up when you push the command so that new packages are not flooding your storage space.

NixOS's stable channel can be very loosely compared to Manjaro in the sense that just like Manjaro, NixOS's Stable repo does opinionated changes/interferences/fixes. And NixOS Unstable is like Arch linux with latest and greatest upstream stable versions of the packages.

Re: I Love Arch, but GNU Guix Is My New Distro

#34

Post by amelius »

marcan_42 wrote: post #27

> Guix System is an advanced distribution of the GNU operating system. It uses the Linux-libre kernel It's worth pointing out that the linux-libre kernel is developed under the FSF doctrine that "binary blobs are bad unless you can't see them". This has been taken to its logical extreme here, where this Linux fork actively removes security warnings informing users that they need to update their CPU microcode , becaus…

Huh? I've never updated my CPU microcode in other distros, nor did I receive warnings about it.

Do you have a better example?

Re: I Love Arch, but GNU Guix Is My New Distro

#35

Post by computer »

amelius wrote: post #34
marcan_42 wrote: post #27

> Guix System is an advanced distribution of the GNU operating system. It uses the Linux-libre kernel It's worth pointing out that the linux-libre kernel is developed under the FSF doctrine that "binary blobs are bad unless you can't see them". This has been taken to its logical extreme here, where this Linux fork actively removes security warnings informing users that they need to update their CPU microcode , becaus…

Huh? I've never updated my CPU microcode in other distros, nor did I receive warnings about it. Do you have a better example?

Yes you have, it's done automatically.

Re: I Love Arch, but GNU Guix Is My New Distro

#36

Post by LeoPanthera »

amelius wrote: post #34
marcan_42 wrote: post #27

> Guix System is an advanced distribution of the GNU operating system. It uses the Linux-libre kernel It's worth pointing out that the linux-libre kernel is developed under the FSF doctrine that "binary blobs are bad unless you can't see them". This has been taken to its logical extreme here, where this Linux fork actively removes security warnings informing users that they need to update their CPU microcode , becaus…

Huh? I've never updated my CPU microcode in other distros, nor did I receive warnings about it. Do you have a better example?

You might have, without realising it. It's supplied as a package in nearly every distro.

Here's the Debian package for the Intel microcode, for example:

https://packages.debian.org/bullseye/intel-microcode

Debian hides it away in their "non-free" repo but it's in the default install in many other distros.

Re: I Love Arch, but GNU Guix Is My New Distro

#37

Post by detaro »

amelius wrote: post #34
marcan_42 wrote: post #27

> Guix System is an advanced distribution of the GNU operating system. It uses the Linux-libre kernel It's worth pointing out that the linux-libre kernel is developed under the FSF doctrine that "binary blobs are bad unless you can't see them". This has been taken to its logical extreme here, where this Linux fork actively removes security warnings informing users that they need to update their CPU microcode , becaus…

Huh? I've never updated my CPU microcode in other distros, nor did I receive warnings about it. Do you have a better example?

... yes, because your distro did the right thing and does provide updated packages and loads them for you (it's not persistent, but rather done on each boot), and thus you don't need to do anything and also don't see warnings about your distro failing to do so. Whereas linux-libre doesn't want you to know if your distro isn't loading updated microcode, because it's "better" (according to them) to run vulnerable non-updated microcode than letting you get tempted to use non-free updates to the non-free firmware in your CPU.

Re: I Love Arch, but GNU Guix Is My New Distro

#38

Post by amelius »

jordanbeiber wrote: post #22
earthscienceman wrote: post #13

A question that nags me every time Guix comes up, or nix, is about the benefits relative to a normal distro on something like ZFS. Are reproducible builds ever going to be all that important to a user? Rollbacks seem like the key feature here and that seems much better left up to the filesystem, not the package tools. This way your storage is also aware of what you're doing.

A couple of things - if the system can handle rollbacks it will be much more reliable than using the fs, as the fs knows nothing about actual state. It knows about blocks commited to disk. Usually they look the same, but not always. Then there’s the question of how exactly you reached this state. Having nixos generations is like having an event stream of all changes. Apply your backup to a new machine, what happens?…

How does Nix work with less sophisticated package managers that run on top of it, e.g. Python's "pip"?

Re: I Love Arch, but GNU Guix Is My New Distro

#39

Post by soraminazuki »

geokon wrote: post #20

Is there a reason neither Guix nor Nix have made an LTS-type repo? A rolling release seems at odds with the stability granted by reproducible builds. Maybe I have a miopic view, but what's nice with Ubuntu LTS is you know everyone and their mothers has built and tested their packages/libraries/executable against the lib versions provided by Ubuntu 18.04 or 20.04 or whatever. You also know those libs, at their given v…

Nix may not have a LTS release, but it certainly does have stable releases. The biannual releases are there precisely for this reason [1].

What's more, the issues you have with package pinning are more of a problem with traditional package managers. The situation is better on Nix and Guix because it provides you with more control and flexibility over packages.

With traditional system-level package managers, you can't really pin a subset of installed packages. Since all packages are installed into a shared location and depend on each other both explicitly and inexplicitly, packages in a distro release are tightly coupled together. It's just not possible to swap out or pin a subset of packages without the risk of breakage. As a result, a dedicated distro release consisting of old packages is needed to keep using older versions of packages.

This is not the case for Nix and Guix, which installs different packages in their own isolated locations. Packages are more loosely coupled, and you can mix packages from stable channels, unstable channels, and even specific git commits of those channels. Using pinned versions of critical system package is also less of a risk because different versions of the same package can coexist on a single system. Even if something does break, you can always roll back.

Finally, Nix and Guix provides ways to fix issues for pinned packages. With Nix/Guix packages, you're not stuck with whatever the distro provides you with. They're more flexible and allows you to create your own custom packages out of existing ones. For example, here's how you can backport patches for a pinned package on Nix:

    existingPackage.overrideAttrs (old: {
      patches = old.patches ++ [
        (fetchpatch { url = "..."; sha256 = "..."; })
      ];
    })
So while the lack of a LTS may be a bit disappointing, I wouldn't consider it a complete dealbreaker because the features and tooling makes up for it.

[1]: https://nixos.org/blog/announcements.html

Post reply on HN