Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Both statements are valid for StageX


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


Agreed, with NixOs - not only can you declare which packages to include, you can declare how those packages are setup.

Like setting up nginx as a package with SSL support for example.com domain, PHP working with nginx via PHP-FPM, etc.

StageX I don’t believe can do that. I believe it can only confirm that the nginx package hasn’t been tampered with.


Thats just all stuff one puts in a containerfile that generates their disk image. We can build any disk image nix can though with different syntax.


https://git.distrust.co/public/airgap/src/branch/main/Contai...

That containerfile defines an entire deterministic custom OS image, every package, and every configuration etc.

Many patterns are possible, though this will be made way easier with our upcoming "box" primitives


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)

Is this what the box primitives is about?


Fair feedback.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: