From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id OAYcGY3W/GWwkAAAe85BDQ:P1 (envelope-from ) for ; Fri, 22 Mar 2024 01:53:33 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id OAYcGY3W/GWwkAAAe85BDQ (envelope-from ) for ; Fri, 22 Mar 2024 01:53:33 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=cyberdimension.org header.s=dkim header.b=rfYQPcD8; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1711068813; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=eK/oKHGOr9ru8+tt+pscEybbIfkS46lzByz3YMiNfio=; b=RR1M6Pss9zHqx9SvtiA7shGTnyB/KCzeF6BMwLzjv/VcRAaaPWAZwYBhLCa34UpB6c9wOV dAO1r/gjC7vuIksBOYEe8xwbZavOiB8GzJEeg30AzaW7pIxWAwcDCnUvuvRZNJqUXKaaEJ Vx0X9ILNCxF50sT83f1BUb888IAzggdwfB88rhojk+Bx5VXUW1Hbp4LRRjssYypookcZAr wjgQxXQSBDZ4r6IO5z72s8VHobL4m+mxPVKimUA5+8IGeLz5KMSV2MU5JDSXhm8wYLj1w+ VDJQP1iuUGBtjx2p3SpLA52fllEc6vTNNxCsXj72mKsGqELBG1ykytoUSbpvjg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=cyberdimension.org header.s=dkim header.b=rfYQPcD8; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1711068813; a=rsa-sha256; cv=none; b=AcfilosPbbZxRlfXSlPYb7ln8WrivIqYPHM280BdzUcNSBuSRueoi6IVbq7PfkLfRM0vzT SSfzcWSy9xDhsqeBispSRhEgnJC3iuLn0I6+31m0+IHmNQYrjSxM/wV8kfFBwEICqU7Xqy 6S1dFWYApy9biC80Nd/R2/QnPrKu6if9NoH9jtm2Cb9P5QjZZ++nwMPmQ7iBMQRH2O/EuW vFwzA9Fep73EVzVjRMj8Kb1HsRw4ZNDhupG485gN6Un4gWiufq/KN+s1ym9S7h2UJYfab5 3xXzUWX8qCEpIqm4A40jl6acaWmEj1Nc7rwN/17Tjq95h38T9qKpSEeePTME9A== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 107E51156D for ; Fri, 22 Mar 2024 01:53:33 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rnT9V-0003TF-C4; Thu, 21 Mar 2024 20:52:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rnT9S-0003T5-FC for help-guix@gnu.org; Thu, 21 Mar 2024 20:52:54 -0400 Received: from cyberdimension.org ([80.67.179.20] helo=gnutoo.cyberdimension.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rnT9O-0002eq-Kr; Thu, 21 Mar 2024 20:52:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=dkim; bh=eWT+3AM5qk1z3pA 3pC+r43w/cF5FYNIu/xhwDfPS0fU=; h=references:in-reply-to:subject:cc:to: from:date; d=cyberdimension.org; b=rfYQPcD8DfkeGWPWb9LQc0lJb2JIO3/awyj ShfO1P++JxN+lHp4MTPqcfRs0nyB+xq8fJNV1Lqvtw0UQ1CH1gXcaiWPvlFWGp86Jr+RRn r0nt2a66QaXqaTHv4/L4UU+1FIEccv0qoeLeR95rczHNB8vFyNzN6Ii+nXuOMktYXLIlNe q/DOVBKaMkIWTG1vLaLVB1st6PsiUR/DZvkXM8bBqPoNe7xru1+v2jq/f3jldbYi+O2+T5 X441OigUCUTxMSUVzU/D5EF09Kj4f147tTkGYGCOnl+IkldsMuJeulBG3JgIGQM9b+rK33 ssurrz+Nca+EdUaH+fjKvPedXyw== Received: from primary_laptop (localhost [::1]) by gnutoo.cyberdimension.org (OpenSMTPD) with ESMTP id eca17cba; Fri, 22 Mar 2024 00:52:42 +0000 (UTC) Date: Fri, 22 Mar 2024 01:52:24 +0100 From: Denis 'GNUtoo' Carikli To: "pelzflorian (Florian Pelz)" Cc: help-guix@gnu.org, Adrien 'neox' Bourmault Subject: Re: Guix as a non-optional dependency in another project, and Guix resources requirements. Message-ID: <20240322015224.6e7e92cf@primary_laptop> In-Reply-To: <87y1ad6qwa.fsf@pelzflorian.de> References: <20240316020307.6bf7335c@primary_laptop> <87y1ad6qwa.fsf@pelzflorian.de> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.37; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/eg/gVTNy86zVyjtDr0yxe1+"; protocol="application/pgp-signature"; micalg=pgp-sha256 Received-SPF: pass client-ip=80.67.179.20; envelope-from=GNUtoo@cyberdimension.org; helo=gnutoo.cyberdimension.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: help-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -6.93 X-Spam-Score: -6.93 X-Migadu-Queue-Id: 107E51156D X-Migadu-Scanner: mx12.migadu.com X-TUID: Mhhojw5TtncE --Sig_/eg/gVTNy86zVyjtDr0yxe1+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 20 Mar 2024 13:15:17 +0100 "pelzflorian (Florian Pelz)" 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.=20 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.=20 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. --Sig_/eg/gVTNy86zVyjtDr0yxe1+ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAmX81kgACgkQX138wUF3 4mOU4Q/+O+lXCUf47BDJpBauWkFNg4l9aIcyIdKdUOu0IylbxklPG9Px5q6oIZ9F SPXjLnbmh/n6RTchqBbRAzJdnM0lJb0WEh8JXlbmWE1ltkbTIGrY7d/SmMSkjk0a w7LB0NdpIJYsOlTwaxFQnB40LVdSEu8oseowAPRGyKWCW7Rpi45hPTw0BH/zIGrk /CePmdMpIhNer0xheSWM2bCiG/U1QhH4NsrEAA3UknB9kEuzkPylov3ha9Q/WesM e/XSVxtJcbgLUSnUPbU7z41NXNsbYJjHw5MgRGhyad4JUyIIFaGTJNUikZxj9pgX ZeX5ShtxkGwWIWoeOVMiHQHRfmJlXT6oxwYl8vI8SiNqTETQuN6ANnaDFCiGdXJZ Kkd29JtT7N9EXp+ChX7Hdxt3Wk6dLsT7mP3ccnXqSeiLzMJpGGtC5h/3861Ew5Ck kYriL8PzB6pTo73nr6L2SEPibu9pJRmt/ZdnAxUQDAyW7HahEtuZeMIgYwWXeAMw otWlKNPzvtVV4Qb1U/0Z74APxekNcBho5h8BcQUMr7psjhRnojPFDwmhMJAzAmNM EEldmiaFfrgV2nmzJrT8rbApxQsaQ/ivKg/SPHAXlNnWHcDE2q+QWp1vLbm1ITgr xND1s11EU2LQWFpcsiC/ptjoi7+w5JH2k0HEQqWu5xrDn06YBAc= =iCLX -----END PGP SIGNATURE----- --Sig_/eg/gVTNy86zVyjtDr0yxe1+--