Blog: Add excerpt tag for All posts

src/content/docs/blog/2020/08/16/stage2-complete/index.md

@@ -27,6 +27,8 @@ For cross-compilation, we'll be relying on `qemu-static` to complete `2.5` and `
 
 This is a major milestone for the project, as it is an early indication that we're self hosting.
 
+<!-- excerpt -->
+
 ## Multiple Architecture Support
 
 At this point in time, we now have build support for two targets: `x86_64` and `ARMV8a`. Our intent is to support `haswell` and above, or `zen` and above, for the x86_64 target.

src/content/docs/blog/2020/08/20/stage3-progress/index.md

@@ -26,6 +26,8 @@ We're going to start working on a project to flesh out the `musl` runtime with s
 
 These will be maintained over at our [GitHub](https://github.com/serpent-os/libc-support)
 
+<!-- excerpt -->
+
 ## libwildebeest
 
 As a project we strive for correctness in the most pragmatic way. Some software, such as systemd, is heavily reliant on GNU GCC/GLibc extensions. In some software there are feasible alternatives when using `musl`, however in a good number of cases, functionality required to build certain

src/content/docs/blog/2020/08/28/looking-stage4-in-the-eye/index.md

@@ -16,6 +16,8 @@ Well, we've made an awful lot of progress in these last few days. It wasn't that
 
 Our [libc-support](https://github.com/ikeycode/libc-support) project has been growing, thanks primarily to the contributions of [Jouni Roivas](https://github.com/jroivas). We now have initial working versions of `getent` and `getconf`. The `getconf` program is considered feature-complete for our current requirements, and the focus is now on cleaning up `getent` making it more modular and easy to maintain in the long run.
 
+<!-- excerpt -->
+
 ## libwildebeest
 
 We began work on [libwildebeest](https://github.com/ikeycode/libwildebeest) to quickly unlock building `systemd`. Remember, our ambition with this project is to provide a sane, centralised way of maintaining source compatibility with various projects that rely on features currently only available in the GNU toolchain + runtime. This is our alternative vision to patching every single package that fails to build against our LLVM+musl toolchain, ensuring our work scales.

src/content/docs/blog/2020/09/07/stage3-complete/index.md

@@ -22,6 +22,8 @@ Moss does not aim to be a next generation package management solution, it instea
 
 In order to complete `stage3`, we provided linker stubs in `libwildebeest` to ensure we can build. Obviously this introduces runtime errors in systemd and our `stage3` isn't bootable, just chrootable. This will be resolved when systemd is properly packaged by moss in `stage4`.
 
+<!-- excerpt -->
+
 ## Docker Image
 
 We now have a test container available on Docker Hub. You can install and run the simple bash environment by executing the following command with a Docker-enabled user:

src/content/docs/blog/2020/09/10/defining-moss/index.md

@@ -27,6 +27,8 @@ This is typically achieved using a so-called `A/B switch`, which is what we will
 
 Primarily we'll update a single `/usr` symlink to point to the current OS image, with `/` being a read-only faux rootfs, populated with established mountpoints and symlinks. Mutation will be possible only via `moss` transactions, or in world-writable locations (`/opt`, `/usr/local`, `/etc` ...)
 
+<!-- excerpt -->
+
 ## Deduplication
 
 The moss binary package format will be deduplicated in nature, containing hash-keyed blobs in an `zstd` compressed payload. Unique blobs will be stored in a global cache, and hard-linked into their final location (i.e. `/moss/root/$number/usr/...`) to deduplicate the installed system too. This allows multiple system snapshots with minimal overhead, and the ability to perform an offline rollback.

src/content/docs/blog/2020/09/20/moss-format-defined/index.md

@@ -50,6 +50,8 @@ The `Meta` payload consists of a number of records, each with strongly defined t
     ubyte[1] padding = 0;
 ```
 
+<!-- excerpt -->
+
 ## TLDR that for me...
 
 Binary format that is self deduplicating at several layers, permitting fast transactional operations.

src/content/docs/blog/2020/09/21/source-format-defined/index.md

@@ -39,6 +39,8 @@ We've opted to group "Package Definition" behaviour into core structs, which are
             rundeps: Different rundeps
 ```
 
+<!-- excerpt -->
+
 ## Multiple architecture support
 
 In keeping with the grouping behaviour, we're baking multiple architecture configurations into the YML file. A common issue encountered with the older format was how to handle `emul32`:

src/content/docs/blog/2020/09/22/results-of-the-experiment/index.md

@@ -19,6 +19,8 @@ It turns out that so far the experiment has been successful, and being forkable
 
 ![Toolchain bootstrap](./Featured.webp "Toolchain bootstrap")
 
+<!-- excerpt -->
+
 ## An open community
 
 Over the past 2 months we've transformed from set of ideas into a transparent, community-first organisation with clear leadership and open goals. I've stepped into the Benevolent Dictator For Life position, and Peter has taken on daily responsibilities for the project running. Aydemir is now our treasurer on Open Collective[^1], and many individuals contribute to our project.

src/content/docs/blog/2020/10/11/build-system-functional/index.md

@@ -13,7 +13,6 @@ Wow, has it been a hectic few weeks, and it definitely shows: last time we blogg
 
 ![Look at all the buildiness](./Featured.webp "Look at all the buildiness")
 
-
 ## It lives!
 
 We're now able to build **the majority** of a moss package. Notice I've made a distinction there. So, we're able to run the build instructions, and use all the metadata, configuration and macros available. The only thing we're not actually doing is dumping the built files into a binary package.
@@ -33,6 +32,7 @@ We're able to do the build-system part _rather well_, now. Right now we support
  - Recursive macro support in build scripts, defined on per-profile level
  - Architecture specific profiles support in stone.yml, i.e. `profiles -> aarch64 -> setup:` to avoid if/else spaghetti.
 
+<!-- excerpt -->
 
 ## Next on the agenda
 

src/content/docs/blog/2021/02/08/cleanups-complete/index.md

@@ -27,6 +27,8 @@ As it now stands, 1 lint issue (a non-issue, really) exists across all 4 project
 
 Granted, cleanups aren't all that sexy. Peter has been updating many parts of the bootstrap project, introducing systemd 247.3, LLVM 11.0.1, etc. We now have all 3 stages building correctly again for the x86_64 target.
 
+<!-- excerpt -->
+
 ## And then....
 
 Yikes, tough audience! So we've formed a new working TODO which will make its way online as a public document at some point. The first stage, cleanups, is done. Next is to restore feature development, working specifically on the extraction and install routines. From there, much work and cadence will be unlocked, allowing us to work towards an MVP.

src/content/docs/blog/2021/02/09/unlocking-moss/index.md

@@ -21,6 +21,8 @@ Some patching has taken place to prevent using `ld.gold` and instead use `lld` t
 
 ![A wild LDC appears](./Featured.webp "A wild LDC appears")
 
+<!-- excerpt -->
+
 ## Reworking the Payload implementation
 
 Originally our prototype moss format only contained a `ContentPayload` for files, and a `MetaPayload` for metadata, package information, etc. As a result, we opted for simple structs, basic case handling and an iterable `Reader` implementation.

src/content/docs/blog/2021/02/17/moss-format-read-write-support/index.md

@@ -25,6 +25,8 @@ We've removed the old enumeration approach from the `Reader` class, instead requ
 
 Right now we can read and write our `MetaPayload` from and to the stream, allowing us to encode & decode the metadata associated with the package, with strong type information (i.e. `Uint64`, `String`, etc.)
 
+<!-- excerpt -->
+
 ## Next Steps
 
 We need to restore the `IndexPayload`, `LayoutPayload` and `ContentPayload` definitions. The first two are simply **data** payloads and will largely follow the design of the newly reimplemented `MetaPayload`. Then we restore `ContentPayload` support, and this will allow the next steps: unpack, install.

src/content/docs/blog/2021/03/16/optimising-package-distribution/index.md

@@ -21,6 +21,8 @@ Minimising the size of updates is particularly valuable where files are download
 
 From the users point of view, minimising file size and upgrade time are important priorities, but for a developer, the speed at which packages are created and indexed is vital to progression. Deltas are different to packages in that they aren't required immediately, so there's minimal impact in taking longer to minimise their size. By getting deltas right, we can trade-off the size of packages to speed up development, while users will not be affected and fetch only size optimised deltas.
 
+<!-- excerpt -->
+
 ## Test Case - QtWebEngine
 
 QtWebEngine provides a reasonable test case where the package is a mix of binaries, resources and translations, but above average in size (157.3MB uncompressed). The first trade-off for speed over size has already been made by incorporating `zstd` in moss over `xz`, where even with max compression `zstd` is already 5.6% larger than using `xz`. This is of course due to the amazing decompression speeds where `zstd` is magnitudes faster.

src/content/docs/blog/2021/03/20/moss-unlocked/index.md

@@ -18,6 +18,8 @@ Oh yeah, that totally happened. So, we can now successfully build moss packages
 
 Admittedly the code is super rough within `moss` and somewhat proof of concept, however we're able to extract the contents of the moss archive and rebuild the layout on disk.
 
+<!-- excerpt -->
+
 ## What makes extraction difficult?
 
 Well, quirky new format for one. A moss archive currently consists of 4 "payloads", or major sections:

src/content/docs/blog/2021/05/18/let-there-be-databases/index.md

@@ -20,6 +20,8 @@ So far we've implemented a "StateMetaDB", which stores metadata on every recorde
 
 Next on the list is the LayoutsDB (file manifests) and the CacheDB, for recording refcounts of every cached file in the OS pool.
 
+<!-- excerpt -->
+
 ## Integration with Serpent ECS
 
 An interesting trial we're currently implementing is to hook the DB implementation up to our Entity Component system from the Serpent Engine, in order to provide fast, cache coherent, in memory storage for the DB. It's implemented using many nice DLang idioms, allowing the full use of `std.algorithm` APIs:

src/content/docs/blog/2021/08/02/initial-performance-testing/index.md

@@ -26,6 +26,8 @@ It is important to note that in this comparison the Host distro has pulled in so
 
 Based on the results during testing, the performance of `clang` in Serpent OS still has room to improve and was just a quick tuning pass. At stages where I would have expected to be ahead already, the compile performance was only equal (but `cmake` and `configure` were still well ahead).
 
+<!-- excerpt -->
+
 ## GCC Matters Too!
 
 While `clang` is the default compiler in Serpent OS, there may be instances where the performance is not quite where it could be. It is common to see software have more optimized code paths where they are not tested with `clang` upstream. As an example, here's a couple of patches in flac ([1](https://github.com/xiph/flac/commit/67ea8badadd3e63b8e8af5fe837d075104569330), [2](https://github.com/xiph/flac/commit/d4a1b345dd16591ff6f17c67ee519afebe2f9792)) that demonstrate this being improved. Using `benchmarking-tools`, it is easy to see where `gcc` and `clang` builds are running different functions via `perf` results.

src/content/docs/blog/2021/08/03/moss-db-progress/index.md

@@ -54,6 +54,8 @@ And this is the new, shmexy way:
 
 It's quite easy to see the new API lends itself robustly to our needs, so that we may implement stateful, strongly typed databases for moss.
 
+<!-- excerpt -->
+
 ## Next Steps
 
 Even though some APIs in `moss-db` may still be lacking (remove, for example) we're happy that it can provide the foundation for our next steps. We now need to roll out the new `StateDB`, `MetaDB` and `LayoutDB`, to record system states, package metadata, and filesystem layout information, respectively.

src/content/docs/blog/2021/08/10/a-rolling-boulder-gathers-no-moss/index.md

@@ -26,6 +26,8 @@ Well, persistence really. Thanks to `RocksDB` and our new `moss-db` project, we
 
 Additionally, we remember the layouts within the LayoutDB so that we can eventually recreate said layout on disk.
 
+<!-- excerpt -->
+
 ## Precaching
 
 Before we actually commit to an install, we try to precache all of the stone files in our pool. So we unpack the content payload ("megablob"), split it into various unique files in the pool ready for use. At this point we also record the Layouts, but do not "install" the package to a system root.

src/content/docs/blog/2021/08/25/unpacking-the-build-process-1/index.md

@@ -26,6 +26,8 @@ Some key parts to setting up the build environment:
 
 While the focus of early optimization work has been on build time performance, there's more overhead to creating packages time than simply compiling code. Now the compiler is in a good place, we can explore the rest of the build process.
 
+<!-- excerpt -->
+
 ## Packaging is More than just Compile Time
 
 There's been plenty of progress in speeding up the creation of the build environment such as parallel downloads to reduce connection overhead and using `zstd` for the fast decompression of packages. But there's more that we can do to provide an optimal experience to our packagers.

src/content/docs/blog/2021/09/20/unpacking-the-build-process-2/index.md

@@ -22,6 +22,8 @@ The steps for compiling code are generally quite straight-forward:
 
 This will build software compiled against packages installed on your system. It's a bit more complicated when packaging as we first set up an environment to compile in (Part 1). But even then you have many choices to make and each can have an impact on how long it takes to compile the code. Do you build with Link Time Optimizations (LTO) or Profile Guided Optimizations (PGO), do you build the package for performance or for the smallest size? Then there's packages that benefit considerably from individual tuning flags (like `-fno-semantic-interposition` with `python`). With so many possibilities, `boulder` helps us utilize them through convenient configuration options.
 
+<!-- excerpt -->
+
 ## What Makes boulder so Special?
 
 As I do a lot of packaging and performance tuning, `boulder` is where I spend most of my time. Here are some key features that `boulder` brings to make my life easier.

src/content/docs/blog/2021/10/04/optimal-file-locality/index.md

@@ -18,6 +18,8 @@ To test the efficiency our content payload, the natural choice was to compare it
 
 Of course it does (otherwise it would be a pretty crappy blog post!). When extracting a `.stone` package it creates two directories, `mossExtract` where the sha256sum named files are stored and `mossInstall` where those files are hardlinked to their full path name. The first day I created the tarball from `mossInstall` and the second day I realised that creating the tarball from `mossExtract` would provide the closest match to the content payload since it was a direct comparison. When compressing the tarballs to match the `.stone` compression level, the tarball compressed from `mossInstall` was 10% smaller, despite the uncompressed tarball being slightly larger.
 
+<!-- excerpt -->
+
 ## Compression Wants to Separate Apples and Oranges
 
 In simplistic terms, the way compression works is comparing data that it's currently reading versus data that it's read earlier in the file. `zstd` has some great options like `--long` that increases the distance in which these matches can be made at the cost of increased memory use. To limit memory use while making compression and decompression fast, it takes shortcuts that reduce the compression ratio. For optimal compression, you want files that are most similar to each other to be as close as possible. You won't get as many matches from a text file to an ELF file as you would from a similar looking text file.

src/content/docs/blog/2021/11/05/performance-corner-faster-builds-smaller-packages/index.md

@@ -27,6 +27,8 @@ Payload: Content [Records: 2550 Compression: Zstd, Savings: 81.46%, Size: 236.72
 
 The build time is a little high, but a lot of that is due to a slow compiler on the host machine. But analysing and producing packages was also taking a lot longer than it needed to.
 
+<!-- excerpt -->
+
 ## The Death of moss-jobs in boulder
 
 In testing an equivalent build outside of `boulder`, the build stages were about 5% faster. Testing under `perf`, the jobs system was a bit excessive for the needs of `boulder`, polling for work when we already know the times when parallel jobs would be useful. Removing `moss-jobs` allowed for simpler codepaths using multiprocessing techniques from the core language. This work is integrated in `moss-deps` and the excess overhead of the build has now been eliminated.

src/content/docs/blog/2021/11/23/it-all-depends/index.md

@@ -20,6 +20,8 @@ As such we encode dependencies into our (endian-aware, binary) format which is t
 
 Lastly, we'll always ensure there is no possibility for "partial update" woes. With these considerations, we have no need to support `>=` style dependencies, and instead rely on strict design goals and maintainer responsibility.
 
+<!-- excerpt -->
+
 ## First and foremost!
 
 The rapid move we're enjoying from concept, to prototype, and soon to be fully fledged Linux distribution, is only possible with the amazing community support. The last few months have seen us pull off some amazing feats, and we're now executing on our first public milestones. With your help, more and more hours can be spent getting us ready for release, and would probably help to insulate my shed office! (Spoiler: its plastic and electric heaters are expensive 😀)

src/content/docs/blog/2021/12/14/performance-corner-small-changes-pack-a-punch/index.md

@@ -10,7 +10,6 @@ copyright: "Copyright © 2021 aerynOS Developers"
 
 Here we have another round of changes to make packages smaller and show just how much we care about performance and efficiency! Today we are focusing mainly on `moss-format` changes to reduce the size of its payloads. The purpose of these changes is to reduce the size of packages, DB storage for transactions and memory usage for `moss`. These changes were made just before we moved out of bootstrap, so we wouldn't have to rebuild the world after changing the format. Lets get started!
 
-
 ## Squeezing Out the Last Blit of Performance
 
 `Blitting` in Serpent OS is the process of setting up a root, using hardlinks of files installed in the `moss` store to construct the system `/usr` directory. Some initial testing showed `buildPath` using about 3% of the total events when installing a package with many files. As a system is made up of over 100,000 files, that's a lot of paths that need to be calculated! Performance is therefore important to minimize time taken and power consumed.
@@ -29,6 +28,8 @@ After:
    12,814,283 ( 0.40%)  /usr/include/dlang/ldc/std/range/package.d:pure nothrow @safe immutable(char)[] std.path.buildPath
 ```
 
+<!-- excerpt -->
+
 ## Only Record What's Needed!
 
 Our `Index Payload` is used for extracting the `Content Payload` into its hashed file names. As it has one job (and then discarded), we could hone in on including only the information we needed. Previously an entry was a 32 byte key and storing a 33 byte hash. We have now integrated the hash as a `ubyte[16]` field, cut other unneeded fields so that we can fit the whole entry into 32 bytes. That's a 51% reduction in the size of the `Index Payload` and about 25% smaller when compressed.

src/content/docs/blog/2022/01/20/can-hardly-contain-myself-plus-a-bonus/index.md

@@ -20,6 +20,8 @@ Containers have a multitude of uses for a Linux distro, but our immediate use ca
 
 The next step is integrating `moss-container` into `boulder`, so that builds become reproducible across machines, and makes it much easier for users to run builds on their host machines.
 
+<!-- excerpt -->
+
 ## moss Now Understands Repositories
 
 Previously (but not covered in the blogs) work was also done on `moss` so that it can understand and fetch `stone` packages from an online repo. This ties in nicely with the `moss-container` work and is a requirement for finishing up a proper build process for Serpent OS. We are now one step closer to having a full distribution cycle from building packages and pushing those packages as system updates!

src/content/docs/blog/2022/02/11/making-deltas-great-again-1/index.md

@@ -16,6 +16,8 @@ I remember back in the early 2000s on Gentoo when someone set up a server to pro
 
 Today things are quite different. The case for deltas has reduced for users as internet speeds have increased. Shrinking 20MB off a package size may be a second reduction for some, but 10 seconds for others. The largest issue is that deltas have typically pushed extra computational effort onto the users computer in compensation for the smaller size. With a fast internet connection that cost is a real burden where deltas take longer to install than simply downloading the full package.
 
+<!-- excerpt -->
+
 ## What's so Bad About the Old Method?
 
 The previous idea of using the full payload for deltas was very efficient in terms of distribution, but required changes in how `moss` handles packages to implement it. Having the previous payload available (and being fast) means storing the old payloads on disk. This increases the storage requirements for the base system, although that can be reduced by compressing the payloads to reduce disk usage (but increasing CPU usage at install time).