Add posts/2024/why-chimera-linux.md

v2/content/posts/2024/why-chimera-linux.md

@@ -1,13 +1,13 @@
 +++
 title = "Why Chimera Linux"
-date = 2024-07-04T08:48:55+10:00
+date = 2024-07-03T21:09:53+10:00
 
-[extra]
+#[extra]
-updated = 2024-07-04T12:24:30+10:00
+#updated = 2024-06-04T07:49:36+10:00
 +++
 
 I received a reply to my [Tech Stack 2024](@/posts/2024/tech-stack/index.md)
-post asking: Why Chimera Linux? I wrote a response that turned out longer than
+post asking: Why Chimera Linux? I wrote a reply that turned out longer than
 anticipated and figured I may as well post it here too. I'm not trying to
 convince you to use Chimera with this post, just note down why it appeals to
 me. That's really the crux of it: there's dozens of distros out there all with
@@ -16,8 +16,6 @@ something else.
 
 <!-- more -->
 
-Below is a lightly edited version of my email response.
-
 ---
 
 I like [Chimera Linux] because it's the closest distro I've found to what I would build
@@ -25,7 +23,7 @@ if I was building my own (something I've tinkered with a few times over the
 years).
 
 I like that it is a comparatively small and easy to understand system without
-giving up quite as much as you do with Alpine Linux, which to be clear, I like
+giving up quite as much as you do with Alpine Linux, which to be clear I like
 as well and use on my server. The [userland from FreeBSD][userland] is capable and easy
 to understand code wise, [Dinit] provides an init system with process monitoring,
 dependency tracking, and a service file format that doesn't require writing
@@ -35,14 +33,14 @@ closely to the POSIX standard. See the recent OpenSSH vulnerability where
 [remote code execution was not possible on musl based systems](https://fosstodon.org/@musl/112711796005712271).
 
 I really like the [cbuild] system for building packages. It uses a real
-programming language (Python) to define packages and share library code. This
+programming language (Python) to define packages and share library code, which
-makes package templates easier to write and understand over Make and shell
+makes them easier to write and understand over Make and shell based packaging
-based packaging systems. Packages are built in an isolated sandbox, preventing
+systems. Packages are built in an isolated sandbox, preventing them depending
-them depending on the host system accidentally—this is definitely an advantage
+on the host system accidentally—this is definitely an advantage over building
-over building packages on Arch. Most run-time dependencies are automatically
+packages on Arch. Most run-time dependencies are automatically determined so
-determined so you don't have to list all those out in the package template.
+you don't have to list all those out in the package template.
 
-[apk] is fast (although not as fast as Pacman when doing updates[^1]). It has a
+[apk] is fast (although not as fast as Pacman when doing updates). It has a
 clever way of tracking packages where [the world file][world] specifies all the packages
 that should be present and it uses a solver to determine what needs to be
 installed/removed. The neat bit is that when you `apk del` a package it can remove all
@@ -51,24 +49,19 @@ to end up with orphaned packages that are dead weight and require [manual
 maintenance to clean up](https://wiki.archlinux.org/title/Pacman/Tips_and_tricks#Removing_unused_packages_(orphans)).
 
 Chimera is also a rolling distro (like Arch) so things stay up to date. There's
-a low barrier to submitting new packages and updates, you don't have to have a
+a low barrier to submitting new packages and updates, you don't have to be a
-special "committer" or "developer" account, you can just open a pull request
+special "committer", you can just open a pull request. Packages in the repo are
-like any other open-source project. Packages in the repo are built
+built automatically with a build bot server for all supported architectures,
-automatically with a build bot server for all supported architectures, whereas
+whereas I believe Arch is still working towards automated packaging.
-I believe Arch is still working towards automated packaging. Additionally first
+Additionally first class support for multiple CPU architectures allows me to
-class support for multiple CPU architectures allows me to run the same system
+run the same system on different devices I use such as Raspberry Pis, RISC-V
-on different devices I use such as Raspberry Pis, RISC-V single board
+single board computers, and hopefully eventually my new ARM based Snapdragon X
-computers, and hopefully eventually my new ARM based Snapdragon X Elite laptop.
+Elite laptop.
 
 Having written that all out I guess Chimera feels like a distro that is
 full-featured but also simple enough that you can poke around and understand
 all the parts. It's also easy to get involved with the project.
 
-[^1]: Pacman downloads in parallel (5 at time in my config), then does the actual upgrades. `apk` fetches one package at at time and then stages the upgrade before moving on to the next one. There's a couple of related open issues:
-
-      - <https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10963>
-      - <https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/5977>
-
 [cbuild]: https://github.com/chimera-linux/cports/blob/master/Usage.md
 [cports]: https://github.com/chimera-linux/cports
 [musl]: https://musl.libc.org/