On Wed, 20 Mar 2024 13:15:17 +0100 "pelzflorian (Florian Pelz)" <pelzflor...@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.
pgpRIdD2d2UjQ.pgp
Description: OpenPGP digital signature
