System Management Tool For Serpent OS
`moss` is much more than just a package manager
The ideas behind
moss are not original, but are refined and combined into a single package manager. In fact it’s much
more than a package manager! By taking all the good parts and extending the features we are left with the ultimate
distro management tools! And what good would it be if we didn’t also make it extremely fast!
The Basics of System Layout
moss stores packages on disk as a unique hash of every file. In Serpent OS, we call this
caching a package which
includes adding the package metadata to the corresponding databases. This differs to installation as the files aren’t
yet available for the user to access. Therefore we can
cache a package at any time without impacting on the running
From there, we can make up an entire system state (the
/usr directory) by creating hardlinks in the
moss store to
build up a complete
/usr directory for the system. We call this process
blitting and is the step that makes
packages available to the user. Once we have created a system state, it is now ready to be accessed via a symlink.
For example, here we see the
/usr directory as a pointer to the
moss store (
usr -> .moss/store/root/1/usr). From
the users perspective, it will just work like a traditional file system layout, but with much more flexibility.
Blitting Makes Serpent OS Atomic
The update process is fully atomic, where
caching occurs separately in the background and
blitting creates a system
state in the
moss store before it has any impact on the users system. If there’s a power outage or interruption of
this process, there’s no problem at all. Your original
/usr directory will still be in place when you reboot and
rerunning the update will then create a fresh system state. This makes transactions with
moss dependable, simple and
As a result, when updates occur, the previous system state remains on the system allowing for easy rollbacks if there’s anything at all that you don’t like. Just change the symlink back and you’ve got your system back just like that. This allows for easy testing of changes including a whole branch of updates!
For bigger updates you will need to reboot in order to start running the new system, but the update can be prepared beforehand so won’t be waiting longer than your usual reboot time for the update to complete.
moss-format: What Makes Up a Package?
.stone package is made up of four payloads:
- Meta Payload: Contains the usual metadata of a package including its dependencies.
- Layout Payload: This includes all the information to apply a
cachedpackage to the system. Includes the file hash, the path of the file (in
/usr) and the file’s permissions.
- Index Payload: Includes the size and hashes of files in the content payload. This is used for
cachinga package, and is not needed to be stored afterwards.
- Content Payload: The files of the package concatenated together. Relies on the index payload to make sense of its contents.
This differs a lot from traditional tarball packages, where each payload is compressed individually. Despite this, it is very efficient by comparison allowing for smaller package sizes. As the format is designed specifically for Serpent OS, every aspect can be tuned for function and performance.
moss-triggers: Smarter Post-Install Triggers
Post-install package triggers have long been used by Linux distros, but aren’t really needed.
post-install scripts from packages by taking care of the functions in
moss when state data needs to be updated after
package updates. The requirements for post-install operations are entirely predictable, if you add or remove icons, you
need to update the icon cache. If changing libraries, it will run
ldconfig to update the cache for faster binary
loading. This makes life easier for packagers and keeps the system in optimal working condition.
Smart System Management (SSM)
We already have a pretty in-depth discussion on how
moss takes care of system through SSM. See our
Smart System Management page for the full details.
Reproducible System States With Versioned Repos
With a rolling release distro, there are instances where users don’t always want the latest versions of software. Maybe they aren’t ready for the changes in the new version of a database. Downgrading or holding back package updates results in a partial update. These are difficult to support and quickly get complicated where new updates aren’t built to work with the software you have installed locally.
Versioned repos solve this issue by creating
checkpoints, that is a static set of packages at a particular time that
are all built to work with each other. This means that if you don’t update to the latest version, you can still install
extra software that you know with work with your slightly older packages. While most of the time you’ll want to be on
the latest release, this is a handy feature to have for the times it’s needed.
Versioned repos are a fantastic feature when it comes to bugfixing as you can reproduce the set of packages of a user in a given state, even if it was from last month. This allows one to reduce the causes of the bug to a minimal set of packages.
Binary Versus Source Builds
moss operates as a source distribution with pre-built binary packages used where available. Pre-built binary packages
will be available for the main Serpent OS repository, but as it’s focused on source builds, opens up opportunities to
easily add and share new packages with others. Instead of asking someone to install a binary package (where you can’t
validate that the contents haven’t been altered), you can build the package on the host machine instead.
This makes adding source repos simple and easy, hence having a community source repo for people to share their builds
without having to setup a build server to create and serve the output
Deltas Make For Small Updates
Where pre-built binary packages are available, there’s also the ability to provide delta packages to minimize update
size. Deltas are very effective on Serpent OS, as due to the unique way that
moss works there’s no need to recreate
packages before applying an update. This makes them extremely fast and efficient to use, and always better than simply
downloading the full package. There’s no trade-off for whether they are worthwhile, to reduce download size by
increasing CPU use for an update. Serpent OS deltas are able to reduce both! Through the use of
zstd, we can even
produce deltas for binary files to really make updates smaller.