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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,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 6FF5760C00; Thu, 15 Sep 2022 10:43:00 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 57C7160B70; Thu, 15 Sep 2022 10:42:57 +0000 (UTC) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by atuin.qyliss.net (Postfix) with ESMTPS id 53B9160B8E for ; Thu, 15 Sep 2022 10:42:53 +0000 (UTC) Received: by mail-ed1-x52f.google.com with SMTP id z97so26292309ede.8 for ; Thu, 15 Sep 2022 03:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unikie.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=kYeD3aoQdnP9OX8pQX/xG+H2BA5QRcTjHvvecV3+nhc=; b=W25t2qCqEttg2KPdlCWXuLPYN+z9fLq/P0OyLe9/csiZ9oNK0oM02QyvZEg3qFwlmI jn+BhEjDXgeuFJoZpKEU3Q+RlX31d3EjYH24fT2Xe8/0XDf+DrhETHcFU8XjgPQV5k+C QiYq8o1ytG/FAla/54+QpRivksGqjH+3x3zn5JrEpBSThmY81uf2gEOOqTYKo0KziTfw bfC/0nHhvTy+7rF6ONcvvd9ozW/0HbsWw2C9lnbap50t2FsHHJ3sPjFzyMcRgt8LeYgo Ug6dQAcTs1/Mx6/pmEp/4gNFHcYOdoBjlKhMM55O3V2AvH7qNMbavlfqXcwxTUk1e6L7 InHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=kYeD3aoQdnP9OX8pQX/xG+H2BA5QRcTjHvvecV3+nhc=; b=xmcNEH9uf/KfH98vU3NzrYoULkexuE1NNYcfFwROJKdDP3LzQLqThYbO/o+3jfAWz0 ewN6VNuh5so7UN+8wElRDeUXIj3fg0P9L1Q4OfPQ3KjGnlGSyucg43Lp+4SgQRGuSlds ICVbPjg/UqqKnDOTxDJMUg+P0ES2IEjVoL0VaKv4bhQDDjEzWxsCxoqDrKHCfPo/zJOF 5ZXTg+X36M4iCaIIqnegf1sHLgcnyQL9sxq+PReYNK41k1qAqZI04sDwXlBN3bUH6nEY W5kz+ZLU0bGy6Oi+Oj5gBsTqirosBmdwKmf9YNYLoGRUw3ahXDuxJICCss79etBVBsX6 Dv3Q== X-Gm-Message-State: ACgBeo1MLHpQ3XwNBHG3vRodp9x01lMmi6KtbAWGn24OxOjrwIQAWS/Z 8YKbdpaTHAB1uOzHpenlu9adGPzZrTbSxL74IWC22URhJOq1j9wq X-Google-Smtp-Source: AA6agR4FcR+TjFuy3aX7YdiWEuPgOasUkQLeOlDyfsgKJZWf+T7YmEzZ7hrKzNftDOnG/Znu/mD6AA+3D7W+uoGwQv8= X-Received: by 2002:a05:6402:184:b0:442:fd54:2a21 with SMTP id r4-20020a056402018400b00442fd542a21mr33719887edv.129.1663238571194; Thu, 15 Sep 2022 03:42:51 -0700 (PDT) MIME-Version: 1.0 References: <20220915073515.47855-1-jose.pekkarinen@unikie.com> <87mtb1xd38.fsf@alyssa.is> In-Reply-To: <87mtb1xd38.fsf@alyssa.is> From: =?UTF-8?Q?Jos=C3=A9_Pekkarinen?= Date: Thu, 15 Sep 2022 13:42:15 +0300 Message-ID: Subject: Re: [PATCH] Add image configuration option To: Alyssa Ross Content-Type: multipart/alternative; boundary="00000000000036911805e8b4e851" Message-ID-Hash: ML4BYUJOOSTADMIFYGA5GWDPWY4Z5U6P X-Message-ID-Hash: ML4BYUJOOSTADMIFYGA5GWDPWY4Z5U6P X-MailFrom: jose.pekkarinen@unikie.com X-Mailman-Rule-Hits: header-match-devel.spectrum-os.org-0 X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1 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: --00000000000036911805e8b4e851 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 d= o > 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. 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. I hope these give you good hints, and if it doesn't, that we friendly agree to disagree. Jos=C3=A9. --00000000000036911805e8b4e851 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 15, 2022 at 11:21 AM Alys= sa Ross <hi@alyssa.is> wrote:
=
Jos=C3=A9 Pekkarine= n <jose.= pekkarinen@unikie.com> 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 <jose.pekkarinen@unikie.com>
> ---
>=C2=A0 nix/eval-config.nix | 3 ++-
>=C2=A0 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<= br> sure about the feature itself.

Currently we only have a single configuration option, pkgs.=C2=A0 So it
doesn't make sense to be able to split build configuration across two o= r
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.=C2=A0 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.=C2=A0 Hardening falls under that =E2=80=94 if we ca= n do
something to harden the Spectrum system, we should probably be doing it
by default!=C2=A0 Or if it's something that doesn't make sense to d= o by
default, can we make it configurable at runtime so that users don't hav= e
to build their own images if they want to use it?=C2=A0 (I'm hoping the=
proposed developer mode could work this way, for example.=C2=A0 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 poi= nt
yet.

What do you think?

Hi,

In my hu= mble opinion, considering that we are working at
an opera= tive system level, the idea of having a default configuration,
an= d a debug configuration, preferably that we can activate at runtime,
<= div>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=C2=A0 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 bui= lt, or cross
compiled, hardened or not, with debugging tools and = symbols or
without=C2=A0 them, with extra vms to run application = X, without wayland
and graphics applications because our target m= achine 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 o= nly you'll have a big
set of configuration files, but you'= ;ll also want to combine them in
a smart way so that the complexi= ty is bearable and your user
base doesn't get upset because i= t is very hard to handle.

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 t= o make their own Spectrum OS for their
needs, is that you will en= d up with a big base of user that forks
Spectrum with a feature t= hat 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 requ= ired, and they don't even try to hack
the system, loosing the= contribution since the beginning. Needless
to mention, you can e= asily find examples of these 2 scenarios
inside Unikie, no need t= o look further. Examples in how this
flexibility can be implement= ed in multiple ways, and it is a
requirement to guarantee a bigge= r volume of contributions can
be found in communities like buildr= oot, yocto, or even Nix.

I hope these give you good hint= s, and if it doesn't, that
we friendly agree to disag= ree.

<= blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">Jos=C3= =A9.
--00000000000036911805e8b4e851--