From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id B3A2861003; Thu, 15 Sep 2022 11:31:51 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 137E860F6B; Thu, 15 Sep 2022 11:31:48 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by atuin.qyliss.net (Postfix) with ESMTPS id 4A8C760F91 for ; Thu, 15 Sep 2022 11:31:44 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 352B65C00C4; Thu, 15 Sep 2022 07:31:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 15 Sep 2022 07:31:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1663241503; x=1663327903; bh=ydqp3hKZMN HvCd5T9XPE/1Lb4A3AzSZPeYmZEbjalkE=; b=t69hEQ4spZIOgmPxo8FQ+XR7vz wbNm55c4kfZfGcLa9BOyDw6NzlKeMcpcJYVfoXEia8YqT1LANdEvRBJHt30KHakr EMZPLAbEyQr1WKW0Vy4IrIivN95+J37wRuA0eUyP1TFbpqUo7y1UR+O3eXDDvak9 s+zlvHs62R6lQgt/2Ib0NCgPDk3L1Ck/n3p0Q4gSG1uY5s73jWQQ0MN/AmLOcq4P oDW9ULL+P6XR4UPODu+hlOWl3uTHkdfuslT1pJlvOLyMFaijl6VI+vmKA19iZvJ1 XB88kefcGxPUUeo6tnzlhRlEhHN5Nafj4JLDoCxxZ5+16jyIp8suyfroEmuA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1663241503; x=1663327903; bh=ydqp3hKZMNHvCd5T9XPE/1Lb4A3A zSZPeYmZEbjalkE=; b=TvDAXDtzGScOi/c6KxzW4n/WLPFlTa2h2L9yOxeJpfZb etM+h9DRAii2/fc0SqXDBVhRzeppRFTJF5JtGOE1HxgCT+uPJ+pPhquVopUxPViG 0AmEEsKL+94YNOc83LT/HV7kayDZ+4e27do8Afu0y1jhtpa6CSyd2XUF4WwyIw2v feewuZE8jrfjgQCNcj+4Mk1oVoyUxbxEBnjdswexJlj/T5MGopRkUFgtRiMISunS uh5X5RPA5jKhEOeA/IeLGXirehPVKDgUrf00dvV/S87O/2wcAlbaY3HLbtPH9nIo LFWqKL08mABD8TUemsQ8iAiDBVv44G9S8GntZYfv/g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedukedggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefujghffffkgggtsehgtderredttdejnecuhfhrohhmpeetlhihshhs rgcutfhoshhsuceohhhisegrlhihshhsrgdrihhsqeenucggtffrrghtthgvrhhnpeethe evudfgjefghefhieejudelkeeljeegvdekueeuhffhgedvveefteevgeetieenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehhihesrghlhihssh grrdhish X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 15 Sep 2022 07:31:42 -0400 (EDT) Received: by x220.qyliss.net (Postfix, from userid 1000) id E04A51D2; Thu, 15 Sep 2022 11:31:40 +0000 (UTC) From: Alyssa Ross To: =?utf-8?Q?Jos=C3=A9?= Pekkarinen Subject: Re: [PATCH] Add image configuration option In-Reply-To: References: <20220915073515.47855-1-jose.pekkarinen@unikie.com> <87mtb1xd38.fsf@alyssa.is> Date: Thu, 15 Sep 2022 11:31:31 +0000 Message-ID: <87h718yiuk.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Message-ID-Hash: I4M4E2FW2ZRCYGWP5KRA64VK4VI32RYB X-Message-ID-Hash: I4M4E2FW2ZRCYGWP5KRA64VK4VI32RYB X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: devel@spectrum-os.org X-Mailman-Version: 3.3.5 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jos=C3=A9 Pekkarinen writes: > On Thu, Sep 15, 2022 at 11:21 AM Alyssa Ross wrote: > >> Jos=C3=A9 Pekkarinen writes: >> >> > The following patch proposes to host nix configuration >> > files under nix folder that offers default configuration >> > for an image, defaulting to a release image, which would >> > be plain spectrum. A hardened default configuration will >> > be proposed in the near future. In case of configuration >> > collision between the default configuration and config.nix, >> > the latter will be taken into account. >> > >> > Signed-off-by: Jos=C3=A9 Pekkarinen >> > --- >> > nix/eval-config.nix | 3 ++- >> > 1 file changed, 2 insertions(+), 1 deletion(-) >> >> Hi Jos=C3=A9, thanks for the patch! >> >> It looks like the correct way to implement such a feature, but I'm not >> sure about the feature itself. >> >> Currently we only have a single configuration option, pkgs. So it >> doesn't make sense to be able to split build configuration across two or >> more files, because only one of them would be able to set the one >> configuration option that exists so far. >> >> We could end up with more configuration options, of course, but I'd >> really like to avoid the situation where a Spectrum build configuration >> is so complicated it needs to be expressed across multiple files in this >> way. Sometimes configuration is unavoidable, like how we have to give >> people a way to use a vendor kernel if required, because we can't >> possibly bundle every vendor kernel we might want to use into the same >> image, but using build configuration should really be a last resort. >> >> I'd expect very few Spectrum users overall to be building their own >> images, so the most important thing is for the default configuration to >> be as good as possible. Hardening falls under that =E2=80=94 if we can = do >> something to harden the Spectrum system, we should probably be doing it >> by default! Or if it's something that doesn't make sense to do by >> default, can we make it configurable at runtime so that users don't have >> to build their own images if they want to use it? (I'm hoping the >> proposed developer mode could work this way, for example. I haven't >> thought about it enough to know if it's practical, but Chrome OS can do >> it.) >> >> If we ever do end up with lots of configuration options to the point >> where they're getting difficult to manage, we can re-evaluate something >> like this (or at that point it might just be worth it to give in and >> reuse the NixOS module system), but I don't think we're at that point >> yet. >> >> What do you think? >> > > Hi, > > In my humble opinion, considering that we are working at > an operative system level, the idea of having a default configuration, > and a debug configuration, preferably that we can activate at runtime, > was outnumbered, but not today, twenty years ago. Only thinking in > our current workflows, we can easily spot variables enough to show > that 2 configurations are not sufficient, you already gave a good > example with the vendor kernels, I can give some more, like building > for a vm, or a host, of arch x86_64 or arm, natively built, or cross > compiled, hardened or not, with debugging tools and symbols or > without them, with extra vms to run application X, without wayland > and graphics applications because our target machine doesn't have > a display. Several of these cases can be combined, and multiple > of them requires changes at build time not giving the option to > enable them at runtime, so eventually not only you'll have a big > set of configuration files, but you'll also want to combine them in > a smart way so that the complexity is bearable and your user > base doesn't get upset because it is very hard to handle. Okay, thanks for the explanation. I think we can group some of these together: =E2=80=A2 Stuff that's already Nixpkgs configuration options or can be expressed through an overlay. Whether to cross compile, what architecture to build for, whether to use a vendor kernel, etc. This can already be handled through the existing configuration mechanism. =E2=80=A2 VM customisation, including extra VMs, disabling Wayland, etc. = In my mind there are still some open questions around how this should be implemented exactly, but this is definitely something that needs to be more configurable. =E2=80=A2 Whether to install extra stuff on the host system. This covers things like debugging symbols and tools. Does that sound right to you? Are there more that you can think of? I'd like to understand the requirements here better, to help think about what sort of configuration mechanisms might be required. > Now, I have to fully disagree that we are not in the > point were we need to re-evaluate things, we are, and you were > before we joined you, you only need to take a look at the contribution > level of your project in time, since the effect of not implementing > flexibility to developers to make their own Spectrum OS for their > needs, is that you will end up with a big base of user that forks > Spectrum with a feature that is divergent enough that proposing > it back to the upstream is unlikely, or even more dangerous, that > the developer in question doesn't even know how to implement > the feature they are required, and they don't even try to hack > the system, loosing the contribution since the beginning. Needless > to mention, you can easily find examples of these 2 scenarios > inside Unikie, no need to look further. Examples in how this > flexibility can be implemented in multiple ways, and it is a > requirement to guarantee a bigger volume of contributions can > be found in communities like buildroot, yocto, or even Nix. You're right =E2=80=94 it's generally a bad thing if people have to patch Spectrum to make it fit their needs. I want to avoid that. But most of the things we've talked about so far don't feel to me like they're going to lead to massive configuration files. The exception is all the stuff that's either Nixpkgs configuration or overlays, but the mechanism you proposed here wouldn't help with that, because only a single configuration file would be able to change anything in "pkgs", due to the configuration files being merged using the non-recursive // operator. That's exactly why it's important to understand what the needs are before we consider specific configuration mechanisms. It's difficult to figure out if an idea will actually make things easier without seeing an example of the problem, and what difference to it the proposed solution would make. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAmMjDRoACgkQ+dvtSFmy ccBILg/+NU/8cbxWq6O48mz6AfNA+Ot52aq2wA4ID7BdDd1XY53+UB1JWcCcWXuO 1BFisze0kHuGZVb0MkE04kRyGgXKDCccZTNyBDH8ybBXFC8A0dGtx64jH2YWnAoq 5ewxnsTorIe0MPPfqKgA8UvHZhkVH1LUHqOszeit+8X85U7lNHfsdAIX7e7GguWu 7m9fm8YLrfgTN3dvU1c8tPaMm2F9iPMroyTP1Bk1vuWmn4J/cYT6ja+x8qcwUoAU 9RVkukIPupfDVGOPRVHHF9cFWmXMmUS9z7h1I0HgnJW9npj8U0UBO8KeNVGC7Enw m6/eEwXZSI4OsJCwMpHpIbH7Eb2ZLjwz9NWDnwyU5hIVyJ0TmYvZ3eE61LPlRM8i kuuvjzeo76ANVGlFdxKGkiG9eiVcEvEsjm9g3A1UzLfI8VzCfCM5L5LzFkejGsH3 wZZkTjm4cMlwWRsJEJzIiEaasGAPzzGn8shE4HgaqtYkzsPlczk/Zzg176Lb+iqD 19J3ytqGh9pXg1/HCmZodMpkASnu/vZ4VQFIh+XxAI0ugKC6DDFaNQRrL5uGI9Rs EdUc8dLBhnlHcWOZUebmUm+SBtOiRBXcovMBxlRhkgvHxoUxWbnpCP8gm1QzRsZ/ ZDTn4/Px7aaUxHOLzISmuu405EI1lveJd8AXbrxnun56DzhIy5g= =/ft2 -----END PGP SIGNATURE----- --=-=-=--