Hacker News Reader

Comment by shpx | Hacker News Reader

Guix doesn't package proprietary software.

Which is great. Means you have a clean install that's sure to be reproducible. There's always the option to keep your own channel of non-free packages if you really need them.

Proprietary packages may still be reproducible. Presumably, you verify a hash of the inputs (e.g. upstream tarball/binary and patches), and the output should still be bit-for-bit the same on any machine given the same inputs.

Not to mention that there are many open-source (as in OSI) packages that may not be distributed with Guix System because they use non-FSF-approved software licenses.

> Not to mention that there are many open-source (as in OSI) packages that may not be distributed with Guix System because they use non-FSF-approved software licenses.

This is not true; at the very least "many" is wrong in the above statement. Generally, there is virtually no difference between the OSI set of approved licenses and the FSF set.

Can you list examples of the many packages that would be considered "open source" (according to the OSI definition) but not also Free Software as per the FSF definition?

The official Guix channels do not package proprietary software. However, nothing is stopping someone from doing it.

Tried to install nvidia drivers (the only piece of proprietary software I needed) — no luck.

Hope that with 1.0, somebody will find a way.

It's definitely not trivial to do. I have the Guix system installed on my mid 2013 MBP. I installed the mainline Linux kernel and drivers along with the proprietary Broadcom wireless module. Everything seems to be running fine.

Did create a package for it? Is it available?

This is going to be a deal breaker for a lot of HPC folks, so it's surprising to me that there isn't an "unofficial official" way to get non-free Nvidia drivers given Guix's aims at reproducible builds for HPC.

I don't think it has Nvidia drivers, but there is work being done for Guix and HPC. https://guix-hpc.bordeaux.inria.fr/

Sounds like you can use just the package manager, so I guess there's nothing stopping you from installing just the proprietary blobs with your system package manager and build everything else with guix?

The only distro I know of which packages nvidia proprietary driver not as an original blob and a bunch of scripts is Debian. To say it's a mess is understatement (list of dependencies by metapackage[0], which doesn't include all driver parts either).

[0]https://packages.debian.org/sid/nvidia-driver

edit: wording

Pop_OS! By System76 makes these accessible at the installer. It's why I chose it for a recent Lenovo laptop purchase.

So now you know of 2.

Pop_OS is based on Ubuntu, which is itself derived from Debian.

Pop_OS does not reuse Debian's packaging for this, does not do it the same way Ubuntu does. It also bundles it with the OS installer image, which can be pretty important.

These are decisions that OS authors make. Even if they are derivative, it is worth calling out these specifics. Especially if it enables painless adoption of the OS on specific hardware rather than saying "well it's just Debian."

As Ubuntu does on theirs. The thing is, Ubuntu is stated as officially supported by Nvidia's blob itself, although it doesn't remove all the fun of their driver's installation and configuration processes.

Yeah I only mention pop_os because it truly is a painless process for a fresh install and that's worth calling out. Life is too short to suffer installing uncooperative Linux distros on modern laptops.

This is trivial to do on NixOS:

  services.xserver.videoDrivers = [ "nvidia" ];

For a full install for eg machine learning, you'd want these lines, too:

  environment.systemPackages = with pkgs; [
    cudatoolkit
  ];

  systemd.services.nvidia-control-devices = {
    wantedBy = [ "multi-user.target" ];
    serviceConfig.ExecStart = "${pkgs.linuxPackages.nvidia_x11}/bin/nvidia-smi";
  };

(you do need to set config.allowUnfree = true; or the nvidia stuff will be hidden)

You can download blob from official site, but it wouldn't work in a lot of cases after installation process while giving you no options for some choices there are (like GLX provider or vendor-neutral OpenGL libs), that's the difference of Debian's metapackage.

Is it possible to convert the packages for nixos to guix? Seems like someone should create a nonfree repo for guix to allow people to simply add a new source for nonfree software.

If I understand properly this is done via GUIX_PACKAGE_PATH which works somewhat like PATH in that multiple sources are searched in order of precedence.

https://www.gnu.org/software/guix/manual/en/html_node/Packag...

Instead of hoping that someone does it you could always do it yourself and host it somewhere everyone can benefit from.

GUIX_PACKAGE_PATH is inconvenient. We prefer to use channels instead:

https://www.gnu.org/software/guix/manual/en/html_node/Channe...

That's a feature. A good one.

I need to run CuDNN. I'd happily take a conceptually-pure operating system in every other respect, but without that package I can't use it for anything.

Perhaps locking me out is a feature, but it isn't a very welcoming one.

Guix doesn't prevent you from using proprietary software. It gives you all the tools you need to use package modules published by other people, or to package them yourself. This is free software after all: you have the freedom to use Guix for any purpose including the installation of non-free software.

I'm not just saying this to make a nitpicking point: Guix makes it easier to, say, build a custom kernel using the same reliable and hackable mechanisms Guix uses for Linux libre.

It's just that the Guix project itself won't recommend projects that extend Guix with package definitions for non-free software, nor will it include said packages by default.

Guix is still a general purpose operating system running on a general purpose computer. You should be able to run any software on it that is GNU or Linux compatible.

If you don't want to go through the pain of installing it outside of a package manager, that's fine, but that's not "locking you out", it's putting the blame where it belongs: the proprietary ISV.

Reply on news.ycombinator.com