01/02: website: Update draft post about the Guile guix-daemon.

[Christopher Baines]

cbaines pushed a commit to branch master
in repository guix-artwork.

commit d33bbe10634ff5c371e02018fc16a53dbd94ae0f
Author: Christopher Baines <mail@cbaines.net>
AuthorDate: Mon Oct 30 08:13:29 2023 +0000

    website: Update draft post about the Guile guix-daemon.
    
    * website/drafts/guile-guix-daemon-introduction.md: Update.
---
 website/drafts/guile-guix-daemon-introduction.md | 74 +++++++++++++-----------
 1 file changed, 41 insertions(+), 33 deletions(-)

diff --git a/website/drafts/guile-guix-daemon-introduction.md 
b/website/drafts/guile-guix-daemon-introduction.md
index 170ff55..6af8938 100644
--- a/website/drafts/guile-guix-daemon-introduction.md
+++ b/website/drafts/guile-guix-daemon-introduction.md
@@ -1,26 +1,29 @@
-title: Building a Guile guix-daemon
+title: A build daemon in Guile
 author: Christopher Baines
-tags:
+tags: Guix Daemon
 date: 2023-10-13 14:30:00
 ---
 
 When using Guix, you might be aware of the
 
[daemon](https://guix.gnu.org/en/manual/en/html_node/Setting-Up-the-Daemon.html).
 It runs in the background but it's a key component in Guix.  Whenever
-you've been using Guix to operate on the store, whether that's
-building something or downloading some substitutes, it's the daemon
-managing that operation.
+you've been using Guix to [operate on the 
store](https://guix.gnu.org/en/blog/2023/dissecting-guix-part-1-derivations/),
+whether that's building something or downloading some substitutes,
+it's the daemon managing that operation.
 
 The daemon also is a key part of the history of Guix.  The Guix
 project started mixing Guile with ideas from the Nix project, and the
-guix-daemon is a fork of the nix-dameon with some tweaks made over the
-years.  Rather than being implemented in Guile though, the daemon is
-implemented in C++.  Given the focus on Guile in Guix, this is
-unusual, and I believe it's made working on the daemon less desirable,
-especially since rewriting it in Guile has been discussed for many
-years now.
-
-# What would a Guile guix-dameon mean?
+`guix-daemon` is a fork of the `nix-daemon` with some tweaks made over
+the years.  Rather than being implemented in Guile though, the daemon
+is implemented in C++ with some helpers written in Guile.  Given the
+focus on Guile in Guix, this is unusual, and I believe it's made
+working on the daemon less desirable, especially since rewriting it in
+Guile has been discussed for many years now.  It has been the topic of
+a Google Summer of Code internship by Caleb Ristvedt back in 2017,
+which helped clarify implementation details and led to some
+[preliminary 
code](https://git.savannah.gnu.org/cgit/guix.git/log/?h=guile-daemon).
+
+# What would a build daemon in Guile bring?
 
 Guix already has code written in Guile for doing some of what the
 daemon does internally, so being able to use this Guile code inside
@@ -30,51 +33,56 @@ code.
 There isn't Guile code yet for everything the daemon does though, so
 getting to this point will make new exciting features easier to
 implement.  That could be things like making it easier to use Guix in
-environments where running the dameon in the usual way is inconvinient
+environments where running the daemon in the usual way is inconvenient
 or infeasible.  It may also help with portability, so help with
 running Guix on the Hurd and new architectures.
 
 As someone who's more experienced writing Guile than C++, I'm also
-hoping it'll generally make hacking on the dameon more accessible.
+hoping it'll generally make hacking on the daemon more accessible.
 This in turn might lead to new features.  For example, I think having
-a Guile guix-daemon will simplify implementing a way to jump in to a
-build and inspect the environment.
+a build daemon written in Guile will simplify implementing a way to
+jump in to a build and inspect the environment.
 
-With some [monetary support from 
NLNet](https://nlnet.nl/project/GuixDaemon-Guile/),
-I'm planning to focus for the next year on getting a Guile
-implementation of the guix-daemon written and adopted.
+With that in mind, I'm excited to announce that [support from
+NLNet](https://nlnet.nl/project/GuixDaemon-Guile/), will allow me to
+focus for the next year on getting a Guile implementation of the build
+daemon written and adopted.
 
 # A technical plan
 
 Building on the [recent 
discussion](https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00328.html)
-of this topic on the guix-devel mailing list, here's some technical
-thoughts on how I'm approaching this.
+of this topic on the `guix-devel@gnu.org` mailing list, here's some
+technical thoughts on how I'm approaching this.
 
 While I think there's a substantial amount of work to do, progress
 towards a Guile guix-daemon has already been made.  Given that things
 in Guix have probably changed since this work has happened, I plan to
 carefully review that existing work (most of which can be found on the
-`guile-daemon` branch) so that I can build upon it.
+[`guile-daemon` 
branch](https://git.savannah.gnu.org/cgit/guix.git/log/?h=guile-daemon)
 
-The priority for the Guile daemon is backwards compatability, so the
+The priority for the Guile daemon is backwards compatibility, so the
 plan is to allow switching between the C++ implementation and Guile
 implementation which any issues.  This'll require not making changes
 to the database schema, and generally doing things in a way which the
 current C++ daemon will understand.
 
-Like the build coordinator, I'm planning to make the daemon a single
-process using Guile Fibers for parallelism.  This is in contrast to
-the forking model using by the C++ daemon.  Even though it's not a
-priority to address feature issues with the current dameon, this
-approach might help to reduce database contention issues experienced
-with the current daemon, and allow for less locking, like not having
-the big GC lock for example.
-
-# Progress reports
+Like the [Guix Build 
Coordinator](https://guix.gnu.org/en/blog/2021/building-derivations-how-complicated-can-it-be/),
+I'm planning to make the daemon a single process using
+[Fibers](https://github.com/wingo/fibers) for concurrency.  This is in
+contrast to the forking model using by the C++ daemon.  Even though
+it's not a priority to address feature issues with the current daemon,
+this approach might help to reduce database contention issues
+experienced with the current daemon, and allow for less locking, like
+not having the big GC lock for example.
 
 I'm planning on publishing more blog posts as the project progress, so
 keep an eye on the Guix blog for future updates.
 
+# Acknowledgments
+
+Thanks to Simon Tournier and Ludovic Courtès for providing feedback on
+an earlier draft of this post.
+
 #### About GNU Guix
 
 [GNU Guix](https://guix.gnu.org) is a transactional package manager