1 files changed, 655 insertions, 0 deletions
diff --git a/2016-01-20-guix-blu/guix-blu-2016-01-20.org b/2016-01-20-guix-blu/guix-blu-2016-01-20.org
new file mode 100644
index 0000000..8f4547e
--- /dev/null
+++ b/2016-01-20-guix-blu/guix-blu-2016-01-20.org
@@ -0,0 +1,655 @@
+#+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
+#+BEAMER_THEME: metropolis
+
+* About me
+
+  GNU project volunteer
+
+  GNU Guile user and contributor since 2012
+
+  GNU Guix contributor 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
+
+* User autonomy and control
+
+  It is becoming increasingly difficult to have control over your own
+  computing:
+
+  - GNU/Linux package managers not meeting user needs
+  - Self-hosting web applications requires too much time and effort
+  - Growing number of projects recommend installation via =curl | sudo
+    bash= [fn:2] or otherwise avoid using system package managers
+  - Users unable to verify that a given binary corresponds to the
+    source code
+
+* User autonomy and control
+
+  #+latex: \huge{
+  “Debian and other distributions are going to be that thing you run
+  Docker on, little more.” [fn:7]
+  #+latex: }
+
+* User autonomy and control
+
+  This is very bad for desktop users and system administrators alike.
+  We must regain control!
+
+* What’s wrong with Apt/Yum/Pacman/etc.?
+
+  Global state (=/usr=) that prevents *multiple versions* of a package
+  from coexisting.
+
+  *Non-atomic* installation, removal, upgrade of software.
+
+  No way to *roll back*.
+
+  *Nondeterminstic* package builds and maintainer-uploaded binaries.
+  (though this is changing!)
+
+  Reliance on pre-built binaries provided by a *single point of trust*.
+
+  Requires *superuser* privileges.
+
+* The problem is bigger
+
+  Proliferation of *language-specific package managers* and *binary
+  bundles* that complicate secure system maintenance.
+
+* Web applications
+
+  Web applications are particularly painful.
+
+* Web applications
+
+  It’s common for today’s web applications to require *two or more
+  package managers* to get all dependencies.
+
+* Web applications
+
+  Importing a web application available only for a language-specific
+  manager into a distribution proves difficult.  NodeJS is
+  particularly frightening. [fn:6]
+
+* Web applications
+
+  There’s a growing number of popular web applications (Hadoop, Chef
+  Server, Cloudera, etc.) that *no one knows how to build from
+  source*! [fn:3]
+
+* Deployment
+
+  How do we automate application deployment without going crazy?
+
+* Chef/Puppet/Ansible/etc. are pretty good, right?
+
+  Building on top of mainstream package managers and distros yields an
+  unstable foundation.
+
+* Problems with configuration management software
+
+  - Imperative config management is overly-complex and brittle
+    (idempotence is hard)
+
+  - More reliable builds require spawning new machines and building
+    from scratch each time.  (sledgehammer)
+
+  - Made primarily for developers for server maintenance, but all
+    types of users could benefit.
+
+* Docker?
+
+  Surely Docker addresses these issues?
+
+* Docker?
+
+  \center{I’m afraid not.}
+
+  \begin{center}
+  \includegraphics[height=7cm]{containers.jpg}
+  \end{center}
+
+* Problems with Docker
+
+  - Still imperative (though resulting images are immutable)
+
+  - Dockerfile DSL is not expressive
+
+  - Promotes one disk image per application to cover up underlying
+    package management mess [fn:4]
+
+  - No provenance
+
+  - Image layering is an ineffective caching strategy
+
+  - Does not compose (what about the host?)
+
+* Problems with Docker
+
+  Reliance on DockerHub binaries proves to be insecure [fn:5]
+
+  \begin{center}
+  \includegraphics[width=\textwidth]{docker-insecure.png}
+  \end{center}
+
+* Well that was pessimistic
+
+  Computers are hard.  Let’s just look at cat pictures, instead.
+
+  \begin{center}
+  \includegraphics[width=8cm]{cons-cats.jpg}
+  \end{center}
+
+* Meet GNU Guix
+
+  \begin{center}
+  \includegraphics[width=5cm]{guix-logo.png}
+  \end{center}
+
+  Guix is the functional package management tool for the GNU system.
+
+  It is based on the pioneering work of the Nix project. [fn:8]
+
+* Meet GuixSD
+
+  \begin{center}
+  \includegraphics[width=4cm]{guixsd-logo.png}
+  \end{center}
+
+  GuixSD is the GNU/Linux distribution that uses Guix as its package
+  manager.
+
+* What does “functional” mean?
+
+   “Functional” in this context means treating package builds as
+   functions, in the mathematical sense.
+
+   =emacs = f(gcc,make,coreutils,…)=
+
+* Functional package management
+
+  Benefits:
+
+  - Build reproducibility
+
+  - No single point of trust
+
+  - Unprivileged package management
+
+  - Atomic upgrades and roll backs
+
+  - Multiple variants of the same software may coexist
+
+* Functional package management
+
+  The *complete dependency graph* is captured, precisely, down to the
+  *bootstrap binaries*.
+
+  No SAT solver or other complex algorithm for dependency resolution.
+
+* Functional package management
+
+  To view package builds this way, Guix performs builds in an
+  *isolated container* in which *only the specified dependencies* are
+  accessible.
+
+  Build results are *immutable*.
+
+  This maximizes *build reproducibility*.
+
+* Reproducible builds
+
+  Reproducible builds produce *bit-identical binaries* when performed
+  multiple times under the same conditions.
+
+  Requires fixing issues in upstream build systems that are
+  nondeterministic.
+
+* Why?
+
+  “With reproducible builds, multiple parties can *redo this process
+  independently* and ensure they *all get /exactly/ the same result*.
+  We can thus *gain confidence* that a distributed binary code is
+  indeed coming from a given source code.” [fn:9]
+
+* Use cases
+
+  \begin{center}
+  \includegraphics[width=\textwidth]{nsa-vw.png}
+  \end{center}
+
+* Transparent
+
+  Guix is a *source-based* package manager, but will *transparently*
+  download pre-built binaries from a trusted party, if available.
+
+  Otherwise, it will simply build from source.
+
+* Decentralized
+
+  In Guix, there is *no central point of trust* for receiving
+  pre-built binaries (substitutes).
+
+* Decentralized
+
+  Guix provides http://hydra.gnu.org, but it is optional.
+
+  Users may authorize zero or more substitute servers, or even publish
+  their own substitutes for others to use via =guix publish=.
+
+* Challenge authority
+
+  When builds are reproducible, users may *challenge* their substitute
+  providers by building locally and comparing the results.
+
+* Unprivileged
+
+  Users can build and install software *without root privileges*.
+
+* Unprivileged
+
+  Each user may have one or more “profiles”, a union of many packages.
+
+  Use cases:
+
+  - Alyssa and Ben use different versions of Emacs
+  - Alyssa hacks on 2 Ruby projects that require different versions
+
+* Atomic
+
+  Package installation/removal and full-system updates are *atomic*
+  operations, meaning that either the operation succeeds, or nothing
+  happens.
+
+* Roll back
+
+  /Any/ package transaction may be *rolled back*, likewise for
+  full-system upgrades.
+
+  If a full-system update goes wrong, just boot into the previous
+  working generation!
+
+* Coexistence
+
+  Each package has its own *unique* directory in the store that
+  contains its build artifacts.
+
+  You can have every version of Ruby, Python, and Perl under the sun
+  and that’s OK!
+
+* Demo!
+
+  =guix package=
+
+  =guix challenge=
+
+* Hacking
+
+  Guix is made to be maximally hackable, taking inspiration from
+  Emacs.
+
+  We seek to intentionally blur the line between user and developer.
+
+* Choice of language
+
+  Guix is rather special in its choice of implementation language.
+
+* Philosophy
+
+  It’s better to *extend an existing programming language* for package
+  recipes and configuration files rather than making a new,
+  domain-specific one.
+
+* 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
+
+  \begin{center}
+  \includegraphics[width=4cm]{guile-logo.png}
+  \end{center}
+
+   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 goes with everything
+
+   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.
+
+* Example package recipe
+
+  #+latex: \tiny{
+  #+BEGIN_SRC scheme
+    (define-public livestreamer
+      (package
+        (name "livestreamer")
+        (version "1.12.2")
+        (source (origin
+                  (method url-fetch)
+                  (uri (string-append
+                        "https://github.com/chrippa/livestreamer/archive/v"
+                        version ".tar.gz"))
+                  (file-name (string-append "livestreamer-" version ".tar.gz"))
+                  (sha256
+                   (base32
+                    "1fp3d3z2grb1ls97smjkraazpxnvajda2d1g1378s6gzmda2jvjd"))))
+        (build-system python-build-system)
+        (arguments
+         '(#:tests? #f)) ; tests rely on external web servers
+        (native-inputs
+         `(("python-setuptools" ,python-setuptools)))
+        (propagated-inputs
+         `(("python-requests" ,python-requests)
+           ("python-singledispatch" ,python-singledispatch)))
+        (synopsis "Internet video stream viewer")
+        (description "Livestreamer is a command-line utility that extracts streams
+    from various services and pipes them into a video playing application.")
+        (home-page "http://livestreamer.io/")
+        (license license:bsd-2)))
+  #+END_SRC
+  #+latex: }
+
+* Dependency graph
+
+  \includegraphics[width=\textwidth]{livestreamer-graph.png}
+
+* Demo!
+
+  Emacs + Geiser
+
+* Other user interfaces
+
+  Besides the CLI, there’s also an Emacs interface, naturally.
+
+  Proof of concept web interface. (not in Guix core)
+
+* Demo!
+
+  Emacs
+
+* Importing packages
+
+  The =guix import= tool that can *automatically generate code
+  snippets* for packages found in foreign systems.
+
+  Supported systems include: PyPI, RubyGems, CPAN, Hackage, ELPA, and
+  CRAN.
+
+* Auto-updating
+
+  The =guix refresh= tool can automatically find the latest release of
+  certain software.
+
+  For example, Python packages can be updated by querying PyPI for
+  information on the latest release.
+
+* Demo!
+
+  =guix import=
+
+* Reproducible development environments
+
+  Getting the dependencies needed to create development environments
+  can be tough.
+
+  Many languages invent their own solution, but this is a general
+  problem.
+
+* Reproducible development environments
+
+  Guix has a tool for this: =guix environment=
+
+  Think of it like a language-agnostic version of Python’s
+  =virtualenv=.
+
+* Reproducible development environments
+
+  Environments can be *purified* via standard environment variables
+  or, for better isolation, Linux containers.
+
+  This allows developers to have confidence that potential
+  contributors will be able to build their software.
+
+* Demo!
+
+  =guix environment=
+
+* Full-system configuration
+
+  The Guix System Distribution supports a *consistent whole-system
+  configuration mechanism*.
+
+  All aspects of a system configuration are *declared* in a single
+  place.
+
+* Advantages
+
+  Easy to replicate configuration on different machines *without
+  resorting to additional tools* layered on top.
+
+  System upgrades are atomic and can be rolled back.
+
+* Example system configuration
+
+  #+latex: \tiny{
+  #+BEGIN_SRC scheme
+    (operating-system
+      (host-name "izanagi")
+      (timezone "America/New_York")
+      (locale "en_US.UTF-8")
+      (bootloader (grub-configuration (device "/dev/sda")))
+      (file-systems (cons (file-system
+                            (device "root")
+                            (title 'label)
+                            (mount-point "/")
+                            (type "ext4"))
+                          %base-file-systems))
+      (users (list (user-account
+                    (name "dave")
+                    (comment "David Thompson")
+                    (group "users")
+                    (supplementary-groups '("wheel" "netdev" "audio"
+                                            "video" "cdrom"))
+                    (home-directory "/home/dave"))))
+      (packages (cons* adwaita-icon-theme avahi dbus gnome-terminal
+                       htop less man-db nss-certs openssh pulseaudio
+                       wicd unzip rsync xfce
+                       %base-packages))
+      (services %desktop-services)
+      (name-service-switch %mdns-host-lookup-nss))
+  #+END_SRC
+  #+latex: }
+
+* Service graph
+
+  \includegraphics[width=\textwidth]{service-graph.png}
+
+* Demo!
+
+  =guix system vm=
+
+* Project status
+
+  - Full-featured package manager
+  - 3,000 packages, 4 platforms
+  - Guix System Distribution in beta
+  - Binaries at http://hydra.gnu.org
+  - Variety of useful tools
+
+* Project status
+
+  \includegraphics[width=\textwidth]{stats.png}
+
+  \center\url{https://www.openhub.net/p/gnuguix}
+
+* Project status
+
+  \begin{center}
+  \includegraphics[width=\textwidth]{contributor-graph.png}
+  \end{center}
+
+* The people have spoken
+
+  \begin{center}
+  \includegraphics[width=4cm]{awesome-rating.png}
+  \end{center}
+
+* Project status
+
+  \approx200–500 new packages per release.  *More needed!*
+
+* Future
+
+  I intend to focus on:
+
+  - A cluster deployment tool: =guix deploy=
+  - Improved support for GuixSD containers
+
+* Future
+
+  More generally:
+
+  - Stronger build farm
+  - More packages that are reproducible
+  - GNOME
+  - LVM
+  - Encrypted root for everyone
+
+* Join us!
+
+  - Use Guix on top of your existing distro
+  - Use the distribution
+  - Add new packages or upgrade existing ones
+  - Write system services
+  - Add new translations
+  - Tell us your ideas!
+
+* Join us!
+
+  We are currently collecting donations via the FSF to purchase new
+  servers for our build farm!
+
+  Since mid-Decemeber, $8,200 USD has been raised.
+
+  https://gnu.org/software/guix/donate/
+
+* Join us!
+
+  Chat with us in the =#guix= channel on Freenode or on the
+  =guix-devel@gnu.org= and =help-guix@gnu.org= mailing lists.
+
+* LibrePlanet 2016
+
+  Christopher Webber of the GNU MediaGoblin project and myself will be
+  co-presenting “Solving the Deployment Crisis with GNU Guix” at
+  LibrePlanet 2016 on March 19th or 20th.
+
+  Visit https://libreplanet.org/2016 for full details.
+
+* Thank you!
+
+  Visit https://gnu.org/software/guix for source code, documentation,
+  past talks, etc.
+
+  \begin{center}
+    \huge{Questions?}
+  \end{center}
+
+* Legal
+
+  © 2016 David Thompson =<davet@gnu.org>=
+
+  This presentation is licensed under the Creative Common Attribute
+  Share-Alike 4.0 International license.
+
+  GNU Guix and GuixSD logo, GFDL, http://gnu.org/s/guix/graphics
+
+  Copyright of other images included in this document is held by their
+  respective owners.
+
+* Footnotes
+
+[fn:1] “How to be a good host: miniKanren as a case study”
+https://www.youtube.com/watch?v=b9C3r3dQnNY
+
+[fn:2] http://curlpipesh.tumblr.com/
+
+[fn:3] “Your big data toolchain is a big security risk!”
+http://www.vitavonni.de/blog/201504/2015042601-big-data-toolchains-are-a-security-risk.html
+
+[fn:4] “The sad state of sysadmin in the age of containers”
+http://www.vitavonni.de/blog/201503/2015031201-the-sad-state-of-sysadmin-in-the-age-of-containers.html
+
+[fn:5] http://www.banyanops.com/blog/analyzing-docker-hub/
+
+[fn:6] “Let’s Package jQuery: A Javascript Packaging Dystopian Novella” http://dustycloud.org/blog/javascript-packaging-dystopia/
+
+[fn:7] “ownCloud and distribution packaging” http://lwn.net/Articles/670566/
+
+[fn:8] http://nixos.org/nix/
+
+[fn:9] https://reproducible-builds.org/