Guix(SD)

• "technically" alpha, with caveats :)
• I'm not a traditional distro / packager hater! (I love Debian; also thanks for the space, Red Hat!)

"wtf does that mean?" you say!

In brief: packages are based "purely" on their dependencies. And same with the dependencies of dependencies!

We'll come back to this!

• Nix pioneered most of the ideas of functional package management!
• Most of Guix's design follows Nix
• But not the same codebase
  • Only Guix's daemon comes from Nix
  • They both use "Hydra", a continuous integration system, to build binary packages though
• And not the same language:
  • Nix uses a mishmash of languages, including a special DSL for packaging
  • Guix uses Guile… for nearly everything

• Default packages are 100% libre.
• This is another difference from Nix…
• You could taint things with nonfree software, but the base will always be pure. Better foundations: easier to taint something than to remove impurities later.

• Atomic: Either everything succeeds, or nothing does. Never have a system broken mid-install again.
• Time travel: roll back and forward without pain.
• Multiple profiles:
  • Your company's application A is on Django 2.X whereas application B is stuck on Django 1.9? No problem.
  • Each user can have their own profiles, separate from the system! You need GCC 5, but your sysadmin only installed GCC 4? No problem.
• Can serve as a universal package manager
• Can provide an isolated "environment" for hacking… Like a universal "virtualenv", for any language

This is kind of a stretch! But git might feel familiar, so..

cwebber@earlgrey:~/devel/sly$ git cat-file -p 6573261753243257c7b168e174d45c9cd40061ee
                                       
tree 3bcdcbeac414887a356b375a4b230f80159efe2f
parent c23f81b59db98d7af4fd91a41c9b366823662083
author Christopher Allan Webber <cwebber@dustycloud.org> 1434053151 -0500
committer David Thompson <davet@gnu.org> 1434416170 -0400

examples: Add Conway's Game of Life.

* examples/life.scm: New file.
* examples/Makefile.am (nobase_dist_examples_DATA): Add it.

• We refer to commits by their hashes… we'll see more hashes in Guix for similar-ish reasons…
• A commit's parents get hashed in as a kind of depenency … See how git's history is immutably tied to its parents?
• But feature-wise, making a new commit doesn't "destroy" the old version.

(This metaphor only goes so far, for example, you can easily drop old history and reclaim that space in Guix…)

• My system failed mid-upgrade and now it's BORKED
• Oh no I thought this upgrade was okay but now it isn't
• My server is a special snowflake and I have no idea how to reproduce or replace it
• This deployment system has a turing tarpit of custom config languages (I've fallen and I can't get out!)

But maybe most critically for me:

• I work on a sizable network freedom project, GNU MediaGoblin
• Network freedom is near-impossible current state of deployability
  • Running MediaGoblin has given me plenty of experience here
  • See many users start "self hosting", but give up because maintainance burden / anxiety too high
• Tired of my project working or not depending on "phase of the moon"
  • Dependency based failures suddenly not working kills uptake and new contributor enthusiasm
  • Once had a hackathon, prepped all previous day for it, had users show up, and our dependencies were broken

I don't want to live on that kind of planet anymore.

So… how can Guix help?

