Hacker News new | past | comments | ask | show | jobs | submit login
GNU Guix and GuixSD 0.14.0 released (gnu.org)
69 points by Ruud-v-A on Dec 7, 2017 | hide | past | web | favorite | 24 comments

I really wish Guix and NixOS had more usage in the industry.

I am not sure if these are the projects that are going to drive the innovation, if they are only showing the way for the 2nd-generation functional package managers, or if this will just remain a niche forever.

Guix is used as a package manager in HPC environments in order to deploy reproducible software environments. There's a dedicated Guix HPC project: https://guix-hpc.bordeaux.inria.fr/

There are still, unfortunately, some rough edges with Nix.

Nix does not use versions for packages, instead relying on channels and pinning, which can be confusing at best.

There is a manual, but not a good wiki. While you can learn to read the syntax, there isn't any good introduction to write it. Nix derivations are very unique, and difficult to approach without examples and guidance.

Out of curiosity, were you already knowledgeable about lisp/scheme/fp before using nix ?


It's not the functional nature of Nix that is hard to deal with. Nix's functional nature is actually its saving grace.

My difficulty with Nix is that there are important subjects that aren't taught.

I figured out how to create a usable `default.nix` and `shell.nix`, but that takes a lot of effort, and there really aren't many resources to reference.

Nix expressions use a lot of predefined functions, and I have no idea where their documentation exists, if it does at all.

Even if there is some explanation for all of the functions that I need to use, there isn't documentation for how to fit them together.

Instead of being in dependency hell on the outset (like most package managers), I find myself in dependency hell when I want to do something different. The Nix community has an irrational hatred of version numbers, meaning you have to scour the web for a derivation that gets the right version of a dependency, and "pin" it, or hope that the channel you are using has the correct version. Even when channels do have the version you want, sometimes that channel provides multiple package versions, some with the version in the name.

Names are a mess. Since every package must exist in the same namespace, but its derivation is helpfully sorted into a directory tree, the same packages will often have different names. There isn't a good way to search or browse for them either. I end up digging through github quite often, which is a lot more often than the never that I should find myself doing so.

Nix is wonderful. NixOS is by far my favorite OS, and that is why I deal with all of the rough edges, but they certainly are rough.

In Guix package definitions are first-class values. They are arranged in Guile modules so they don't pollute a single namespace (though usually packages have unique names anyway). With standard Guile features one can uniquely specify variables that may have the same name.

Package definitions can often be generated automatically with importers. For example, `guix import cran -r recipes` creates package definitions for the recipes package and all its R dependencies. They usually work with minimal adjustments.

Jumping to package definitions is easy thanks to REPL support (e.g. with Emacs + Geiser), but you can also use `guix edit name` and it will spawn an editor to edit the package "name".

Creating variants of packages is trivial as package definitions can inherit from existing definitions. I maintain a bunch of different versions for bioinformatics tools. I can select them on the command line simply by appending the version string, e.g. "samtools@0.1".

Guix has a comprehensive manual with a procedure and variable reference and examples.

I really like Guix and GuixSD because of how consistent and hackable it is.

I see, lots of work to be done. My question was mostly about the derivation idea (much like a lambda) that would be confusing for people not used to this style.

Also, this popped on twitter https://github.com/Gabriel439/slides/blob/master/nix-interna...

The derivation idea isn't too difficult to understand, because it is rather elegant.

The problem with derivations is that they are like a library without a reference

The functions that are to be used in derivations aren't documented clearly, at all, or in an obvious place.

The problem is that _every_ _single_ _program_ has to have its configuration files rewritten to take nix or guix into account, and every sysadmin has to know how to use the new nix or guix way.

I don't think this is the case. I've packaged several things for Guix, and patches are rare. Stuff that has good configuration (e.g. uses GNU make, and thus accepts --prefix) will be fine.

