#+TITLE: Guix(SD) #+AUTHOR: Christopher Allan Webber #+EMAIL: cwebber@dustycloud.org #+DATE: 2015-09-30 Wed #+OPTIONS: toc:nil ^:nil # TODO: Cool Guix image here # From here: # [[file:~/docs/guix-talks/talks/ots-2015/images/guix-logo.pdf]] * Introduction ** What's Guix? Not just "Yet Another Package Manager / Distro!" https://www.gnu.org/software/guix/ *** A functional package manager "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! *** Based on Nix # TODO: Nix logo here - 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 *** Free as in Freedom - 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. *** (Other) features - 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 1 is on Django 2.X whereas the old version 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 *** "The git of package management"???? 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 1434053151 -0500 : committer David Thompson 1434416170 -0400 : : examples: Add Conway's Game of Life. : : * examples/life.scm: New file. : * examples/Makefile.am (nobase_dist_examples_DATA): Add it. - All these "hash" references are (kind of) "content addressed storage" - 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...) ** What's GuixSD? - Now take Guix, and make it a distro! ** Motivations *** Has this ever happened to you? - My system failed mid-upgrade and now it's BORKED - Oh no I thought this upgrade was okay but now it isn't - One Package Manager Per Child Language - 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!) *** Personal motivations But maybe most critically for me: - Network freedom is near-impossible current state of deployability - Tired of * Prereq: Understanding "functional" Or: "I'm not trying to trick you into learning monads, I promise!" ** Understanding pure functions *** A definition of pure functions : =================================================================== : 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 output!) : =================================================================== 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...) *** Your prescription: no side effects! "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 beeps and boops - No mutating data that is accessed elsewhere *** Functions vs procedures #+BEGIN_SRC python # A function def greet(name): return "Hello, " + name # A procedure (NOT a function) def greet_printer(name): print("Hello, " + name) #+END_SRC Printing to the screen is a "side effect" *** This is as far from a pure function as you can get #+BEGIN_SRC python def write_site_status_to_file(our_file, config): # mutation! urls = config.pop("urls") # iteration! for url in urls: # time-dependent variables! current_time = datetime.datetime.now().isoformat() # File IO! our_file.write("\n--Site status at %s--\n" % current_time) # Network IO! site_status = urlopen(url).read() # More file IO! our_file.write(site_status) #+END_SRC ** A purely functional program can't do anything #+BEGIN_QUOTE ... Functional programs can't really do anything, since they can't have /side effects/. As Simon Peyton Jones, a well-known functional programmer, likes to say, "All you can do without side effects is push a button and watch the box get hot for a while." (Which isn't technically true, since even the box getting hot is a side effect.) -- Land of Lisp, p. 300 #+END_QUOTE ** So... what does it give you? That sounds like a lot of "can't", but functional programming gives you some amazing properties: - GUARANTEED reproducibility. By definition! - Concurrent programming is easy. No mutation means no locking! - Most of the hard bugs vanish (Ever heard of a heisenbug?) - Game engines which can "scrub" back and forth in time! Debug by setting that game to 20 seconds ago! (Elm and Sly) - Memoization means caching with /no/ cache invalidation challenges - Optimized "immutable" datastructures are cooooooooool - And much, much more Unfortunately, this isn't a functional programming talk! (I recommend reading Land of Lisp for a great explaination of where functional programming is awesome, applied to game AI!) ** Functional programming strategy 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. * Guix: a functional package manager ** Understanding pure functional packaging *** The general picture *** What will we get? *** What ** Exploring a little install *** Run an install command! #+BEGIN_SRC sh guix package -i extremetuxracer #+END_SRC Now let's run it! #+BEGIN_SRC sh etr #+END_SRC *** Where'd that package go? Let's look in the "store": : ls /gnu/ ** So what does a Guix package look like? How about a nice game of [[file:~/devel/guix/gnu/packages/games.scm::(define-public%20chess][chess]]? ** How deep does it go? ** Multiple profiles! ** What does writing a package look like? ** Guix is a lot like Git ** GUI alternatives? *** You meant emacs right? *** guix-web *** .~~@YOUR GUI HERE!@~~. * GuixSD: a functional system distribution ** Describe your system and go ** Run it in a VM! On a container! * Cool demonstrations * Guile as a killer feature This is where Guix diverges from Nix ** What's Guile? # TODO: New Guile homepage screenshot here ** How much of Guix is written in Guile? ** What can we do here? ** How does this compare against Nix? ** A word against "turing tarpits" * Wrapping up ** Guix is "The Right Thing", but "right thing" != success Avoiding a "Worse is Better" type fate, and other analyses here ** Other conclusions ** Blah blah thanks for coming