Re: Guix as a non-optional dependency in another project, and Guix resources requirements.

[Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>]

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

On Wed, 20 Mar 2024 13:15:17 +0100
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

> Hello Denis.
Hi,

> I believe automatically invoking package managers for users does not
> give users control.  Telling them what to run, yes, but running the
> commands for them does not seem like good practice, if it can be
> avoided.  If I were a user, I would mostly like to understand.
Here it's more a question of design and what to do or not to do
automatically. For instance command line users do understand 'ls' or
'find' without needing to look at its source code or to change it. Many
scripts also use 'ls' or 'find'.

Here running 'guix build' commands automatically makes sense and as I
understand many people sharing their Guix configurations do that, at
least to setup the load path (-L, --load-path).

Since we want to reuse the output of guix build (because we want to
integrate guix progressively) there is no other way. 

The question here is more how far to go with the rest (guix pull,
substitutes, etc), and you get a point with that.

When there is setup-specific configuration to do, your advise is usually
good as documentation is easier to get right than a very specific tool
that works only in a subset of the cases. An example here is if you
want to install GNU/Linux on a WiFi access point and that requires you
to setup a TFTP server, in that case a documentation is better than
fragile scripts.

But here Guix is very reproducible there is not a lot to configure for
the users here, so it somewhat makes automatizing updates and
configuration a bit more relevant than other cases.

Though your answer also make me think once we have everything as
Guix packages, what we automatize (updates, etc) would still need to be
kept working not to break contributors or users habits. So the
automatizing would most likely need to be moved in a Makefile.

> In particular, the GNU Boot description on Savannah says it aims to
> replace boot code with 100% free software; the Canoeboot FAQ says it
> is impossible to get completely rid of Intel ME.
GNU Boot description talks about boot software, not boot code (more on
that below).

The devices we support either have no Management Engine (so we don't
need to get rid of something that isn't there), or have a management
engine hardware with its OS being completely removed.

What we remove is the OS (which is software) of the management engine
hardware. We don't remove hardware. 

In practice there is a bootrom inside the Management Engine (that
contains some code that is read-only as the name implies), but we can
consider that as hardware as it is not modifiable by anybody.

In any case we don't have to redistribute any nonfree software so that
bootrom has no impact on Guix usage or in our strategy to upstream
packages inside Guix. And since that bootrom cannot be updated anyway,
we don't have the risk of having to later on provide (nonfree) updates
for users either.

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]