Wait, I thought that guix (like nix) keep their full configuration in flat nix or lisp files (like https://www.gnu.org/software/guix/manual/html_node/Using-the... )?

I never really tried guix, but that's how nix works ( https://nixos.org/nixos/manual/index.html ). So how does Apache configuration on upstream (meaning, how it's configured on Windows/Linux/FreeBSD) correlate to how it's configured on nixos/guix?

It depends. You can install it with nix/guix and configure it as in any other Linux distro.

Or, if it's a service you want to make the configuration totally reproducible, you can use https://www.gnu.org/software/guix/manual/html_node/Services.... interfaces for those packages that have some written for them.

But there's nothing wrong with regular dotfiles.

What would boost uptake is for just one of the major distros, especially Ubuntu, to release a spin/variant based off either.

There are some deployments in the industry already. AFAIK, Logicblox employs Nix creator.

Both Nix & Guix are past proof-of-concept stage. In particular, I've found Guix very elegant, simple and useful.

I guess I should use this time to shamelessly plug one of my side projects, farch: https://github.com/shawndellysse/farch

It's an attempt to bring the functional system paradigm to Arch linux, giving you the "my system is a function of my configuration" approach combined with not having to relearn how to administer a linux system like GuixSD and NixOS require.

> Hackable. It provides Guile Scheme APIs, including high-level embedded domain-specific languages (EDSLs) to define packages and whole-system configurations.

What is the benefit of directly using Scheme for the package declarations over using NixOS's DSL? Specifically, what technical features does Scheme make possible which are not possible in NixOS?

> what technical features does Scheme make possible which are not possible in NixOS

Integration of all stages. We use the same language on the build side as on the host side; the same language to execute builds as to define packages. In Guix there is no mix of languages, so we don't need to glue strings together produce build-side shell scripts. Instead we can use higher-level S-expressions and code staging.

For more on code staging see this paper:

This allows for code reuse, even across projects, e.g. the GNU Shepherd init system can take the container code from Guix and run services in isolated environments with very little effort. See this blog post for details:

FWIW, Guix implements a DSL that's embedded in Scheme (it's not just "raw" Scheme). The advantage of embedding is tooling: you can work with package definitions right there in the REPL / with Emacs+Geiser; you can use the Guile debugger features.

Another result is that all these package definitions form a lazy graph of live Scheme values. In Nix you have a large hash table of identifiers to functions. Think code vs data. In Guix the primary data structure is an emergent lazy graph; it is not merely an inert description of such a graph. Each package definition is just another Scheme value.

I'm a complete beginner but, for example, comparing Nix's Firefox and Guix's IceCat you can see that with Nix you have to fallback to shell scripting for some tasks while with Guile you can perform those operations with Scheme.

Nix's Firefox: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...

Guix IceCat: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages...

Are those really the same package definitions? The guix one contains build instructions and the nix one is for binary packages.

No they aren't. I was pointing to the fact that in Guile you don't need shell scripting where you can use functions like 'mkdir', 'symlink', 'copy-file', 'file-system-tree', etc..., so you can use scheme with all the support Emacs, Geiser and guix.el give you.

Is this Linux?

The site should be more direct about whether or not it is Linux.

I don't have time to wade through reams of words to work out what something is. Just tell me.

It's not clear at all why this matters or is better than other operating systems. If this is a competitor to Linux then the first thing they need to address is "why should you care?", if it is Linux, then the first thing it should adress is "Why you should use this over other distros"

They ought to have said Gnu/Linux, as per their own propaganda!

I'm guessing if the word "Hurd" doesn't appear anywhere on the page, it's still Linux.

Linux is just the kernel. GNU as a name for the system is okay, while Linux is arguably not. GNU/Linux is just a compromise for those who insist on naming Linux. Also, from the projects website, we have

"GuixSD is a distribution of the GNU operating system centered on the GNU Guix package manager. It uses the Linux-libre kernel, and support for the Hurd is being worked on."


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact