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 (.stones) 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.

    Hey ikey, how does this compare to something like the ideas in Distri? I noticed what looked like similarities in the design that he describes in his intro blog post and the design here.

    • ikey replied to this.

        ShadowCreator from the looking I've done, distri focuses largely on installation performance, which I can totally understand. However, hermetic dependencies are mandated in the design meaning co-installable packages, which is part of why it has squashfs and FUSE. As a result of focusing on installation performance, the pipeline and critical features aren't in place or considered (by design)

        moss on the other hand is part of a suite of tools for building an operating system sanely. The build pipeline is complex but accessible, with a source format building upon the package.yml format I made for Solus. Thus maintainer cost is vastly reduced with the pipeline containing an easier workflow and a proper build scheduler.. 🙂

        moss is inspired by classical Linux package management, and does not implement hermetic dependencies. We rely on shared dependencies through non-conflicting packages with unique names and providers. To the observer, it feels just like a normal package manager, and requires zero modifications to any userspace tooling. It also doesn't require any exchange directories or symlink farms as seen in Distro and NixOS (symlinks also carry a performance penalty), the filesystem is a "real" Linux filesystem.

        moss is being designed for production use cases, which requires us to know if a transaction has failed. The implementation means we can swap the entire OS out in one atomic operation (via enforced usr-merge, stateless and content addressable store). It's actually pretty fast already, and when the async rewrite lands it'll be a compelling user experience.

        The additional benefit of course being that updates only require as much extra disk space as the unique files added, thanks to the deduplicated (hard linked) content store, and every transaction is still on disk available to revert to.

        Thanks to the off-tree composition and atomic exchange, it doesn't suffer the performance characteristics of ostree, for example, or the limiting software availability of so-called "Modular" or "bundle" led approaches. Packages are packages.

          Hey Ikey this sounds fascinating . can not wait till see this in action. A couple of questions.

          1 . could you explain further how each package or file will be stored in a database ?? or will everything be a binary file with a central index ? i may have misunderstood something.

          1. will every file / package /app currently in the repo have to be converted:? Seems like a big job. I guess you would have to rebuild everything starting with source code as a base or am I wrong? I also imagine some of this work is done already thanks to Serpent OS having some programs /files in its own repo.

          Anyway Good Luck ! Also I would be willing to be a tester if you need volunteers once everything is ready.

          • ikey replied to this.

            tuxlover4 hey 🙂

            So all the "real" files will be in /.moss/assets and stored by xxhash ID. Each root is in /.moss/root and we use a special staging tree to prepare a new transaction. "Promoting" the root swaps the staging tree with the current /usr.
            A number of databases live in /.moss/db.

            • StateDB: All transactions coupled with the list of package IDs they needed
            • LayoutDB: Describe the filesystem layout for every package by unique ID (on all transactions)
            • InstallDB: Metadata (and dependencies) for installed packages (on all transactions)
            • MetaDB: Per repository, provides quick DB cache for each repository in the layer system

            When we produce a new transaction we simply read the relevant entries from the LayoutDB and blit files from assets into the new transaction. 🙂

                Do you have some schematics available for those of us that don't get it after reading a couple of times? :\

                On a system using moss, what happens if a user tries to move an executable by hand into /usr/bin? Presumably the executable gets wiped out by the next moss install?

                • ermo replied to this.

                  My biggest question as a non-technical user of Solus is "When Solus updates to using moss instead of eopkg, will the update be done in a way that causes little or no manual intervention by non-technical users of the distro?"

                  ikey thank you for replying. I understand now . This will be much better in the long run and much quicker . I still don't see how flatpak or snap will fit in but look forward to its usage .

                    I'm idiot at all this,I trust you guys to build it good and strong, so; one thing I'd say: Make it Rain.

                    I wonder about logouts/reboots after installation some particular packages:

                    • do you need reboot/logout after e.g. Firefox update?
                    • do you need reboot after a new kernel update?
                    • ikey replied to this.

                      Solarmass Right now no reboots are mandated, it's immediate. So new software immediately appears. We plan to build in a deferred switch mode where it'll happen in initrd for certain updates, i.e. do not activate /usr until ready.

                        Another question: how it would affect the boot and shutdown fast speed (the killer feature of Solus)?

                        • ikey replied to this.

                          Not gonna lie, it goes a bit over my head still but I think I'm slowly becoming a moss convert after rage quitting several of the immutable distros several times over mostly the reboot requirements.
                          Lighted this is definitely sounding in the range of "immutability done right" for me, but I wonder if a package instalation fails are we able to roll back generationally like NixOS/Silverblue?

                          • ikey replied to this.

                            With moss, will the format of the commands to update the system etc. change? Will it be sudo moss up instead of sudo eopkg up ? I don't want to have the commands become more complex for simple stuff, as that's one of the reasons as to why I like using Solus over other distros

                            • ikey replied to this.