José 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é Pekkarinen > --- > nix/eval-config.nix | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Hi José, 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 — 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?