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.

                    ikey I guess the answer is 'no' in this case? Good

                      davidjharder 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?

                      Right now, I imagine that the binary would stay within the corresponding transaction directory in /.moss/root/${transactionID}/.

                      In the future, we're looking at ensuring that everything under /usr (/usr/local will be a symlink to somewhere under /var probably) will be protected (= read-only, except to moss & friends) such that you cannot write to it, even as root in "normal use".

                      HTH