===================================================================
  A pure function:
  
  1. Given the same arguments, must always produce the same output.
     (Can't rely on any data that might change!)
  2. Doesn't cause any observable "side effects".
     (Can't change anything that isn't its result!)
===================================================================

Simplified from: https://en.wikipedia.org/wiki/Pure_function

(Yes, that's all functional programming means! But what is extrapolated from those requirements is what makes things interesting…)

"Side effects" are not allowed:

• It can't do any IO
  • It can't read or write from the filesystem
  • No network access
• No changing global variables or relying on changing variables
• No GUIs, no widgets
• Definitely no "random" procedure
• No printing or beeping
• No mutating data that is accessed elsewhere

Coding with side effects is called "imperative programming"

"impure" functions are more accurately "procedures"

# A function
def greet(name):
    return "Hello, " + name

# A procedure (NOT a function)
def greet_printer(name):
    print("Hello, " + name)

Printing to the screen is a "side effect"

===================================================================

Break your program into two parts:

 - The clean part: purely functional!
   Make as much of your program into this clean part as possible.
 - The dirty part: do side effects here.
   Make this as small and "quarantined" as possible.
===================================================================

===================================================================

Use the dirty part as scaffolding for the clean part,
this way state is pushed to the fringes of the program

===================================================================

Think about it! The dirty system state flows into the functional system as an argument, and evalues to a result out back the other end to flow back into the imperative system.

• Packages are built out of a package definition (function) and take very precise inputs
• Side effects during package building are forbidden!
  • No network IO!
  • No reading or writing outside of package building!
• To enforce this, we'll build packages in a chroot that has very few privileges and no network access

But wait… isn't package building kinda inherently imperative? Compiling files means reading from files, writing out new files, etc!

• Correct observation! However, we can uphold the "pure function" contract as long as imperative code is "confined" to the chroot
• Think of the chroot as the memory space of the function. It'll be discarded after the function "evaluates"

The result of evaluating this "pure function" is called a "derivation"

• This means a binary version is a "memoized" version
• The same inputs on the same architecture to the same package will always yield the same output!
• Reproducibility! We can be sure that once something builds, it will always build.
• No clobbering previous packages… if we can access their former inputs, we can always reproduce and return to their outputs.

guix package -i extremetuxracer

Now let's run it!

etr

What does this show us?

which etr

Where does that point us to?

• What's this ~/.guix-profile/ directory?
• What's this /gnu/store/ directory stuff in there points to?

Let's get a graph of coreutils:

guix graph coreutils | dot -Tpng > /tmp/coreutils-dag.png

How about Tuxracer? :)

guix graph extremetuxracer | dot -Tpng > /tmp/extremetuxracer-dag.png

How about GNU Hello?

guix graph hello | dot -Tpng > /tmp/hello-dag.png

Oh wait… that looks really simple… it's just hello! How can that be?

The above commands ommitted "implicit inputs"… dependencies that are needed to build, but aren't needed to run.

I've already generated the graph for coreutils:

guix graph coreutils --type=bag-emerged | dot -Tpng > ./static/graphs/coreutils-dag-emerged.png

A much bigger graph can be generated if you include bootstrapping requirements too :)

M-x guix-generations

• These are previous instances of your profile
• You can roll back to older versions if you need be
• Once you don't need generations, delete them!
• Reclaim old space with "guix gc" (yup, garbage collection)

• If something low down the chain gets a new verison, all of its dependencies will be rebuilt (inputs are verrrry precise)
• This is made manageable:
  • You can drop old generations
  • And then garbage collect them!

Services part of system config defines:

• Daemon management
• Config management

Uses a system called "dmd" to do this, also written in Guile

This does mean that Guix does not use Systemd… but not for systemd-hater reasons!

There is a big benefit to being able to "compose" a system in the same language as the rest of Guix… (can even programmatically generate a system definition based on other requirements)

What happens if you need to deploy MediaGoblin, and..

• Its configuration needs information so it can connect to the Mail Transfer Agent
• It needs to provide configuration to nginx or apache?

How can you do this without duplicating config information all over?

Imagine a web or desktop UI where a user just fills in a few widgets with config stuff, and this can be used to compose the system definition!

S-expressions bring lots of power

But does Lisp stand for:

• Lots of Irritating Superfluous Parentheses?
• or, Lisp Is Syntactically Beautiful?

Let's look at an alternative syntax to s-expressions, with Wisp:

./static/grep.w

Now let's look at the same file, with s-expressions:

./static/grep.scm

Does it look so scary now?

• rainbow delimiters
• syntax navigation
• smartparens / paredit

• containers are great (and Guix supports them)
• distro-sized statically compiled systems are not great

With apologies to Greenspun:

All package management/deployment tools contain an ad hoc, informally-specified, bug-ridden, slow implementation of half of Guix.

http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html

• Guix has solid fundamentals
• A likely foundation for solving the deployment crisis