You can define an immutable, deterministic, and bootable system image for anything from an enclave to a laptop with just the primitives provided by the OCI Containerfile standard.
A stagex containerfile can define a system build recipe in such a way that several competing build systems that obey the same standard can all get the same hashes, which we sign every release.
there are several distros built using stagex to get a disk image like airgapos. Just a containerfile a user writes at the last mile.
But when my current "distros" branch lands ideally this month, we will have in-tree support for building images for many common desktop, server, enclave, and embedded use cases.
Just to confirm my understanding, is the following corrects?
NixOS: “Given this configuration, build me the same system again.”
StageX: “Prove that every binary in this system came from the source code I think it did.”
Different angles, same problem. Nix should deterministically take the same pinned inputs and produce the same output, which is also a solution to "Prove that every binary in this system came from the source code I think it did." (since that source code is one of the inputs that's pinned)
How to define the list of installed packages in a config file in StageX, and tell the system that it should be the new list of packages? Like done in nixos
If I remove a package from the list itt best uninstalled, if I add it gets installed, etc
There is a lot of repetition/stutter, also there's some hashes that belong to a .lock file. Is there tooling to edit this file? (Like some command to add/remove/update entries)
Not inventing our own language has drawbacks, but we are convinced the security and portability wins of sticking to standards with many existing implementations, however awkward at times, are worth it.
No major OCI runtime supports separate lock files yet, so for now they have to be maintained at the top of the file for portability. Most teams use scripts to maintain the hash blocks, though soon our official tool, sxctl will have a "lock" function to make this painless. Also only in most cases people will be able to get away with only one hash soon for most common use cases.
This leads to reducing repitition, "boxes" will allow us to have portable patterns such as "rootfs -> cpio" or "rootfs -> bootable iso" to make things dramatically more succinct. Here is an example of the upcoming pattern in action to produce multiple variants of a qemu/cloud bootable < 30mb busybox image: https://codeberg.org/stagex/stagex/src/branch/lance/distros/...
No need for hash locking inputs when in-tree as everything in tree must end up with deterministic digests signed by multiple team members before merging, which are generated in the digests folder.
Similarly we may introduce something a bit like Gentoo Overlays to allow for out-of-tree extension repos to still build with all the benefits of being in tree.
Nix/NixOS is fundamentally about a declarative system configuration.
And as far as I understand, StageX doesn’t have that.