[bug#68876] [PATCH maintenance] doc: guix-days-2024: Add notes from the infrastructure discussion.

[bug#68876] [PATCH maintenance] doc: guix-days-2024: Add notes from the infrastructure discussion.

[Jonathan Brielmaier via Guix-patches via]

* doc/guix-days-2024/infrastructure.md: New file.
---
 doc/guix-days-2024/infrastructure.md | 54 ++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)
 create mode 100644 doc/guix-days-2024/infrastructure.md

diff --git a/doc/guix-days-2024/infrastructure.md b/doc/guix-days-2024/infrastructure.md
new file mode 100644
index 0000000..a226041
--- /dev/null
+++ b/doc/guix-days-2024/infrastructure.md
@@ -0,0 +1,54 @@
+# Infrastructure
+
+## Why (ideal world)
+Areas where we could improve
+* serve the whole world web
+* redundancy
+* low maintenance (labour), but maintained, supported and observed
+* understood, documented and transparent
+* sustainable (financially and environmental)
+
+Other (okeish) things
+* secure and trusted
+* privacy considerations
+* scaleable
+* no cost to use
+* ethical
+* hosted or project owned hardware?
+* minimal but futureproof
+* provides (substitutes etc.)
+* efficient operations (bandwith)
+
+## What is our infrastructure
+* Build farms
+* Security and trust
+* Services
+  * QA
+  * issues/bug tracker
+  * git
+  * website
+  * package search
+  * mailing lists
+  * DNS
+  * IRC
+* substitutes
+* sysadmin
+  * updates
+  * software e.g. guix deploy
+  * support
+  * incident response
+* money, donations
+* location, hosting
+* virtual/physical hardware
+* state, storage
+
+## Ideas for improvement
+* mirroring
+  * use a CDN
+  * peer-to-peer hosting
+* equivalence ignoring reference hashes
+* substitutes
+  * storage for the Bordeaux build farm
+  * how long do we store them (scientific community "loves" substitutes for the past)
+  * prepare for the loss of MDC hosting (Berlin build farm)
+* pay/financially support people providing hardware
--
2.43.0

[bug#68876] [PATCH 1/2 maintenance] doc: guix-days-2024: Add notes about hurd session.

[Jonathan Brielmaier via Guix-patches via]

* doc/guix-days-2024/hurd.md: New file.
---
 doc/guix-days-2024/hurd.md | 48 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)
 create mode 100644 doc/guix-days-2024/hurd.md

diff --git a/doc/guix-days-2024/hurd.md b/doc/guix-days-2024/hurd.md
new file mode 100644
index 0000000..6d30a8d
--- /dev/null
+++ b/doc/guix-days-2024/hurd.md
@@ -0,0 +1,48 @@
+# Hurd + Guix
+
+* a few people in the room have run the Hurd before, even less on baremetal machines
+
+## Challenges
+* hurd on bare metal is difficult -> missing drivers
+* hurd supports only small disks (up to 100GB or so)
+* mach provides less then Linux kernel (file system, network etc) -> bootstrap is hard
+
+## Upstream status
+* 64bit (x86) support WIP
+* support for SMP (multi-threading)
+* port to aarch64 was started
+* Debian is mostly used for developing/integrated
+* activity increased a lot in the last 2 years (1 person -> couple contributors)
+* patches are pushed to glibc upstream
+
+## Guix on hurd
+* netdde (Linux kernels built for mach) -> Guix integration non-working
+* rumpdisk, disk drivers from NetBSD -> integrated in Guix already
+* rumpnet (for WiFi, network drivers etc.)
+* Guix with Hurd image available https://guix.gnu.org/en/download/latest/ including:
+  * netdde and rumpdisk included
+  * shepherd
+* glibc in core-updates contains many improvements for the Hurd
+  * 2.39 brings even more fixes, but maybe to late for core-updates
+* Bordeaux and Berlin build farms build packages for i586-gnu
+  * only master, core-updates currently disabled
+* `guix system reconfigure` broken on core-updates
+* rust@1.75 is cross-compilable from Linux
+* Mes builds on the hurd, stage0 misses support for mach+hurd
+  * so no bootstrap of Guix yet
+
+## Ideas
+* implement /gnu/store as a hurd translator
+* install Hurd via Guix installer
+* writing Guile bindings for Hurd translator
+* work closer together with Hurd devs
+* mach kernel can be "stretched" over network -> build "clusters"
+
+* how can users/devs start with Hurd
+  * run either via childhurd or Hurd VM
+  * childhurd allows offloading from Guix@Linux
+  * write a simple translator
+* what would help the Hurd ecosystem
+  * fix failing packages
+* empower users (non-admins) -> idea shared by Hurd and Guix
+  * "Linux+systemd+rust" is making things complex (high entry barrier)
--
2.43.0

[bug#68876] [PATCH 2/2 maintenance] doc: guix-days-2024: Add notes about CLI session.

[Jonathan Brielmaier via Guix-patches via]

* doc/guix-days-2024/cli.md: New file.

Co-authored-by: Adriel Dumas--Jondeau <leirda@disroot.org>
---
 doc/guix-days-2024/cli.md | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 doc/guix-days-2024/cli.md

diff --git a/doc/guix-days-2024/cli.md b/doc/guix-days-2024/cli.md
new file mode 100644
index 0000000..7d7808d
--- /dev/null
+++ b/doc/guix-days-2024/cli.md
@@ -0,0 +1,30 @@
+# CLI of Guix
+
+## How a perfect CLI would look like?
+* consistent
+* self-explaining
+* intuitive
+* mapping between API and CLI (e.g. easier REPL)
+* output can be parsed (composability)
+* flexible outputs
+* override defaults (aliases or extensions)
+* should be fast
+* auto completion, support for tabbing
+
+## What's the current state (good or bad)?
+* consistency in conventions (mostly)
+* fast tab completion
+* 39 top-level commands (`guix top-level-command`)
+* guix refresh / lint / style / challenge / download / hash are toplevel but really specific
+* Some options are not consistent between different commands
+  * `guix system list-generations` vs `guix pull --list-profile`
+* the `guix import` command is hard coded so we can't plug new importers with a channel for instance
+* the order of channel specification is important in regard to definitions (might not be the case anymore)
+* there's a common confusion between the name of the package and the name of the variable that holds the package
+
+## What we can improve
+* make guix extensions / modules more accessible
+  * there's something about that on a git repo of Andreas
+* package name writing differs between CLI and code (e.g. "glibc:debug" vs glibc `("debug"))
+* `guix shell --development spec` should accept a = sign (`guix shell --development=spec`)
+* Having a equivalent of the CLI example for the REPL in documentation
--
2.43.0

bug#68876: [PATCH maintenance] doc: guix-days-2024: Add notes from the infrastructure discussion.

[Ludovic Courtès]

Hello comrades!

Jonathan Brielmaier <jonathan.brielmaier@web.de> skribis:

> * doc/guix-days-2024/hurd.md: New file.

[...]

> * doc/guix-days-2024/cli.md: New file.
>
> Co-authored-by: Adriel Dumas--Jondeau <leirda@disroot.org>

Applied both, thanks a lot!

I’ve added my notes too; let’s hunt the other note-takers tomorrow!  :-)

Ludo’.

[bug#68876] [PATCH] [PATCH maintenance] doc: guix-days-2024: Add notes from the profiling discussion.

[Adriel Dumas--Jondeau via Guix-patches via]

Change-Id: I57abb36cbab43010f43270e626087cb2cb211c14
---
 doc/guix-days-2024/profiling.md | 81 +++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 doc/guix-days-2024/profiling.md

Hi o/

Here are the notes (unmodified, but we now know why ~,trace~ doesn't
behave the same in a ~guix repl~ than in ~guile~, as it is not the same
VM used in both) we've taken during the profiling session.

diff --git a/doc/guix-days-2024/profiling.md b/doc/guix-days-2024/profiling.md
new file mode 100644
index 0000000000..f484a2ff3c
--- /dev/null
+++ b/doc/guix-days-2024/profiling.md
@@ -0,0 +1,81 @@
+# What is profiling?
+
+- Have an idea of the execution time of part of code
+- Have some kind of flame graph
+- What feels slow (not necessarily what is slow)
+- Where's RAM most used?
+
+# What should be profiled?
+
+- guix authenticate
+- guix system/home
+- guix pull
+- not the compilation itself
+- Guix system start time (like ~systemd-analyse~)
+- Time of deployments
+
+# Why?
+
+- To be able to use Guix on low-end/older devices
+- Building a package is long (because of compilation)
+- Pulling is slow (because of network)
+- Computing Guix derivations (guix system init/reconfigure)
+- Authenticating guix commits (especially with many/big commits)
+
+- It's compelling (for HPC people for instance)
+
+- To know where there's progress to be made
+- ~make~ in the Guix repo is slow so testing is not as immediate as it could be
+- As small/fast finale binary as possible
+- To get a feel of what specs are needed to do actual stuff
+
+# How?
+
+- Guile has ~trace~ / ~profile~ procedure that you could use on Guix procs
+  - How to make a flame graph from this data or any other format?
+- Retrieving some metrics on demand from build systems (via ~guix build~)
+  - to get logs RAM/space/temporal usage during compilation
+- Profiling daemons resources usage from shepherd (exposing those profiling options to users)
+- Making shepherd services to profile ~guix shell --container~
+
+# Starting point
+
+```
+$ guix repl
+(guix-user)> ,use (guix scripts build)
+(guix-user)> ,profile (guix-build "hello")
+%     cumulative   self             
+time   seconds     seconds  procedure
+ 24.00      0.16      0.16  put-string
+ 16.00      0.11      0.11  write
+ 12.00      0.11      0.08  append
+ 12.00      0.08      0.08  get-bytevector-n
+  4.00      0.05      0.03  guix/gexp.scm:809:0:gexp-attribute
+  4.00      0.03      0.03  string->utf8
+  4.00      0.03      0.03  guix/packages.scm:1969:0:package->derivation
+  4.00      0.03      0.03  regexp-exec
+  4.00      0.03      0.03  cons
+  4.00      0.03      0.03  guix/store.scm:1426:4
+  4.00      0.03      0.03  apply-smob/1
+  4.00      0.03      0.03  sort
+(guix-user)> ,trace (guix-build "hello") ; doesn't output any trace for some reason
+/gnu/store/6fbh8phmp3izay6c0dpggpxhcjn4xlm5-hello-2.12.1
+(guix-user)> ^D
+$ guile
+(guile-user)> ,use (guix scripts build)
+(guile-user)> ,trace (guix-build "hello") ; however it does work
+trace: |  (guix-build "hello")
+trace: |  |  (_ (guix scripts) #:ensure #f)
+trace: |  |  (_ #<procedure 7ff4802c5000 at ice-9/boot-9.scm:3241:7 ()>)
+trace: |  |  |  (lock-mutex #<mutex 7ff487d01fc0>)
+...
+trace: |  |  |  |  |  |  (fileno #<output: file /dev/pts/3>)
+trace: |  |  |  |  |  |  1
+trace: |  |  |  |  |  |  (bytevector->pointer@system/foreign #vu8(0 0 0 0 0 0 0 0))
+trace: |  |  |  |  |  |  (bytevector->pointer #vu8(0 0 0 0 0 0 0 0))
+trace: |  |  |  |  |  |  #<pointer 0x7ff48036a7d0>
+```
+
+```sh
+$ guix build --verbosity=<big number> --debug=<big number>
+```

base-commit: a4464bd0975c811f18af98f69032b29bddda5b81
prerequisite-patch-id: cefc174692b72660bf5ed4c03442f33dbaf6e784
prerequisite-patch-id: 6b1015959d122056b883e766306b0ff8ba30bde9
prerequisite-patch-id: a3116f7908bc9fdb237e4cde52260856b083596d
prerequisite-patch-id: db1d3d945579284d401944b18fcbc506a000714f
prerequisite-patch-id: 84bff5e4689979f565315edf96250ccc367f8fb8
prerequisite-patch-id: bd69d4115bc86b7d2739e9890625788f1fa5a006
prerequisite-patch-id: 0834ca6f4e7f1ed91b5dcb679096a953a6e36273
prerequisite-patch-id: 9812bf7906d21768559f10f97d8363d2a18fc7e9
prerequisite-patch-id: 68e70365da7db55420105f7cb12c9fffb80d2415
-- 
2.41.0

[bug#68876] [PATCH] [PATCH maintenance] doc: guix-days-2024: Add notes from the profiling discussion.

[Ludovic Courtès]

Hi!

Adriel Dumas--Jondeau <leirda@disroot.org> skribis:

> Hi o/
>
> Here are the notes (unmodified, but we now know why ~,trace~ doesn't
> behave the same in a ~guix repl~ than in ~guile~, as it is not the same
> VM used in both) we've taken during the profiling session.

Heheh, pushed!  Thanks a lot for sharing your notes!

Ludo’.