Thoughts and questions from a newcomer

Thoughts and questions from a newcomer

[Andrew Erlanger]

Hello, Guix users,

After a bit of love, I've got most of my personal computing environment
running in GuixSD. As I get more comfortable with the system, I hope to
naturally become a developer.

At this point, I have a few thoughts and questions, which I'm looking
for some feedback on, especially where I'm misguided.

It seems that the main problem Guix is trying to address is about state
and side-effects. In modern computers, a program running over here
can affect the execution of a completely unrelated program running over
there because of side-effects. The result is a large amount of
unnecessary complexity. Effectively, the programs have many, many
inputs, and with feedback loops between components, the system can
exhibit chaotic behaivor.

If I'm not mistaken, Guix attempts to provide a way of building
programs so that all inputs to the build process are known exactly.
Assuming that the build is a deterministic process (which I
hope it is!), this ensures that the resuling executables are not
tainted by side-effects.

The main thing that has been confusing me about this process is in
dealing with configuration files. Clearly the state of a program such
as, for example, wpa_supplicant, depends on the configuration file used
to start the process. So, if we are trying to effectively declare the
state-machine of wpa_supplicant using Guile, shouldn't the config file
be part of the Guile definition of wpa_supplicant?

My main draw to Guix was my frustration with configuring Gentoo and
other distros. After I spend a day exactly configuring a system, I want
the state which I set up to be _exactly_ reproducible anytime I want.
But clearly I don't need all the information of the entire disk image
to reproduce that exact state; I just need a few configuration files
worth of information.

If I can't include the contents of configuration files as an input to a
package build, then I can't really capture the state-machine of the
package with a single declaration. I have to then use something like
stow and git to manage my config, which is not really solving the
problem.

On the other hand, it seems that Guix might be more about mitigating
side-effects rather than declaring state. So, which is it?

Thanks for reading,

Andrew

Re: Thoughts and questions from a newcomer

[Julien Lepiller]

[-- Attachment #1: Type: text/plain, Size: 3516 bytes --]

Le 12 septembre 2017 01:25:54 GMT+02:00, Andrew Erlanger <andrew.erlanger@gmail.com> a écrit :
>Hello, Guix users,
>
>After a bit of love, I've got most of my personal computing environment
>running in GuixSD. As I get more comfortable with the system, I hope to
>naturally become a developer.
>
>At this point, I have a few thoughts and questions, which I'm looking
>for some feedback on, especially where I'm misguided.
>
>It seems that the main problem Guix is trying to address is about state
>and side-effects. In modern computers, a program running over here
>can affect the execution of a completely unrelated program running over
>there because of side-effects. The result is a large amount of
>unnecessary complexity. Effectively, the programs have many, many
>inputs, and with feedback loops between components, the system can
>exhibit chaotic behaivor.
>
>If I'm not mistaken, Guix attempts to provide a way of building
>programs so that all inputs to the build process are known exactly.
>Assuming that the build is a deterministic process (which I
>hope it is!), this ensures that the resuling executables are not
>tainted by side-effects.
>
>The main thing that has been confusing me about this process is in
>dealing with configuration files. Clearly the state of a program such
>as, for example, wpa_supplicant, depends on the configuration file used
>to start the process. So, if we are trying to effectively declare the
>state-machine of wpa_supplicant using Guile, shouldn't the config file
>be part of the Guile definition of wpa_supplicant?
>
>My main draw to Guix was my frustration with configuring Gentoo and
>other distros. After I spend a day exactly configuring a system, I want
>the state which I set up to be _exactly_ reproducible anytime I want.
>But clearly I don't need all the information of the entire disk image
>to reproduce that exact state; I just need a few configuration files
>worth of information.
>
>If I can't include the contents of configuration files as an input to a
>package build, then I can't really capture the state-machine of the
>package with a single declaration. I have to then use something like
>stow and git to manage my config, which is not really solving the
>problem.
>
>On the other hand, it seems that Guix might be more about mitigating
>side-effects rather than declaring state. So, which is it?
>
>Thanks for reading,
>
>Andrew

Hi Andrew !

We want to be able to distribute packages to people, so we can't make a package depend on some configuration file. As you noted, it would be unreproducible.

On the other hand, when using guixSD, you can use system services to declare your configuration. Our wpa-supplicant-service cannot be run alone, but if we had a better service, you could declare something like this in guile:

(service wpa-supplicant-service-type
  (wpa-supplicant-configuration
    (ssid "my-wifi")
   ...))

This would create a configuration file in the store and create a new herd service for wpa_supplicant that would use this file. You may be interested in the system configuration section of the manual if you want to learn more.

So, you have a reproducible package and a reproducible config, therefore a reproducible behaviour.

With guixSD you have only one file to edit in order to configure your system entirely. At least that's part of what we would like to achieve. One of your first contribution could be this wpa-supplicant-service-configuration :).

[-- Attachment #2: Type: text/html, Size: 4005 bytes --]

Re: Thoughts and questions from a newcomer

[Ludovic Courtès]

Hello,

Andrew Erlanger <andrew.erlanger@gmail.com> skribis:

> My main draw to Guix was my frustration with configuring Gentoo and
> other distros. After I spend a day exactly configuring a system, I want
> the state which I set up to be _exactly_ reproducible anytime I want.
> But clearly I don't need all the information of the entire disk image
> to reproduce that exact state; I just need a few configuration files
> worth of information.

Indeed.  Like Julien wrote, if you’re using GuixSD, having the Guix
commit and the GuixSD configuration file is all you need to reproduce
the exact same deployment, bit-for-bit (or almost).

To get a feel of what configuration looks like in GuixSD, take a look
at this section of the manual:

  https://gnu.org/software/guix/manual/html_node/Using-the-Configuration-System.html

> On the other hand, it seems that Guix might be more about mitigating
> side-effects rather than declaring state. So, which is it?

GuixSD, as can be seen on the page above, is purely declarative.  You
declare an OS, and then you instantiate it with ‘guix system’.

The per-user profiles of Guix can be either declarative (via ‘guix
package --manifest’), or with an imperative style (‘guix package
--install’ etc.).  In the latter case, the style is imperative, but
under the hood it’s always declarative.

HTH,
Ludo’.