Firstly, hi all! It's a really exciting time for Solus - but I imagine as normality returns you're all starting to form some questions.
The first one is @Staudey and @[deleted]'s favourite question of all time:
What is moss?
So you'll see a lot of hype around "immutable" blahblah. That stuff comes later. Right now it is a new package manager designed around a content addressable store, deduplication and atomic updates. It will feel like a classic package manager, having largely the same CLI as eopkg
(subject to change). How it functions internally is very, very different though.
Classic package managers download archives, extract them somewhere temporary and then actively mangle the contents of your /
filesystem to include those packages. This involves creation and deletion of filesystem nodes, as well as handling renames of directories or symlinks or changing symlinks to directories and .... Well it all gets kinda messy.
moss, on the other hand, takes the idea of "package selections" and separates them from the installation via a so-called StateDB. This simply contains the transactions and the package IDs within each transaction. Every time any moss operation is performed, a new transaction (with a numerical ID) is created under /.moss
. Packages are downloaded, but unlike conventional archives these are binary encoded moss-specific format files (.stone
s) that are internally deduplicated with strongly-typed metadata and payloads. Fun fact, they use xxhash
for fast content IDs, have built-in CRC checks, and zstd
for super fast decompression.
When the package is extracted, the various data payloads are merged into moss's databases. The content payload is split into files in the deduplicated store - meaning that every unique file in the OS is stored exactly once by (xx)hash. The new files are hardlinked into a staging tree under /.moss/root
in the new filesystem layout, a step we call blitting. Once the new filesystem is ready, we can activate it immediately by swapping the live /usr
with the staged transaction using the atomic variant of the renameat2
API.
So to tldr all that.. you get atomic updates, immediately available, traditional composition expected from a distro.. and it's all really quite fast =)
We're adding new features as we go, and will look for help with testing and development soon enough. The TLDR is this will feel like a classic package manager without the warts, having stateless design fully baked in, replace the need for usysconf + clr-boot-manager, and support a full A/B system switch needed for Solus 5.
Please respond with any questions, happy to respond! Note we also have other tooling such as our build infrastructure @ https://dash.serpentos.com, boulder
, moss-container
for development.