diff options
Diffstat (limited to 'website')
13 files changed, 68 insertions, 68 deletions
diff --git a/website/posts/back-from-the-european-lisp-symposium.sxml b/website/posts/back-from-the-european-lisp-symposium.sxml index 648e122..3ecc2b4 100644 --- a/website/posts/back-from-the-european-lisp-symposium.sxml +++ b/website/posts/back-from-the-european-lisp-symposium.sxml @@ -8,7 +8,7 @@ (p "The " (a (@ (href "http://www-sop.inria.fr/members/Manuel.Serrano/conferences/els13.html")) "European Lisp Symposium") - " (ELS) is over now, and it\x92s been pleasant experience: thoughtful discussions, beautiful city, and parentheses all around. Thanks to all the Lispers and Schemers who made it to ELS for the friendly atmosphere!" + " (ELS) is over now, and it’s been pleasant experience: thoughtful discussions, beautiful city, and parentheses all around. Thanks to all the Lispers and Schemers who made it to ELS for the friendly atmosphere!" (br)) (p "The slides of the talk I gave on the design and implementation of Guix are " (a (@ (href "http://www.gnu.org/software/guix/guix-els-20130603.pdf")) diff --git a/website/posts/emacs-as-a-general-purpose-package-manager.sxml b/website/posts/emacs-as-a-general-purpose-package-manager.sxml index e2ea5c3..fdbdbd1 100644 --- a/website/posts/emacs-as-a-general-purpose-package-manager.sxml +++ b/website/posts/emacs-as-a-general-purpose-package-manager.sxml @@ -24,7 +24,7 @@ ", the beloved Guile/Emacs interface and development environment, to communicate with the underlying Guile process. That Guile process, in turn, simply uses Guix and " (a (@ (href "http://www.gnu.org/software/guix/manual/html_node/Package-Modules.html")) "the whole distribution") - " as libraries\x97the goodness of embedding the " + " as libraries—the goodness of embedding the " (a (@ (href "http://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html")) "packaging DSL") " in a general-purpose language." diff --git a/website/posts/gnome-in-guixsd.sxml b/website/posts/gnome-in-guixsd.sxml index 1a3c3d6..9663b9f 100644 --- a/website/posts/gnome-in-guixsd.sxml +++ b/website/posts/gnome-in-guixsd.sxml @@ -5,19 +5,19 @@ (date unquote (make-date 0 0 0 0 23 3 2016 3600)) (content div - (p "It\x92s a feature that many users were waiting for: proper " + (p "It’s a feature that many users were waiting for: proper " (a (@ (href "https://www.gnome.org/")) "GNOME") - " support in GuixSD. Good news: the forthcoming Guix and GuixSD release will give you exactly that! Don\x92t miss the obligatory " + " support in GuixSD. Good news: the forthcoming Guix and GuixSD release will give you exactly that! Don’t miss the obligatory " (a (@ (href "https://www.gnu.org/software/guix/screenshots/0.9.1/gnome-totem-epiphany.png")) "screenshot") "!" (br)) - (p "You would think adding GNOME is routine distro work involving a lot of packaging and bits of plumbing that\x92s already been done a hundred times, which is probably true! Yet, adding GNOME support turned out to be interesting in many ways: it\x92s a good test for GuixSD\x92s declarative operating system configuration framework, it\x92s a way to formalize how this whole software stack fits together, and it\x92s been an insightful journey into GNU/Linux desktop plumbing!" + (p "You would think adding GNOME is routine distro work involving a lot of packaging and bits of plumbing that’s already been done a hundred times, which is probably true! Yet, adding GNOME support turned out to be interesting in many ways: it’s a good test for GuixSD’s declarative operating system configuration framework, it’s a way to formalize how this whole software stack fits together, and it’s been an insightful journey into GNU/Linux desktop plumbing!" (br)) (p "Of course, a lot of software needs to be packaged to begin with. This had been on-going for some time, culminating with the addition of a " (a (@ (href "https://www.gnu.org/software/guix/packages/#gnome")) "gnome meta-package") - " thanks to the hard work of ??? (Sou Bunnbu) and other hackers. On the way, we added " + " thanks to the hard work of 宋文武 (Sou Bunnbu) and other hackers. On the way, we added " (a (@ (href "https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00173.html")) "an auto-updater for GNOME packages") ", because all these package recipes need love." @@ -25,11 +25,11 @@ (p "The more interesting parts were system integration. Modern GNOME/Freedesktop environments rely on a number of daemons, most of which talk over " (a (@ (href "https://www.freedesktop.org/wiki/Software/dbus/")) "D-Bus") - ", and extending each other\x92s functionality: udev, udisks, upower, colord, geoclue, and polkit, to name a few. Being able to " + ", and extending each other’s functionality: udev, udisks, upower, colord, geoclue, and polkit, to name a few. Being able to " (em "compose") " all these system services was one of the driving use cases behind " (a (@ (href "https://savannah.gnu.org/forum/forum.php?forum_id=8412")) - "the design of GuixSD\x92s new service composition framework") + "the design of GuixSD’s new service composition framework") ". With this design, we knew we were able to have fine control over the " (a (@ (href "https://www.gnu.org/software/guix/manual/html_node/Service-Composition.html")) "service composition graph") @@ -40,7 +40,7 @@ "GNU Shepherd") " and not systemd as its init system, we needed a way to provide the " (a (@ (href "https://freedesktop.org/wiki/Software/systemd/logind/")) - "\x93logind\x94") + "“logind”") " functionality that systemd implements, and which allows GNOME to know about " (a (@ (href "https://www.freedesktop.org/wiki/Software/systemd/multiseat/")) "users, sessions, and seats") @@ -51,8 +51,8 @@ "extracting") " logind from systemd, leading to " (a (@ (href "https://github.com/wingo/elogind")) - "\x93elogind\x94") - ". At this point, we had this daemon that could keep track of logged-in users and active sessions, and which GNOME could talk to over D-Bus\x85 provided all the relevant " + "“elogind”") + ". At this point, we had this daemon that could keep track of logged-in users and active sessions, and which GNOME could talk to over D-Bus… provided all the relevant " (a (@ (href "http://www.linux-pam.org/")) "PAM services") " would use the pam_elogind module so that elogind knows when a user logs in and out, as Andy " @@ -75,7 +75,7 @@ "cross-cutting modules") ". At last, we had proper logind support! " (br)) - (p "At this point, the brave could start using GNOME on GuixSD but would soon realize that, for example, the \x93power off\x94 button wouldn\x92t have the desired effect, or that changing a laptop\x92s backlight wouldn\x92t work because " + (p "At this point, the brave could start using GNOME on GuixSD but would soon realize that, for example, the “power off” button wouldn’t have the desired effect, or that changing a laptop’s backlight wouldn’t work because " (a (@ (href "https://www.freedesktop.org/wiki/Software/polkit/")) "polkit") ", the daemon that allows unprivileged users to perform privileged operations like that one, was " @@ -85,7 +85,7 @@ (br)) (p "You would think you can finally change the brightness of your screen, but no! Turns out that polkit would " (a (@ (href "https://lists.gnu.org/archive/html/guix-devel/2016-02/msg01170.html")) - "refuse to run gnome-setting-daemon\x92s backlight helper program") + "refuse to run gnome-setting-daemon’s backlight helper program") " because " (a (@ (href "https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00247.html")) "elogind happened to fail to map PIDs to sessions") @@ -96,7 +96,7 @@ "GNOME suspending right after it wakes up from suspend") ", failure to start in QEMU, or " (a (@ (href "https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00690.html")) - "the lack of GNOME\x92s favorite font") + "the lack of GNOME’s favorite font") ". Well, it seems that all these are gone now!" (br)) (p "GuixSD users can now enable GNOME by adding " diff --git a/website/posts/gnu-guix--guixsd-0.10.0-released.sxml b/website/posts/gnu-guix--guixsd-0.10.0-released.sxml index a79b26b..1a78960 100644 --- a/website/posts/gnu-guix--guixsd-0.10.0-released.sxml +++ b/website/posts/gnu-guix--guixsd-0.10.0-released.sxml @@ -18,9 +18,9 @@ "from binaries") "." (br)) - (p "It\x92s been almost 5 months since the previous release, and many things happened! The highlights include:" + (p "It’s been almost 5 months since the previous release, and many things happened! The highlights include:" (br)) - (ul (li "Our \x93grafting\x94 mechanism for " + (ul (li "Our “grafting” mechanism for " (a (@ (href "https://www.gnu.org/software/guix/manual/html_node/Security-Updates.html")) "security updates") " has been fixed to be generally applicable. Read " diff --git a/website/posts/gnu-guix-and-guixsd-0.11.0-released.sxml b/website/posts/gnu-guix-and-guixsd-0.11.0-released.sxml index 83eea8b..ce579f1 100644 --- a/website/posts/gnu-guix-and-guixsd-0.11.0-released.sxml +++ b/website/posts/gnu-guix-and-guixsd-0.11.0-released.sxml @@ -19,7 +19,7 @@ "from binaries") ". " (br)) - (p "It\x92s been 4 months since the previous release, during which 70 people contributed code and packages. The highlights include:" + (p "It’s been 4 months since the previous release, during which 70 people contributed code and packages. The highlights include:" (br)) (ul (li "New GuixSD system services, including an " (a (@ (href "https://www.gnu.org/software/guix/manual/html_node/Scheduled-Job-Execution.html")) diff --git a/website/posts/gnu-guix-talk-in-rennes-france-november-9th.sxml b/website/posts/gnu-guix-talk-in-rennes-france-november-9th.sxml index 43ee035..dc4b23e 100644 --- a/website/posts/gnu-guix-talk-in-rennes-france-november-9th.sxml +++ b/website/posts/gnu-guix-talk-in-rennes-france-november-9th.sxml @@ -11,7 +11,7 @@ "in Rennes, France, on November 9th") ". The event is organized by the three local free software and hacker organizations:" (br)) - (p (em " \x93It used to work perfectly, then I upgraded something, and somehow\x85\x94 Sounds like a déjà vu? Sometimes feel like software deployment is unpredictable? Dissatisfied with Dockerfiles, Vagrantfiles, and co? Ever wondered if you can trust your compiler or the integrity of those binary packages you have downloaded?") + (p (em " “It used to work perfectly, then I upgraded something, and somehow…” Sounds like a déjà vu? Sometimes feel like software deployment is unpredictable? Dissatisfied with Dockerfiles, Vagrantfiles, and co? Ever wondered if you can trust your compiler or the integrity of those binary packages you have downloaded?") (br)) (p (em "This talk introduces GNU Guix, a package manager that implements the functional package management paradigm pioneered by " (a (@ (href "http://nixos.org/nix")) "Nix") diff --git a/website/posts/guix-starts-fundraising-campaign-with-support-from-the-fsf.sxml b/website/posts/guix-starts-fundraising-campaign-with-support-from-the-fsf.sxml index 7958a8d..2a60f51 100644 --- a/website/posts/guix-starts-fundraising-campaign-with-support-from-the-fsf.sxml +++ b/website/posts/guix-starts-fundraising-campaign-with-support-from-the-fsf.sxml @@ -10,15 +10,15 @@ (p "The GNU\xa0Guix project is glad to announce its first fundraising campaign, supported by the Free Software Foundation (FSF). As the FSF " (a (@ (href "https://www.fsf.org/blogs/community/fsf-announces-support-for-gnu-guix")) "announced today") - ", the campaign\x92s primary goal is to help increase the capacity of the project\x92s build farm. We believe Guix offers a great tool set to increase the freedom and autonomy of computer users, and we are excited that the FSF supports the project!" + ", the campaign’s primary goal is to help increase the capacity of the project’s build farm. We believe Guix offers a great tool set to increase the freedom and autonomy of computer users, and we are excited that the FSF supports the project!" (br)) (p "Until now, the build farm behind hydra.gnu.org had been working on hardware and hosting " (a (@ (href "https://www.gnu.org/software/guix/donate/")) "generously provided") - " by several organizations and individuals\x97thank you! To cope with the growing number of " + " by several organizations and individuals—thank you! To cope with the growing number of " (a (@ (href "https://www.gnu.org/software/guix/packages/")) "packages") - " and users, we felt that the time has come to call to the community to strengthen the project\x92s infrastructure. Our first action will be to change the build farm\x92s front-end, which orchestrates builds and " + " and users, we felt that the time has come to call to the community to strengthen the project’s infrastructure. Our first action will be to change the build farm’s front-end, which orchestrates builds and " (a (@ (href "http://www.gnu.org/software/guix/manual/html_node/Substitutes.html")) "distributes binaries") ". Next we want to add more build machines, with two goals in mind: being able to quickly test changes that trigger lots of rebuilds, and being able to identify " diff --git a/website/posts/guixsd-system-tests.sxml b/website/posts/guixsd-system-tests.sxml index 15146b6..07c3152 100644 --- a/website/posts/guixsd-system-tests.sxml +++ b/website/posts/guixsd-system-tests.sxml @@ -5,14 +5,14 @@ (date unquote (make-date 0 0 0 0 28 6 2016 7200)) (content div - (p "From its inception, Guix has had a thorough test suite\x97something that\x92s not only reassuring, but also the thing that allows for fearless evolution of the code. That we didn\x92t have this safety net when hacking on the whole operating system, GuixSD, made it uncomfortable and more risky. We are now addressing the problem with the introduction of " + (p "From its inception, Guix has had a thorough test suite—something that’s not only reassuring, but also the thing that allows for fearless evolution of the code. That we didn’t have this safety net when hacking on the whole operating system, GuixSD, made it uncomfortable and more risky. We are now addressing the problem with the introduction of " (em "system tests") ", closing one of the major roadblocks towards 1.0." (br)) (p "Before going into details, let me recap the sorts of testing that already occurred in Guix land." (br)) (h4 "Unit tests") - (p "Guix\x92s " + (p "Guix’s " (a (@ (href "http://git.savannah.gnu.org/cgit/guix.git/tree/tests")) "test suite") " currently contains almost 600 " @@ -27,7 +27,7 @@ (br)) (p "Since Guix provides Scheme modules for use " (a (@ (href "https://www.gnu.org/software/guix/manual/html_node/G_002dExpressions.html")) - "both in the package management front-end and on the \x93build side\x94") + "both in the package management front-end and on the “build side”") ", the latter is also tested. This includes part of the " (a (@ (href "https://www.gnu.org/software/guix/manual/html_node/Build-Systems.html")) "build systems") @@ -50,7 +50,7 @@ "functional packaging model") "." (br)) - (p "Additionally, our policy is to always run each package\x92s test suite (typically \x93make check\x94) as part of its build process, unless there is a serious technical obstacle to doing that. That way, we can, and do catch integration issues, incompatibilities, and plain bugs before they hit users." + (p "Additionally, our policy is to always run each package’s test suite (typically “make check”) as part of its build process, unless there is a serious technical obstacle to doing that. That way, we can, and do catch integration issues, incompatibilities, and plain bugs before they hit users." (br)) (h4 "System tests") (p "So far, so good. Now, what about GuixSD itself? GuixSD did not have an automated test suite until now. What it did have, though, is the ability to instantiate an operating system in a virtual machine (VM) or in a container. You would write your " @@ -63,23 +63,23 @@ (p "This " (a (@ (href "https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-system.html#Invoking-guix-system")) "gives you a script to launch a VM") - " running an instance of the OS declared in \x91my-config.scm\x92. Already pretty convenient! And indeed, even more so back in the days when we were eating a fair amount of dog food. In fact, that\x92s how we ate our " + " running an instance of the OS declared in ‘my-config.scm’. Already pretty convenient! And indeed, even more so back in the days when we were eating a fair amount of dog food. In fact, that’s how we ate our " (a (@ (href "https://savannah.gnu.org/forum/forum.php?forum_id=7506")) "first") (a (@ (href "https://savannah.gnu.org/forum/forum.php?forum_id=7737")) "dog food dishes") ", and the VM infrastructure was the fork and knife that made it more tolerable." (br)) - (p "So what could we test exactly? Roughly, we want to test that the instantiated system behaves according to the source \x91operating-system\x92 declaration: that user accounts are all there, that system services are running as expected, that all of the configuration is taken into account." + (p "So what could we test exactly? Roughly, we want to test that the instantiated system behaves according to the source ‘operating-system’ declaration: that user accounts are all there, that system services are running as expected, that all of the configuration is taken into account." (br)) (p "To do that, we need to run the system under test in a VM, but we also need to instrument it. We use " (a (@ (href "http://qemu.org")) "QEMU") " to run our VMs, and QEMU along with the Linux virtio-serial module nicely supports communication between the guest operating system and the host, a strategy also used by " (a (@ (href "https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/test-driver/Machine.pm")) - "NixOS\x92 test driver") + "NixOS’ test driver") ". Concretely, we define a " (a (@ (href "http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/marionette.scm")) - "\x93marionette\x94") + "“marionette”") (a (@ (href "http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/tests.scm#n129")) "service") ", which hooks a Guile " @@ -89,22 +89,22 @@ (br)) (p "Now we can write build processes (" (a (@ (href "https://www.gnu.org/software/guix/manual/html_node/Derivations.html")) - "aka. \x93derivations\x94") + "aka. “derivations”") ") that will:" (br)) (ol (li "instantiate an instrumented variant of the operating system configuration we want to test in a VM image;\n") (li "spawn the VM, run a series of tests on the guest OS, and return the test results.\n")) (p "Thus, a system test to make sure the " (a (@ (href "https://www.gnu.org/software/guile/manual/html_node/System-Identification.html#index-scm_005funame")) - "\x91uname\x92") + "‘uname’") " system call returns something that matches the OS declaration looks like this:" (br)) (div (@ (class "example")) - (pre "(define (run-test)\n (define os\n ;; The declaration of the OS we want to instantiate and test.\n ;; Calling 'marionette-operating-system' instruments it.\n (marionette-operating-system\n (operating-system\n (host-name \"komputilo\")\n (timezone \"Europe/Berlin\")\n (locale \"en_US.UTF-8\")\n\n (bootloader (grub-configuration (device \"/dev/sdX\")))\n (file-systems %base-file-systems))))\n\n ;; Compute the script to run OS in a VM.\n (mlet %store-monad ((run (system-qemu-image/shared-store-script\n os #:graphic? #f)))\n (define test\n ;; The actual test. Here \x93#~\x94 is like \x93quote\x94, allowing us\n ;; to describe code to run in the build environment; it\x92s a\n ;; \x93g-expression.\x94\n #~(begin\n (use-modules (gnu build marionette)\n (srfi srfi-64)\n (ice-9 match))\n\n (define marionette\n\t ;; Spawn the VM that runs the declared OS.\n (make-marionette (list #$run)))\n\n (mkdir #$output)\n (chdir #$output)\n\n (test-begin \"basic\")\n\n (test-assert \"uname\"\n\t ;; Call the \x91uname\x92 Scheme function in the guest.\n\t ;; In the host, make sure its result (a vector) matches\n\t ;; our OS declaration above.\n (match (marionette-eval '(uname) marionette)\n (#(\"Linux\" host-name version _ architecture)\n (and (string=? host-name\n #$(operating-system-host-name os))\n (string-prefix? #$(package-version\n (operating-system-kernel os))\n version)\n (string-prefix? architecture %host-type)))))\n\n (test-end)\n (exit (= (test-runner-fail-count (test-runner-current)) 0))))\n\n ;; Turn the test into a buildable \x93derivation\x94.\n (gexp->derivation \"simple-test\" test\n #:modules '((gnu build marionette)))))\n")) - (p "There are interesting things going on here. First, while this is all Scheme code, there are in fact three tiers or strata of code at play here: the code that produces the OS declaration and the derivation, the build code of that derivation\x97the test\x97embodied in a " + (pre "(define (run-test)\n (define os\n ;; The declaration of the OS we want to instantiate and test.\n ;; Calling 'marionette-operating-system' instruments it.\n (marionette-operating-system\n (operating-system\n (host-name \"komputilo\")\n (timezone \"Europe/Berlin\")\n (locale \"en_US.UTF-8\")\n\n (bootloader (grub-configuration (device \"/dev/sdX\")))\n (file-systems %base-file-systems))))\n\n ;; Compute the script to run OS in a VM.\n (mlet %store-monad ((run (system-qemu-image/shared-store-script\n os #:graphic? #f)))\n (define test\n ;; The actual test. Here “#~” is like “quote”, allowing us\n ;; to describe code to run in the build environment; it’s a\n ;; “g-expression.”\n #~(begin\n (use-modules (gnu build marionette)\n (srfi srfi-64)\n (ice-9 match))\n\n (define marionette\n\t ;; Spawn the VM that runs the declared OS.\n (make-marionette (list #$run)))\n\n (mkdir #$output)\n (chdir #$output)\n\n (test-begin \"basic\")\n\n (test-assert \"uname\"\n\t ;; Call the ‘uname’ Scheme function in the guest.\n\t ;; In the host, make sure its result (a vector) matches\n\t ;; our OS declaration above.\n (match (marionette-eval '(uname) marionette)\n (#(\"Linux\" host-name version _ architecture)\n (and (string=? host-name\n #$(operating-system-host-name os))\n (string-prefix? #$(package-version\n (operating-system-kernel os))\n version)\n (string-prefix? architecture %host-type)))))\n\n (test-end)\n (exit (= (test-runner-fail-count (test-runner-current)) 0))))\n\n ;; Turn the test into a buildable “derivation”.\n (gexp->derivation \"simple-test\" test\n #:modules '((gnu build marionette)))))\n")) + (p "There are interesting things going on here. First, while this is all Scheme code, there are in fact three tiers or strata of code at play here: the code that produces the OS declaration and the derivation, the build code of that derivation—the test—embodied in a " (a (@ (href "https://www.gnu.org/software/guix/manual/html_node/G_002dExpressions.html")) "g-expression") - ", and code sent from the host to the guest VM via \x91marionette-eval\x92." + ", and code sent from the host to the guest VM via ‘marionette-eval’." (br)) (p "Using Scheme all the way means we can share code, use the right tools such as the " (a (@ (href "http://srfi.schemers.org/srfi-64/srfi-64.html")) @@ -118,13 +118,13 @@ ", which is often useful in system tests." (br)) (h4 "Status") - (p "Guix now includes the test infrastructure described above; running \x93make check-system\x94 runs all the currently defined tests. Currently we have " + (p "Guix now includes the test infrastructure described above; running “make check-system” runs all the currently defined tests. Currently we have " (a (@ (href "http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/tests/base.scm")) "tests for basic functionality") ". This includes making sure that all the system services declared are available and running. We have tests for specific system services such as the " (a (@ (href "https://www.gnu.org/software/mcron/")) "mcron") - " job scheduling daemon\x97inspired by your parents\x92 cron, but with a powerful Scheme interface\x97and " + " job scheduling daemon—inspired by your parents’ cron, but with a powerful Scheme interface—and " (a (@ (href "http://avahi.org/")) "Avahi") " and its " (a (@ (href "https://www.gnu.org/software/guix/manual/html_node/Name-Service-Switch.html")) diff --git a/website/posts/join-gnu-guix-for-gsoc.sxml b/website/posts/join-gnu-guix-for-gsoc.sxml index 7c8ae9b..9f40312 100644 --- a/website/posts/join-gnu-guix-for-gsoc.sxml +++ b/website/posts/join-gnu-guix-for-gsoc.sxml @@ -14,7 +14,7 @@ " (GSoC), and " (a (@ (href "https://www.gnu.org/software/guix")) "Guix") - " is participating under GNU\x92s umbrella." + " is participating under GNU’s umbrella." (br)) (p "We have collected project ideas for " (a (@ (href "https://libreplanet.org/wiki/Group:Guix/GSoC-2016")) diff --git a/website/posts/reproducible-and-user-controlled-software-environments-in-hpc-with-guix.sxml b/website/posts/reproducible-and-user-controlled-software-environments-in-hpc-with-guix.sxml index 66777d0..82e10c3 100644 --- a/website/posts/reproducible-and-user-controlled-software-environments-in-hpc-with-guix.sxml +++ b/website/posts/reproducible-and-user-controlled-software-environments-in-hpc-with-guix.sxml @@ -13,7 +13,7 @@ (a (@ (href "http://reppar.org/")) "RepPar") ", a workshop on reproducibility in parallel computing:" (br)) - (p " Support teams of high-performance computing (HPC) systems often find themselves between a rock and a hard place: on one hand, they understandably administrate these large systems in a conservative way, but on the other hand, they try to satisfy their users by deploying up-to-date tool chains as well as libraries and scientific software. HPC system users often have no guarantee that they will be able to reproduce results at a later point in time, even on the same system\x97software may have been upgraded, removed, or recompiled under their feet, and they have little hope of being able to reproduce the same software environment elsewhere. We present GNU Guix and the functional package management paradigm and show how it can improve reproducibility and sharing among researchers with representative use cases. " + (p " Support teams of high-performance computing (HPC) systems often find themselves between a rock and a hard place: on one hand, they understandably administrate these large systems in a conservative way, but on the other hand, they try to satisfy their users by deploying up-to-date tool chains as well as libraries and scientific software. HPC system users often have no guarantee that they will be able to reproduce results at a later point in time, even on the same system—software may have been upgraded, removed, or recompiled under their feet, and they have little hope of being able to reproduce the same software environment elsewhere. We present GNU Guix and the functional package management paradigm and show how it can improve reproducibility and sharing among researchers with representative use cases. " (br)) (p "The paper can be thought of as a followup to the recent " (a (@ (href "http://elephly.net/posts/2015-04-17-gnu-guix.html")) diff --git a/website/posts/reproducible-builds-a-means-to-an-end.sxml b/website/posts/reproducible-builds-a-means-to-an-end.sxml index 98abb97..4cee33b 100644 --- a/website/posts/reproducible-builds-a-means-to-an-end.sxml +++ b/website/posts/reproducible-builds-a-means-to-an-end.sxml @@ -11,35 +11,35 @@ (p "GNU Guix is committed to improving the freedom and autonomy of computer users. This obviously manifests in the fact that GuixSD is a " (a (@ (href "http://www.gnu.org/distros/free-system-distribution-guidelines.html")) "fully free distro") - ", and this is what GNU stands for. All the packages in Guix are built from source, including things like firmware where there is an unfortunate tendency to use pre-built binaries; that way, users can know what software they run. On the technical side, Guix also tries hard to empower users by making the whole system as hackable as possible, in a uniform way\x97making " + ", and this is what GNU stands for. All the packages in Guix are built from source, including things like firmware where there is an unfortunate tendency to use pre-built binaries; that way, users can know what software they run. On the technical side, Guix also tries hard to empower users by making the whole system as hackable as possible, in a uniform way—making " (a (@ (href "https://www.gnu.org/philosophy/free-sw.html")) "Freedom #1") " practical, à la Emacs." (br)) - (p "Guix provides pre-compiled binaries of software packages as a service to its users\x97these are " + (p "Guix provides pre-compiled binaries of software packages as a service to its users—these are " (a (@ (href "http://www.gnu.org/software/guix/manual/html_node/Substitutes.html")) "substitutes") - " for local builds. This is a convenient way to save time, but it could become a threat to users if they cannot establish that those substitutes are authentic\x97that their " + " for local builds. This is a convenient way to save time, but it could become a threat to users if they cannot establish that those substitutes are authentic—that their " (a (@ (href "http://www.gnu.org/licenses/gpl.html#section1")) "Corresponding Source") " really is what it claims to be." (br)) (h4 "Reproducible builds") - (p "We view \x93reproducible builds\x94 as a technical means to an end: that of guaranteeing user autonomy and safety. What matters here is that, if package build processes are reproducible, then users actually have a chance to " + (p "We view “reproducible builds” as a technical means to an end: that of guaranteeing user autonomy and safety. What matters here is that, if package build processes are reproducible, then users actually have a chance to " (em "verify") " that the substitutes (pre-compiled binaries) they download correspond to the source code that supposedly produced them." (br)) (p "Guix builds packages in a " (a (@ (href "http://www.gnu.org/software/guix/manual/html_node/Features.html")) "fully isolated environment") - " to maximize reproducibility\x97a crucial feature inherited from " + " to maximize reproducibility—a crucial feature inherited from " (a (@ (href "http://nixos.org/nix/")) "Nix") ". Thus, by construction, very few variations are possible between separate instances of a build environment; the set of files accessible in the environment, the host name, environment variables, locale, and so on are fully under control and cannot change. This eliminates a " (a (@ (href "https://reproducible-builds.org/docs/test-bench/")) "whole class of possible discrepancies") " between independent builds." (br)) - (p "The only things that may vary are the kernel, and the hardware. The most prominent example of how \x91hardware\x92 details can leak into a build process are timestamps: it\x92s unfortunately quite common for build processes to query the system clock and record it in build outputs. Eelco Dolstra, Andres Löh, and Nicolas Pierron described sources of non-determinism in their " + (p "The only things that may vary are the kernel, and the hardware. The most prominent example of how ‘hardware’ details can leak into a build process are timestamps: it’s unfortunately quite common for build processes to query the system clock and record it in build outputs. Eelco Dolstra, Andres Löh, and Nicolas Pierron described sources of non-determinism in their " (a (@ (href "https://nixos.org/~eelco/pubs/nixos-jfp-final.pdf")) "2010 JFP paper about NixOS") ", along with a study on how this affects packages of the distribution in practice. The " @@ -47,7 +47,7 @@ "Reproducible Debian") " project has since made a similar evaluation but at a larger scale, and with a larger number of independent builds, thereby providing more insight." (br)) - (p "Reproducible Debian has demonstrated one thing: contrary to what one might expect, sources of non-determinism are common in build processes. To eliminate the sources of non-determinism that remain in spite of the isolation techniques used in Nix and Guix, the most viable approach appears to be to fix upstream projects that suffer from these problems\x97one by one." + (p "Reproducible Debian has demonstrated one thing: contrary to what one might expect, sources of non-determinism are common in build processes. To eliminate the sources of non-determinism that remain in spite of the isolation techniques used in Nix and Guix, the most viable approach appears to be to fix upstream projects that suffer from these problems—one by one." (br)) (p "The " (a (@ (href "http://reproducible-builds.org")) @@ -80,7 +80,7 @@ " 0.9.0 version of GNU Guix provides a new command called " (a (@ (href "http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-challenge.html")) "guix challenge") - ". The command allows users to automatically compare the build results of their local builds against those served by one or more binary providers. It allows both to find out about non-reproducible builds\x97and indeed, has already " + ". The command allows users to automatically compare the build results of their local builds against those served by one or more binary providers. It allows both to find out about non-reproducible builds—and indeed, has already " (a (@ (href "https://lists.gnu.org/archive/html/guix-devel/2015-10/msg00728.html")) "proved") " to be " @@ -94,7 +94,7 @@ " (" (a (@ (href "https://www.gnu.org/software/guix/guix-rennes-20151109.pdf")) "slides") - "). We strongly believe in a future where the ability to authenticate distribution-provided binaries will be commonplace. Let\x92s build it!" + "). We strongly believe in a future where the ability to authenticate distribution-provided binaries will be commonplace. Let’s build it!" (br)) (h4 "About GNU Guix") (p (a (@ (href "http://www.gnu.org/software/guix")) diff --git a/website/posts/service-composition-in-guixsd.sxml b/website/posts/service-composition-in-guixsd.sxml index 0f5a4d4..b67e408 100644 --- a/website/posts/service-composition-in-guixsd.sxml +++ b/website/posts/service-composition-in-guixsd.sxml @@ -12,14 +12,14 @@ " of GNU\xa0Guix." (br)) (h4 "Declarative Configuration Management") - (p "GuixSD is not like your parents\x92 distro. Instead of fiddling with configuration files all around, or running commands that do so as a side effect, the system administrator " + (p "GuixSD is not like your parents’ distro. Instead of fiddling with configuration files all around, or running commands that do so as a side effect, the system administrator " (em "declares") " what the system will be like. This takes the form of an " (a (@ (href "https://www.gnu.org/software/guix/manual/html_node/Using-the-Configuration-System.html")) "operating-system declaration") ", which specifies all the details: file systems, user accounts, locale, timezone, system services, etc." (br)) - (p "If you\x92re familiar with it, this may remind you of what deployment tools like Ansible and Puppet provide. There is an important difference though: GuixSD takes a stateless\x97or \x93purely functional\x94\x97approach. This means that instantiating the system with " + (p "If you’re familiar with it, this may remind you of what deployment tools like Ansible and Puppet provide. There is an important difference though: GuixSD takes a stateless—or “purely functional”—approach. This means that instantiating the system with " (a (@ (href "https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-system.html")) "guix system") " always produces the same result, without modifying the current system state. This is what makes it possible to test new system configurations, roll-back to previous ones, and so on. The " @@ -51,12 +51,12 @@ "system service") " we want to add, possibly with several instances of a service, and have GuixSD do the right thing." (br)) - (p "Before 0.9.0, GuixSD had a narrow definition of what a \x93system service\x94 is. Each service in the operating-system configuration had to map to exactly one dmd service\x97" + (p "Before 0.9.0, GuixSD had a narrow definition of what a “system service” is. Each service in the operating-system configuration had to map to exactly one dmd service—" (a (@ (href "https://www.gnu.org/software/dmd")) "GNU dmd") - " is the init system of GuixSD. This would work well in many cases: an SSH server or a log-in daemon is indeed a service that dmd has to take care of, even a file system mount is an operation that can be usefully inserted into dmd\x92s service dependency graph." + " is the init system of GuixSD. This would work well in many cases: an SSH server or a log-in daemon is indeed a service that dmd has to take care of, even a file system mount is an operation that can be usefully inserted into dmd’s service dependency graph." (br)) - (p "However, this simple mapping failed to capture more complex service composition patterns. A striking example is \x93super-daemons\x94\x97daemons that can spawn other daemons, such as dbus-daemon or inetd. From the user viewpoint, it does not matter whether a daemon is started by dmd, or by dbus-daemon, or by inetd; this should be transparent. If it\x92s a D-Bus service, then dbus-daemon\x92s configuration file should be told about the service; if it\x92s an inetd service, then inetd.conf should be augmented accordingly; if it\x92s a dmd service, information on how to start and stop it should go to dmd\x92s configuration file. Unfortunately, the pre-0.9.0 services could not express such things." + (p "However, this simple mapping failed to capture more complex service composition patterns. A striking example is “super-daemons”—daemons that can spawn other daemons, such as dbus-daemon or inetd. From the user viewpoint, it does not matter whether a daemon is started by dmd, or by dbus-daemon, or by inetd; this should be transparent. If it’s a D-Bus service, then dbus-daemon’s configuration file should be told about the service; if it’s an inetd service, then inetd.conf should be augmented accordingly; if it’s a dmd service, information on how to start and stop it should go to dmd’s configuration file. Unfortunately, the pre-0.9.0 services could not express such things." (br)) (p "Worse, this approach did not capture the more general pattern of " (em "service extension") @@ -71,7 +71,7 @@ " can be extended with new rules and actions, the " (a (@ (href "http://www.linux-pam.org/")) "Pluggable authentication module system (PAM)") - " can be extended with new services, and so on. At that point it was clear that GuixSD\x92s naive approach wouldn\x92t scale." + " can be extended with new services, and so on. At that point it was clear that GuixSD’s naive approach wouldn’t scale." (br)) (h4 "Composing System Services") (p "The lesson learned from these observations is that system services " @@ -79,12 +79,12 @@ " each other in various way. The new " (a (@ (href "https://www.gnu.org/software/guix/manual/html_node/Service-Composition.html")) "service composition framework") - " is built around this model: \x93system services\x94, broadly defined, can extend each other, and services and their \x93extends\x94 relationships form a graph. The root of the graph is the operating system itself." + " is built around this model: “system services”, broadly defined, can extend each other, and services and their “extends” relationships form a graph. The root of the graph is the operating system itself." (br)) - (p "We can see that this pattern applies to services that are not daemons. PAM is one such example. Accounts are another example: GuixSD provides an \x93account service\x94 that can be extended with new user accounts or groups; for example, the " + (p "We can see that this pattern applies to services that are not daemons. PAM is one such example. Accounts are another example: GuixSD provides an “account service” that can be extended with new user accounts or groups; for example, the " (a (@ (href "https://www.gnu.org/software/guix/manual/html_node/Networking-Services.html#index-ntp_002dservice")) "Network time protocol (NTP) daemon") - " needs to run under the unprivileged \x93ntp\x94 user, so the NTP service extends the account service with an \x93ntp\x94 user account. Likewise, the \x93/etc\x94 service can be extended with new files to be added to /etc; the \x93setuid\x94 service can be extended with new programs to be made setuid-root. " + " needs to run under the unprivileged “ntp” user, so the NTP service extends the account service with an “ntp” user account. Likewise, the “/etc” service can be extended with new files to be added to /etc; the “setuid” service can be extended with new programs to be made setuid-root. " (a (@ (href "https://www.gnu.org/software/guix/manual/html_node/Service-Reference.html")) "See the manual") " for more examples." @@ -99,7 +99,7 @@ "guix system extension-graph") " command, for instance, takes an operating-system declaration and renders the extension graph in the Graphviz format, making it easy to inspect the OS configuration structure." (br)) - (p "The API makes it easy to see how services contributed to a specific service\x92s configuration. For instance, the following expression shows the PAM service as extended by other declared services:" + (p "The API makes it easy to see how services contributed to a specific service’s configuration. For instance, the following expression shows the PAM service as extended by other declared services:" (br)) (div (@ (class "example")) (pre "(fold-services (operating-system-services os) \n #:target-type pam-root-service-type)\n")) @@ -109,15 +109,15 @@ (pre "(fold-services (operating-system-services os) \n #:target-type etc-service-type)\n")) (p "This contrasts with the approach taken by " (a (@ (href "http://nixos.org/")) "NixOS") - ", GuixSD\x92s cousin, and described in this " + ", GuixSD’s cousin, and described in this " (a (@ (href "https://nixos.org/~eelco/pubs/nixos-jfp-final.pdf")) "2010 paper") - ". In NixOS, the whole system configuration is described in an \x93attribute set\x94\x97a list of key/value associations, similar to JavaScript objects or Python dictionaries. Each NixOS service is passed the whole system configuration, allowing it to inspect and change any part of it." + ". In NixOS, the whole system configuration is described in an “attribute set”—a list of key/value associations, similar to JavaScript objects or Python dictionaries. Each NixOS service is passed the whole system configuration, allowing it to inspect and change any part of it." (br)) (p "This form of " (a (@ (href "https://en.wikipedia.org/wiki/Ambient_authority")) "ambient authority") - " gives a lot of flexibility, but it makes it harder to reason about service composition\x97all a service implementation does is inspect, add, or modify attributes of the global configuration, which may or may not affect other services. The use of a loose key/value dictionary also prevents good error reporting; for instance, a typo in a service name may go undetected. Lastly, NixOS services are enabled by writing service.enable\xa0=\xa0true stanzas, which leads to complications for services that may have several instances, each with its own configuration." + " gives a lot of flexibility, but it makes it harder to reason about service composition—all a service implementation does is inspect, add, or modify attributes of the global configuration, which may or may not affect other services. The use of a loose key/value dictionary also prevents good error reporting; for instance, a typo in a service name may go undetected. Lastly, NixOS services are enabled by writing service.enable\xa0=\xa0true stanzas, which leads to complications for services that may have several instances, each with its own configuration." (br)) (h4 "Wrapping Up") (p "The new " diff --git a/website/posts/timely-delivery-of-security-updates.sxml b/website/posts/timely-delivery-of-security-updates.sxml index e5e5aec..c1eb307 100644 --- a/website/posts/timely-delivery-of-security-updates.sxml +++ b/website/posts/timely-delivery-of-security-updates.sxml @@ -25,12 +25,12 @@ ". What this means is that the the package graph in Guix is an immutable, " (a (@ (href "https://en.wikipedia.org/wiki/Persistent_data_structure")) "persistent data structure") - "\x97similar to a singly-linked list in a functional programming language, or to the " + "—similar to a singly-linked list in a functional programming language, or to the " (a (@ (href "http://eagain.net/articles/git-for-computer-scientists/")) "object graph in the Git version control system") "." (br)) - (p "A common difficulty with persistent data structures is the algorithmic complexity of updates\x97the computational cost of updating an arbitrary element of the data structure. For instance, to update the nth element of a singly-linked list, you first need to traverse and copy the n\xa0?\xa01 elements at the head of the list, then insert the new element and make it point to the tail of the list." + (p "A common difficulty with persistent data structures is the algorithmic complexity of updates—the computational cost of updating an arbitrary element of the data structure. For instance, to update the nth element of a singly-linked list, you first need to traverse and copy the n\xa0?\xa01 elements at the head of the list, then insert the new element and make it point to the tail of the list." (br)) (p "With the functional package management paradigm, the cost of updating a package is simple to understand: you need to rebuild the package itself, " (em "and all the packages that depend on it") @@ -39,26 +39,26 @@ " build from source, there is no way we can be using binaries that cannot be " (a (@ (href "https://savannah.gnu.org/forum/forum.php?forum_id=8407")) "rebuilt from their Corresponding Source") - ", breakage due to incompatible application binary interfaces (ABIs) is foreign to our users, we have a precise trail of the tools that produced binaries\x97that is, builds are " + ", breakage due to incompatible application binary interfaces (ABIs) is foreign to our users, we have a precise trail of the tools that produced binaries—that is, builds are " (a (@ (href "https://en.wikipedia.org/wiki/Referential_transparency")) - "\x93referentially transparent\x94") + "“referentially transparent”") ", and as a bonus, we get " (a (@ (href "https://www.gnu.org/software/guix/manual/html_node/Features.html")) "features") " such as transactional upgrades and rollbacks, peaceful coexistence of different variants of the same package, and more." (br)) - (p "But obviously, this update cost is very high when all you want is to deliver an important security update in a core package. Regarding yesterday\x92s update, " + (p "But obviously, this update cost is very high when all you want is to deliver an important security update in a core package. Regarding yesterday’s update, " (a (@ (href "http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-refresh.html")) "guix refresh -l openssl") " shows that 2,115 packages depend on OpenSSL. On top of that, Guix supports 4 architectures, so needless to say, rebuilding everything that depends on OpenSSL would take time. Sure, users do not have to wait for " (a (@ (href "http://www.gnu.org/software/guix/manual/html_node/Substitutes.html")) "pre-built binaries") - " and can instead build just what they need locally; in practice, they\x92d better have a powerful machine, though." + " and can instead build just what they need locally; in practice, they’d better have a powerful machine, though." (br)) (h4 "Grafting important updates") (p "A solution to this problem has been floating around for some time: the idea is to " (em "graft") - " important package updates onto packages that depend on it. That way, we would rebuild OpenSSL, but all we need to do for packages that depend on OpenSSL is to substitute the reference to the \x93broken\x94 OpenSSL with a reference to the security update, with the understanding that this substitution process is orders of magnitude cheaper than rebuilding packages, and faster than redownloading rebuilt packages." + " important package updates onto packages that depend on it. That way, we would rebuild OpenSSL, but all we need to do for packages that depend on OpenSSL is to substitute the reference to the “broken” OpenSSL with a reference to the security update, with the understanding that this substitution process is orders of magnitude cheaper than rebuilding packages, and faster than redownloading rebuilt packages." (br)) (p "Shea Levy had implemented a form of grafting " (a (@ (href "https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/replace-dependency.nix")) @@ -84,7 +84,7 @@ (h4 "Good news!") (p "This bug was finally addressed, " (a (@ (href "https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00009.html")) - "just in time for yesterday\x92s OpenSSL update") + "just in time for yesterday’s OpenSSL update") ". We have identified things to improve, but overall, it has worked pretty well. It has worked so well that we even experienced " (a (@ (href "http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22876#8")) "our first ABI break") |