For NS7 we have upstream repos and mirrors + NethServer’s public repos and mirrors. On top of that, Nethesis customers with paid subscription have tech support and alternative repos with delayed updates -in some way similar to the approach taken by Manjaro vs “pure” Arch Linux- as a means to contain upstream packages bugs and keep OS and server stable (a double-edged sword in case of 0-day vulnerabilities, but fixes could also be pushed to repos by Nethesis security team -if there’s any- without much delay).
With NS8 traditional rpm packages updates are less relevant than they used to be on NS7.
Only a few requirements for NS8: podman, systemd (and firewalld), wireguard, python, openssl…
But those few packages are crucial to the core of NS8, hence the “safety harness” option.
Besides podman / systemd version upgrades et al, there are other packages (kernel, etc.) that could cause havoc among servers.
Currently (in this context) NS8 rocky’s mirrorlist points to default Rocky mirrors but in the future that could change (maybe just for customers using paid subscription based support).
Same as with NS7, user is in control of which repos are enabled (can edit / add repo files), but have to understand the benefits and tradeoffs of those changes.
Although NS8 is build around containers, it (sort of) expects to partially “take control” of the underlying OS to make it its play-field/sandbox. For instance, the use of users and home folders.
Some users would expect a higher degree of separation from the OS, and the ability to build a cluster of mixed OS nodes (even though it’s already a step-forward from NS7 where there is no easy clustering option).
As a precaution, developers will encourage installation of NS8 on a clean OS and deter NS users from installing other software solutions alongside NS8 (on the same OS) to prevent unexpected scenarios. Of course, we can install OS updates, nano, mc, nmap and other tools, but maybe not a full-blown web-server with conflicting ports (hypothetical example).