Updated Serpent OS Alpha Brings Few Fixes To This Original Linux Distribution

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67377

    Updated Serpent OS Alpha Brings Few Fixes To This Original Linux Distribution

    Phoronix: Updated Serpent OS Alpha Brings Few Fixes To This Original Linux Distribution

    Last week Ikey Doherty's Serpent OS Linux distribution debuted in alpha form while kicking off the new week is updated install media to provide a few fixes for this original from-scratch Linux distribution...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
  • Topolino
    Phoronix Member
    • Jun 2024
    • 116

    #2
    I understand this is mostly a packaging effort? How is this effort added value compared to Fedora / Debian?

    Comment

    • ikey_serpent
      Junior Member
      • Jan 2024
      • 6

      #3
      Originally posted by Topolino View Post
      I understand this is mostly a packaging effort? How is this effort added value compared to Fedora / Debian?
      I think it's fair to say most distributions are mostly a packaging effort. What we're actually trying to do with Serpent OS is change *how* we distribute, rather than focus on just being a distribution. That requires work across the board to make the tooling and the distro work together a a singular thing.

      I guess the major USP for moss (our package manager) is enabling atomic updates *without* sacrificing on classical package management features (granularity/composition) or relying on a specific filesystem to achieve the features, say, using btrfs. At the core it's effectively content addressable storage, deduplicating the entirety of the OS across multiple transactions which can be rolled back/forwards offline. Each transaction is in essence a hardlink farm, relying on a usr-merge system. We swap `/usr` out with the newly staged transaction (once fully baked and all triggers run in their own isolated namespace..) using the `renameat2()` call with `ATOMIC_EXCHANGE`, thereby not impacting any inodes. It means trivial updates and package additions don't require reboots. Ofc, for a lot of updates you'll still *want* to reboot.

      Beyond that we have boulder, our package build tool that is largely a successor to ypkg/solbuild from Solus. It uses our declarative recipe format to generate our packages, with a bunch of tuning options, trivial rule based package splitting, automatic binary, python, cmake and pkgconfig deps. And of course, generates the ".stone" binary packages, which are internally deduplicated, using binary structured, versioned payloads, lookup tables and zstd compression.

      In the mix we also have blsforme, largely a successor to my clr-boot-manager project, for automatic configuration and management of the ESP. Long story short it reliable
      manages boot entries, the XBOOTLDR if present, discovery and mount of ESP/XBOOTLDR, and cmdline management (root= being automatically generated/zero conf)

      We're not actually trying to build a distribution that appears different. We're trying to build a Linux distribution that is usable, like everyone else, but distributed in a fashion that is easy for the client side and maintainer side of the equation. That's why we're also furthering my old Clear Linux stateless work (coined "hermetic /usr" by openSUSE) to make it even easier to move between transactions, as our stone packages aren't allowed to contain any `/etc` files (anything non `/usr`, basically). This has lead to a hybrid approach of sysusers, tmpfiles, userdb drop ins, etc.

      We're at the point now where our installer, lichen, actually does very little work in the whole "OS provisioning" story. Assuming the rootfs is mounted, and the ESP (and potentially XBOOTLDR) are mounted into the target you can `moss install -D $destdir $(cat package_list)` and have pretty much an entirely functioning, bootable install.

      I know folks may say "why not ostree" and "why not bootc" - so shortly, sweetly:

      - ostree requires sideloading hackery on overlayfs to be functional for developer use-cases
      - not granular.
      - bootc came after clr-boot-manager/blsforme, and i've reached out to their devs a few times.

      TLDR, we (Serpent OS folk) want a traditional feeling package manager *but* with the bells and whistles of the new generations of Linux distributions; easier provisioning, stateless, atomic updates. We're not actually immutable but that'll be implemented down the road, likely via LSM. For now you can `moss state verify` to confirm your integrity, and still have seamless A/B swaps without mandated reboots or explicit topology requirements like a secondary partition. And, the system is usable in chroots/containers without having to recreate the work of initrd helpers (remounting the usr tree from a private location and pivot_root, etc)

      Hope this information helps, sorry I've not replied to the other articles on Phoronix, I've had some health issues in the last few months (herniated disc C6-C7. Ouch )

      Comment

      • Pheoxy
        Junior Member
        • Dec 2018
        • 18

        #4
        For a start and to really spice up the comments, the tooling is built in rust and leverages it heavily to keep the existing simplification within most package management software. From what I remember talking to Ikey a lot of the tasks usually done by contributors is also meant to be heavily automated in the tooling to allow for development to focus on key issues within package integration and ABI compatibility with a immutable system using atomic updates in realtime.

        Performance is also sought after within that stack and I would equate it to similar to Gentoo but more fedora influenced maybe without user required interaction with how boulder and moss inform packaging during build time for the entire stack.
        From what I remember it's meant to use strictly sane stable standardized compile options although their was still some development to do when I last poked around and had a go at it with architecture types and the compile levels they were still looking at.

        It was pretty cool having a look and contributing a bit but I'm still learning rust so that held be back a bit when I looked at the tooling.

        Also the tooling is supposed to be just that easy, eventually.
        If you get, you get that one.

        I found the core team knew what they wanted and Ikey was determined to get there but that meant they had a bit of leg work to do to get there

        I found I could nearly run it as a Daily driver like you would other bleeding edge distros depending on your use case and if flatpaks were most of what you needed. But I couldn't rely on it then as the repository just didn't have everything I needed yet and while I contributed a few packages I did use often some packages wouldn't be up streamed into SerpentOS proper yet or was confusing to get right with the kernel if it had kernel modules at that moment because the tooling for that was still in heavy active development or still in initial stages.

        I'll be honest though any issues I usually had were most times a skill issue.

        Sorry for long winded post, I had a lot of fun with SerpentOS and recommend you give it a try just do it on a VM or something you don't mind if it eats your data. This happened more than a few times to me when I was developing packages and the /tmpfs kept running out and the filesystem got corrupted saying it had no space but had over 100gb free space remaining so it's not joking.

        Have fun! 😅

        Comment

        • renich
          Junior Member
          • Jun 2023
          • 2

          #5
          Originally posted by Topolino View Post
          I understand this is mostly a packaging effort? How is this effort added value compared to Fedora / Debian?
          Not at all. Check them out: https://serpentos.com/

          There's a lot to be said about the project:

          * cutting edge tool chain (LLVM, libc++, etc)
          * brand new rustified tooling (build system, boot manager, package manager and installer)
          * built on a modern microarchitecture: x86-64-v2 at the time, I believe)
          * Extensive systemd integration.
          * Atomic updates without being immutable.

          Besides that, the distro boots instantly, the package manager is fast as hell and the dev team is available and light-blooded, if that makes sense in English.

          Comment

          • ermo
            Senior Member
            • Mar 2014
            • 589

            #6
            Originally posted by Pheoxy View Post
            (...) and the filesystem got corrupted saying it had no space but had over 100gb free space remaining so it's not joking.

            Have fun! 😅
            For context, we "blit" a new root for each moss transaction that involves installs/removals. These new roots are based on a farm of hardlinks to the moss content store.

            To fix the error, we initially just pruned the filesystem so it would not keep around as many previous transaction roots. But as we kept hitting the error, we dug a little deeper.
            ​
            In return, we found that (particularly for linux kernel development config option files) a lot of hard link farm files all pointed to the empty file in the store, which is what would typically (via multiple transactions containing said files) cause the number of links to grow to the point where users hit the EMLINK error that implies "sorry, the filesystem refuses to make any more links to the same empty file in the underlying moss store". In addition, we found out the hard way that ext4 has a hard limit of 65k links to a single file, due to the filesystem using an unsigned 16-bit integer to count them.

            Now, we no longer deduplicate empty files, but let them live as actual files in each transaction. We also no longer recommend that people use ext4 (it will hit the hardlink limit too soon), and instead offer suitable alternatives, which all use a 32-bit unsigned integer (which can count to four billion plus change) for storing the allowed number of hardlinks to a single file

            As for the rest of the post, that's a pretty fair assessment. There's a reason we are carrying an alpha label currently.
            Last edited by ermo; 30 December 2024, 01:42 PM.

            Comment

            • ermo
              Senior Member
              • Mar 2014
              • 589

              #7
              Originally posted by Topolino View Post
              I understand this is mostly a packaging effort? How is this effort added value compared to Fedora / Debian?
              We're building new tooling and system management facilities from scratch, designed for a distribution built from the ground up, so as to be able tackle the issues with existing tooling (and distributions) in a way we believe will make for not only a better system, but also a better development, delivery and system management workflow.

              The value add from this perspective is that we are not constrained by the tooling that Fedora or Debian use, and that we are also not constrained by the stakeholders of either distribution, meaning we don't need to contort ourselves into strange shapes because the tooling needs to be backwards compatible or makes decisions that are not aligned with what we are seeking to achieve.

              If this was "mostly a packaging effort", we could have just used existing tooling.
              Last edited by ermo; 30 December 2024, 05:41 PM.

              Comment

              • pWe00Iri3e7Z9lHOX2Qx
                Senior Member
                • Jul 2020
                • 1595

                #8
                Originally posted by ermo View Post

                For context, we "blit" a new root for each moss transaction that involves installs/removals. These new roots are based on a farm of hardlinks to the moss content store.
                .
                Is this similar at all to the way that NixOS generations are handled and /nix/store?

                Comment

                • ermo
                  Senior Member
                  • Mar 2014
                  • 589

                  #9
                  Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post

                  Is this similar at all to the way that NixOS generations are handled and /nix/store?
                  Only at a very superficial level it would seem. In practice, moss is not nix.

                  If people need or rely on what NixOS offers, they should use NixOS.
                  Last edited by ermo; 30 December 2024, 08:50 PM.

                  Comment

                  • rrveex
                    Phoronix Member
                    • Aug 2023
                    • 50

                    #10
                    Originally posted by renich View Post


                    * Extensive systemd integration.
                    OMG. Can it get any... [cough] _more_ systemd than just systemd?

                    Comment

                    Working...
                    X