forked from cheng/wallet
62 lines
2.7 KiB
Markdown
62 lines
2.7 KiB
Markdown
|
---
|
||
|
title:
|
||
|
Guix and Shepherd
|
||
|
sidebar: true
|
||
|
misc_links: >-
|
||
|
<a href="set_up_build_environments.md" target="_blank">Set up build environments</a><br>
|
||
|
abstract: >-
|
||
|
I know nothing about Guix. This file exists to record my learning
|
||
|
experience.\
|
||
|
|
||
|
\
|
||
|
|
||
|
The plan is to be able to install Guix on debian, then load a reproducible
|
||
|
configuration file so that I can instantly and reproducibly produce a
|
||
|
host setup the way I want it. (Which nix, lacking its own init
|
||
|
system, cannot quite do, because one always wants to run services.)
|
||
|
...
|
||
|
|
||
|
Guix is primarily a package manager with a declarative functional language
|
||
|
as its package manager.
|
||
|
|
||
|
Which makes it possible to reproducibly create a setup.
|
||
|
Unfortunately the packages are hard to customise,
|
||
|
because access to the
|
||
|
configuration files is restricted and non trivial -- you have to derive your own package from an existing package
|
||
|
|
||
|
Guix solves the problem of dll hell by having any number of configurations living on the same machine --
|
||
|
which leads to massive and rapid accumulation of garbage.
|
||
|
Garbage collection is very slow, and requires either a lot of ram or a lot of swap (12GB swap recommended.
|
||
|
This is a feature I do not want, but wind up suffering, for the advantage of reproducible setups.
|
||
|
|
||
|
To avoid bloat, can use a strategy of re-install from scratch, which Guix makes less painful.
|
||
|
|
||
|
"With Guix System, you declare all aspects of the operating system configuration and Guix takes care of
|
||
|
instantiating the configuration in a transactional, reproducible, and stateless fashion
|
||
|
(see [System Configuration](https://guix.gnu.org/manual/en/html_node/System-Installation.html))."
|
||
|
|
||
|
|
||
|
# What Guix is
|
||
|
|
||
|
A Guix package is a pure function, which generates the install
|
||
|
as directory identified by its hash in `/gnu/store` and then a symbolic link
|
||
|
in the users directory references the package by human readable name, analogous
|
||
|
to git having branch names that point to commits.
|
||
|
|
||
|
Which is great if you have a lot of users each of which might want a different
|
||
|
version of software, but I want to install stuff that will run under
|
||
|
the init system, Shepherd.
|
||
|
|
||
|
The package manager is a great pile of such pure functions,
|
||
|
but if you want to install stuff that is fully configured the way you want it configured,
|
||
|
you are going to have to derive a packages from an existing package
|
||
|
|
||
|
The Guix install system, Shepherd, cannot be a pure function, there can only be one http service,
|
||
|
one wireguard service, and so forth. It has to be the escape hatch that makes a purely functional
|
||
|
system actually do things by not being a purely functional system, akin to Haskell Monads,
|
||
|
an isolated piece of procedural code that make all the purely functional code actually do something.
|
||
|
|
||
|
# Install Guix and Shepherd
|
||
|
|
||
|
not yet begun
|