#+TITLE: Functional Package and Configuration Management with GNU Guix
#+AUTHOR: David Thompson
#+EMAIL: davet@gnu.org
#+DATE: Wednesday, January 20th, 2016
#+DESCRIPTION:
#+KEYWORDS:
#+LANGUAGE:  en
#+OPTIONS:   H:1 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS:   TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc
#+INFOJS_OPT: view:nil toc:nil ltoc:t mouse:underline buttons:0 path:http://orgmode.org/org-info.js
#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport
#+LINK_UP:
#+LINK_HOME:
#+startup: beamer
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [bigger]
#+COLUMNS: %40ITEM %10BEAMER_env(Env) %9BEAMER_envargs(Env Args) %4BEAMER_col(Col) %10BEAMER_extra(Extra)
#+LATEX_HEADER: \beamertemplatenavigationsymbolsempty

* About me

  - GNU project volunteer
    - GNU Guile user and contributor since 2012
    - GNU Guix user since 2013
  - Day job: Ruby + JavaScript web development / "DevOps"

* Overview

  - Problems with application packaging and deployment
  - Intro to functional package and configuration management
  - Towards the future
  - How you can help

* Preface: User autonomy and control

  It is becoming increasingly difficult to have control over your own
  computing:

  - Growing number of applications that cannot be reasonably packaged
    for GNU/Linux distributions
  - Self-hosting web applications requires too much time and effort
  - Growing number of projects recommend installation via =curl | sudo
    bash= or otherwise avoid using system package managers
  - Users unable to verify that a given binary corresponds to the
    source code

  This is bad for desktop users and system administrators alike.

* Problems with package management

  - Global state (=/usr=) that prevents multiple versions of a package
    from coexisting
  - Non-atomic installation, removal, upgrade of software
  - Nondeterminstic package builds
  - Proliferation of language-specific package managers
  - Reliance on pre-built binaries that few can build from source
  - Binary bundles (a la OmniBus) complicate secure system maintenance
  - System package managers do not allow unprivileged operation

* Problems with mainstream configuration management

  - Imperative paradigm makes software overly-complex and brittle
    (idempotence is hard)
  - Promotes one disk image per application to cover up underlying
    package management mess
  - Made primarily for developers for server maintenance, but all
    users could benefit

* Qualities of good software

  - System integration
  - Reproducibility
  - Security

* System integration

  - Use the system package manager!
  - Not uncommon for today's web applications to require 2 or more
    package managers to get all dependencies

* Reproducibility

  - Growing number of free software projects that no one knows how to
    build from source

* Security

* Solutions?

  - Ansible?
  - Docker?
  - OmniBus?

* Functional package management

* What does it mean?

   Treating package builds as functions, in the mathematical sense...

* Why?

* What's wrong with dpkg/yum/pacman/etc.?

    Lack of transactional updates, rollbacks, unprivileged package
    management

* What about Docker?

   Trusting random binaries, non-reproducible, no provenance, opaque
   disk images...

* Reproducible builds

* What are they?

* Why is it important for security and freedom?

   reproducible-builds.org

   guix challenge

* GuixSD: Configuration management

    guix system, declarative interface, fully free, system rollback

* Choice of language

* Off the beaten path

   Guix takes a different approach than a lot of other
   package/configuration managers

* Embedded vs. External DSLs

   Using an extensible programming language as a host has several
   advantages compared to external DSLs:

   - No new parser, interpreter/compiler, editor tools, etc. to
     maintain

   - Access to all available libraries of the host language

   - Extensions to the host language can be used as a library by
     others

   Not all general-purpose programming languages are suitable for
   embedding new languages, [fn:1] so which did we choose?

* Guile Scheme

   - GNU Guile is a Scheme implementation and the official extension
     language of the GNU project

   - It's a great choice for EDSLs because of Scheme's hygienic macro
     system

   - It's a great choice for Guix because purely functional
     programming is well-supported in Scheme

* Guile all the way down

   Guix uses Guile for nearly everything:

   - Initial RAM disk
   - Init system (GNU Shepherd, formerly GNU dmd)
   - Package recipes (including build scripts!)
   - Command line tools
   - Low-level POSIX/Linux utilities (such as =call-with-container=)

* Guix as a library

   Guix is a big collection of Guile modules.

   Packages are first-class Scheme objects.

   Anyone can use Guix as a library to write new Guile programs that
   manipulate package recipes, create new user interfaces (like a web
   UI), etc.

* Development environments

    guix environment

* UIs

    CLI, Emacs, web prototype

* The trouble with language-specific package managers

    Why Guix is better, how to pull in foreign packages with guix
    import, update them with guix refresh

* Project status

* Join us!

  - Chat with us in the =#guix= channel on Freenode or on the
    =guix-devel@gnu.org= mailing list
  -

* Thank you!

  Any questions?

* Legal

  © 2016 David Thompson <davet@gnu.org>

  This presentation is licensed under the Creative Common Attribute
  Share-Alike 4.0 International license.

* Footnotes

[fn:1] "How to be a good host: miniKanren as a case study" \newline
Dan Friedman and Jason Hemann
https://www.youtube.com/watch?v=b9C3r3dQnNY