
NOTE: The beginning of this post is a bit of a narrative/celebration of The
Ridge Podcast. The technical part/tutorial starts with the second heading.

## The Ridge Podcast Turns 3

In a few months, [The Ridge Podcast](https://theridgepodcast.com) will turn 3
years old. In case you're not familiar, it is a show focused on interviews from
the Blue Ridge/Appalachian area. Some guests include local officials, educators,
business owners, historians, and people willing to share their stories. Episodes
touch on local politics, community service, culture, history, education, faith,
and more. Some notable guests include [John Reid](https://theridgepodcast.com/podcast/99-john-reid-republic-candidate-for-lieutenant-governor-politics-campaigning-platform-family/),
[Beth Macy](https://theridgepodcast.com/podcast/49-beth-macy-dopesick-roanoke-times-factory-man-writing-journalism-research/),
[Morgan Griffith](https://theridgepodcast.com/podcast/27-us-congressman-morgan-griffith-law-school-politics-family-coal-energy-insurance-advice/),
[Sam Bush](https://theridgepodcast.com/podcast/45-sam-bush-musician-bluegrass-grammys-mandolin-fiddle-singing-new-grass-revival/),
[Walter Rugaber](https://theridgepodcast.com/podcast/34-walter-rugaber-journalism-new-york-times-roanoke-times-richard-nixon-northwestern-georgia-watergate-civil-rights-humanities/),
[John Bennardo](https://theridgepodcast.com/podcast/15-john-bennardo-wheel-of-fortune-hollywood-afv-author-film-director-2-bill-just-a-typo-film-school/),
and so many [more](https://theridgepodcast.com/podcast/).

This labor of love has been an incredibly important part of mine and my co-host's
life. It has connected us to countless amazing people and allowed us to share
their stories with others. Additionally, the podcast serves as an archive for
future generations. The podcast's role as an archive became more obvious to us
after a guest unexpectedly passed away. Afterwards, we made it a point to
interview family members and those close to us.

Throughout the podcast's life, I have also served as the webhost, editor,
producer, funder, and social media manager. Being a small production means that
I quickly had to learn to wear many hats. The show's size also means that, when
starting, I did not have the skills or knowledge to create the website of my
dreams. We just needed something up and working. Fortunately, Wordpress and its
plugin ecosystem has served the show well for almost 3 years now. That being
said, Wordpress is a bit inflexible and rigid—it also has some pretty
detrimental performance issues that undoubtedly impact our listener's
experience, as well as Search Engine Optimization and indexing. Finally, the
podcasting plugin I use does not support some of the new [podcasting 2.0](https://podcasting2.org/)
tags that I would like to take advantage of.

Given the show's maturity and my increased abilities as a developer and
designer, I figure it is about time The Ridge Podcast gets a new website. Now
that winter break is here and I have some free time, it is time to get to work.

## Why Cloudflare R2, NextJS, and MDX?

In the old Wordpress setup, all files were served directly from my server's
filesystem and sent to listeners—regardless of where and when they were
listening. While my Wordpress setup had simple redis caching, it lacked a CDN.
Given that my server is located in the basement of my childhood home on a
less-than-amazing satellite connection and then served over a Wireguard tunnel
to a VPS in NYC, streaming speeds left a bit to be desired. Additionally, I
found Wordpress's UI hard to navigate and overly bloated. Also, the stateful
nature of Wordpress made me nervous. What if a bad plugin or Wordpress update
ruins my database? Sure, I have backups and can revert, but its annoying and
time-consuming.

After a few days of ruminating (and boredom while being home for break) on
these issues, I've come up with the following solution: use Cloudflare R2 to
cache the podcast episodes and serve them over a CDN while using MDX files to
store metadata. To explain, whenever I want to publish a new episode, I will
add a .mdx file to my podcast episodes directory and write its title,
description, etc. From there, NextJS will build the mdx files and serve them as
static html. This way, I can reduce the amount of state/media on my own
servers. All of the written content will be declaratively written to be stored
in a git repository. While uploading the file to Cloudflare R2 could be done
manually, I will most likely write a script to automate it as well as the post
creation process. This stateless model is pretty common for blogs and there are
numerous examples online of using mdx + nextjs to create a blog. I'm just taking
it a step further!

I chose Cloudflare R2 because it is relatively cheap (compared to Amazon S3!)
and I am most familiar with it. In my position as a Technology Board member at [The Harvard Crimson](https://www.thecrimson.com/),
I recently helped migrate our site from Amazon S3 to Cloudflare R2. Given this
experience, I was impressed by R2's pricing and quality. While there are
probably easier, simpler, or cheaper ways to achieve my setup, I would like to
learn S3-compatible storage and I don't mind paying a few dollars a month
(on top of everything else) to learn and have fun.

## Migrating to Cloudflare and R2

### Cloudflare DNS

In order for the caching to properly work in the future, I also need to give
Cloudflare control over theridgepodcast.com's DNS. Like always, Cloudflare's
documentation made this super simple (noticing a pattern? Go Cloudflare!).
They have a [tool that imports](https://developers.cloudflare.com/fundamentals/manage-domains/add-site/)
all of the A, CNAME, MX, etc records into their system. After they were
imported, I went to my domain registrar (hover.com) to change my NS records to
Cloudflare's servers. Because I manage my own SSL/TLS certificates with Nginx
Proxy Manager, I had to also set Cloudflare's encryption mode to `Full (Strict)`.
Oddly enough, I also had to go to Nginx Proxy Manager and request a new
certificate. I'm still not exactly sure why. I would've thought my old
certificate would have worked? Anyways, after doing those two things I had
successfully switched over.

### R2

My first step was to migrate all of the podcast media to Cloudflare R2.
Thankfully, this was pretty straighforward. There is some really amazing
tooling around S3-compatible storage backends and the documentation for it is
superb. After creating my Cloudflare account and enrolling in R2, I created
a Standard Bucket called `theridgepodcast-media` and account API tokens to
start tinkering with R2 and its features. Cloudflare has a really nice guide
on [using the official AWS S3 JavaScript SDK with Cloudflare R2](https://developers.cloudflare.com/r2/examples/aws/aws-sdk-js-v3/).
After verifying its functionality, I started copying podcast episodes to the
bucket with rclone. Again, Cloudflare has a great guide [to configure](https://developers.cloudflare.com/r2/examples/rclone/)
and [to use](https://developers.cloudflare.com/r2/objects/upload-objects/)
rclone. After running `rclone config`, and navigating through the menus to
select Cloudflare R2 support, I ran `rclone copy -vvvvv ./audio/ r2:theridgepodcast-media`
to copy all of my podcast audio files (in the `audio` directory) to the bucket.
A half an hour later, all of my episodes are in the bucket. Easy as pie!

I also had to add a subdomain for my bucket `theridgepodcast-media`. While it
is technically possible to use the public development url, it is discouraged and
prevents proper caching. Cloudflare's [guide explains the steps](https://developers.cloudflare.com/rules/origin-rules/tutorials/point-to-r2-bucket-with-custom-domain/).
After, `media.theridgepodcast.com` pointed to the bucket
`theridgepodcast-media` where episodes are stored.

## Figuring Out Feeds and Exporting Content

Obviously, there is other data that I am interested in exporting and preserving.
For example, the post descriptions, episode titles, publish dates, and more are
reusable and valuable content. After writing a simple Python script with the
[feedparser library](https://github.com/kurtmckee/feedparser), I had all of that
content exported into a folder of .mdx files roughly following this format:

<SyntaxHighlighter language="yaml">
{`
---
title: "#XX - My Really Interesting Podcast Title"
date: '2024-08-17T10:00:00+00:00'
categories:
- books
- history
- reading
- podcasting
speakers:
- ethan-carter-edwards
- my-interesting-guest
guid: 3n4s52q3-1op1-0sn6-nrnr-571r185o630o
---

Blah blah blah this is my content!
`}
</SyntaxHighlighter>

My script did make a few mistakes (mostly regarding encoding special characters
like ò or '"') that I had to clean up manually, but other than that it was a
quick process.

One important datapoint I lost in the export with feedparser was my curated
speaker/guest list. My podcasting Wordpress plugin allowed me to add a speaker
to every single episode. I was on all of them, Luke was on many, and each guest
was on their respective episode(s). For guests that have been on the show
several times, sorting by speaker allowed site visitors to find episodes easier.
I was not willing to give up this information, so I dumped the mariadb database
and wrote a script that automatically added speakers to the correct episodes.
After a bit of manual cleanup, the data had been migrated.

One unexpected source of frustration was the episode GUID. For those
unfamiliar, each episode has a globally unique GUID that allows podcast sites
like Spotify, Apple Podcasts, or whoever else, to keep track of podcast
episodes even if their titles, files, or descriptions change. This means that
users don't lose their progress or have to redownload an entire file if a typo
is fixed in the description.

Unfortunately, the Wordpress plugin I was using created the GUID's in a bit of
an awkward format: a link (that doesn't resolve, mind you) to the website that
the feed is hosted on. When researching what the GUID does and why changing it
is not recommended, I became quite frustrated. Recently, however, the developer
of the plugin decided recently that he was going to start using [uuidv5](https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions_3_and_5_(namespace_name-based)).
This is a completely reasonable decision (and what I will use for my uuid's
going forward), but it is frustrating that there are two different schemas in
the same feed. Because there is not a way to consistently calculate the episode
GUID, I have to hardcode it into each .mdx file. While this works, it is ugly.

## Generating HTML from MDX

Once all the episode content was exported from my old feed and imported into
my new mdx format, I needed a way to turn the mdx file into html to be rendered
and to go in the podcast RSS feed. In the past, I have used [next-mdx-remote](https://github.com/hashicorp/next-mdx-remote)
on my personal website (this one!) and decided to stick with what I know.

For rendering the HTML on a page, this works great! Simply pass the serialized
content into the `<MDXRemote />` component and it renders. Some rough pseudocode below:

<SyntaxHighlighter language="javascript">
{`
    const components = { PodcastTrailer };

    const frontMatter = post.frontMatter;
    const source = await serialize(post.content);

    return (
        <div>
            <MDXRemote {...source} components={components} />
        </div>
    );
`}
</SyntaxHighlighter>

I'm even able to pass in a component, PodcastTrailer, to the renderer. This is
a component that allows me to reduce duplicate text across all of the episode
descriptions. For example, at the end of every episode description I want to
include links to the podcast website, Facebook page, YouTube, etc—the trailer.
Over time, this trailer has changed. For example, I used to not have a podcast
Bluesky account. It would have been a huge pain to go through every podcast
description and add the link, so I never did. Now, I can just edit the component
and the next time I deploy the site, all of the episodes will have the new trailer.

Generating the HTML for the podcast feed, however, was a bit more complex. For
whatever reason, the next-mdx-remote library does not expose an API that generates
the HTML that the MDXRemote function generates. For that reason, I had to do a little
hack:

<SyntaxHighlighter language="javascript">
{`
async function mdxToHtml(mdxContent) {
    const source = await serialize(mdxContent);
    return renderToStaticMarkup(
        React.createElement(MDXRemote, { ...source, components })
    );
}
`}
</SyntaxHighlighter>

But it works, so is it really a hack? ;) Figuring this out was actually really
satisfying as a few years ago I tried to create a podcast feed for this website
but ran into the same issue. Now that I have this in my back pocket, I will be
sure to revisit the idea and start offering a real RSS feed for the content in
this blog!

## RSS/Podcast Feed Generation

Generating the podcast RSS feed was probably the hardest part about this entire
project. Figuring out what tags I needed to transfer over and manually create
in order to not break existing subscriber's feeds was an ordeal. Also, the
Wordpress plugin I used did not support many of the new podcasting 2.0 features
like the `podcast:person` tag, which can be used to define interactive cards for
hosts and guests on some podcast apps. I learned they existed as a part of this
project.

Podcast RSS feeds are generated with XML. Instead of manually creating the feed
myself, I decided to use an npm library called [podcast](https://www.npmjs.com/package/podcast).
While it handled a lot of the boilerplate, I found that it lacked some of the
features (like fht `podcast:person` tag, for example) that I needed. Another
crucial feature it lacked was the ability to lock a podcast by adding the
locked tag, which prevents unauthorized imports. Or another one is the setting
the feed GUID, which functions similarly to episode GUIDs. It also creates some
deprecated tags that are no longer used by podcast readers.

To actually add podcast episodes to the feed, I just loop through the podcast
episodes directory (where the mdx files are) and use the frontMatter/content to
populate its fields. There's also some data fetching which I'll touch more on
later.

While I paint a negative picture of the library here, it does its job well. It
just lacks a few features I think modern podcast feeds need. Thankfully, it
supports the `customElements` field which allowed me to add the tags that the
library lacked by default. In the future, I would like to fork the library and
add the features I need. Surely, I'm not the only person in the world who needs
them?

## Future Improvements

I did not mention this earlier in the article, but when I was telling my
friends about this project they all encouraged me to avoid NextJS and to use
SvelteKit or Astro. While researching for the project, I came to the conclusion
that they probably would have been better for this project, but I really enjoy
(and am already familiar with) working with Next, so I decided to stick with
it. That being said, I made a few suboptimal design choices.

The first (and probably most egregious) one is that I am using the old, mostly
deprecated, pages router instead of the new app router. My personal website
uses it, so I was familiar with it. Also, I'm really not a fan of directory
based routing with a page.ts or whatever. Having 20 page.ts files open is
really annoying. I much prefer having an about.ts, index.ts, contact.ts, etc
files. But whatever. In the future, I plan to make the migration.

Additionally, I did not use NextJS's official MDX library: [@next/mdx](https://nextjs.org/docs/pages/guides/mdx). From some brief reading,
it seems like it would've solved my problem with producing HTML output for the
RSS feed. Also, it seems next-mdx-remote development has mostly stalled.
Migrating would probably be smart, so its on the TODO list!

Similarly, I took advantage of a library for some SEO stuff: [next-seo](https://github.com/garmeeh/next-seo).
From my understanding, it was originally designed for the pages router.
However, now that the app router is recommended, it has less support. Also, it
seems like the app router handles a lot of SEO stuff automatically nowadays, so
this library may not even be necessary once I migrate. TODO!

Also, currently the process to create a new episode is painfully manual: create
an mdx file, add the title, upload the mp3 to cloudflare using rclone or the
Web UI, and then deploy the newly generated docker image onto my server. Soon,
I will write a simple little javascript or python script that has a nice,
interactive interface that will upload the mp3 for me and automatically create
the .mdx file with the fields I input. This will take like 15 minutes.

Alternatively, I may just create an authenticated page where hosts/owners can
login and upload a file and write a title, description, etc. This would be
helpful when I decide to commercialize this product (which may be soon). I will
probably end up doing this.

In any case, the script that generates the podcast feed is quite slow. Instead
of storing episode duration and size information in the .mdx file, I have the
script fetch that information from the file during each build. This operation
isn't cached. Obviously, for 100+ episodes, this takes a solid 45 seconds and
is annoying. I'm debating if I should just store the information in the .mdx
files because the audio files rarely change (it does happen, though) or if I
should just parallelize this operation. I would learn more if I parallelized
it, so maybe that'll be it.

Finally, because this site is completely static and has very little client side
JS or server side JS, I do not collect any listener statistics. To solve that,
I am thinking about writing a middleware layer that passes through the podcast
audio files. Maybe something along the lines of an endpoint
`/podcast-download/[slug].mp3` that then connects to a database somewhere and
increments a counter. Or maybe just a text file. Who knows. I don't need or
want anything fancy, just an idea of how many listens each episode gets that I
can track over time. That's a problem for later me!



Using Cloudflare R2 to host theridgepodcast.com!

Building a podcast site with Cloudflare R2, NextJS, and MDX

## Background

I have been a long time Linux user (since March of 2020, guess why? ;) ). Part
of the reason I began to use Linux and continue to use it is the increased security
and privacy that it offers. Not only am I confident that Microsoft, Google, or Apple
is not spying on me, but I am afforded the ability to take my security into my own hands.

While there are a number of strategies to enhance a computer's software security like utilizing
SELinux, AppArmor, or hardening the SSH configuration, few measures protect a computer
from physical tampering like disk encryption does. It does not matter how secure a device's
software stack is if it is physically compromised. Full disk encryption is the easiest way 
to protect against low effort but high-yield physical attacks. Using LUKS encryption is the
easiest way to do that. LVM on top of it allows me even more flexibility with how I organize my data.

As I prepare to start my studies at Harvard University, I anticipate the unfortunate
reality that I may somehow lose my laptop or that my laptop is taken, intentionally or not.
By securing my device with encryption, I am protecting myself against unauthorized data access.
Additionally, using NixOS allows me to verify that my configuration is as it seems. Any change
to my system would be overwritten by my declarative NixOS configuration switching. Also, using
NixOS allows me to easily replicate my system configuration across multiple devices and quickly
reinstall my system in the event of a theft or drive failure. I'll stop evangelizing and start
explaining now.

As a general warning, this article will be fairly technical. I will assume that the readers
know the basics of filesystems and disk partitioning, but will explain the disk encryption-
and NixOS-specific content. Also, these steps are specific to my 11th Gen 13" Framework with an
NVMe drive. Other computer's specifics may vary.

A more advanced and NixOS-like solution may be an encrypted ZFS root with [impermanence](https://grahamc.com/blog/erase-your-darlings/), however
LVM on LUKS is the more traditional way to accomplish the same goal. Additionally, I am much more
comfortable with LVM, LUKS, and ext4 than I am with ZFS. Neither is better or worse, just different.

## The Disk

The process for preparing the disk is pretty uniform across distributions. I learned much of this
from the Arch Wiki when I used Arch Linux full time. Skilled Linux users can probably skim this section
and start at the NixOS section.

We'll start by partioning my disk into two parts with `fdisk /dev/nvme0n1`:
1. 1G partition with Type 1: `UEFI boot`
2. Remaining free space with Type 23: `Linux x86_64 root`

The first partition will be the unencrypted `FAT32` UEFI boot partition. The second will be the
the LUKS encrypted partition that will be organized with LVM. However, before we start using
LVM or formatting filesystems, we must actually encrypt and unlock our disk. I suggest adding
labels to make configuring the NixOS hardware settings easier later.

<SyntaxHighlighter language="bash">
{`
cryptsetup luksFormat --label=NIXOS_LUKS /dev/nvme0n1p2
cryptsetup luksOpen /dev/nvme0n1p2 cryptlvm
`}
</SyntaxHighlighter>

After unlocking the encrypted partition and mapping it to the `cryptlvm` name, we can create
our LVM Physical Volumes (pv), Volume Groups (vg), and Logical Volumes (lv). While understanding how each works
is not vital for setting up the system, I encourage the reader to research each topic in more detail
at the [Arch Wiki](https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Preparing_the_logical_volumes) 
and [Digital Ocean](https://www.digitalocean.com/community/tutorials/an-introduction-to-lvm-concepts-terminology-and-operations).

Now is a good time to mention why we are using LVM when LUKS handles all of our encryption needs.
LVM is the Logical Volume Manager (LVM) for Linux. LVM allows us to create multiple logical
partition-like volumes under the encrypted LUKS partition. This means that we could have lv's for
home partitions, root partitions, var partitions, etc. Here, I am choosing to create lv's for a
swap partition and a root partition.

Please note that I am leaving `256M` at the end of the lv to allow for using `e2scrub` with `ext4`.

<SyntaxHighlighter language="bash">
{`
pvcreate /dev/mapper/cryptlvm
vgcreate NIXOS_LVM /dev/mapper/cryptlvm
lvcreate -L 16G -n SWAP NIXOS_LVM
lvcreate -l 100%FREE -n ROOT NIXOS_LVM
lvreduce -L -256M NIXOS_LVM/ROOT
`}
</SyntaxHighlighter>

After setting up LVM, we can start formatting the volumes. I am electing to use `ext4`
because I am confident in it and am very familiar with it. I believe using other file systems
like `xfs` would be possible too. `FAT32` is required for UEFI boot partitions, so that makes
our decision easy! After formatting the drives, we can mount them. This is all pretty standard stuff. 

Please note that again I am using labels to make things easier on myself later.

<SyntaxHighlighter language="bash">
{`
# formatting
mkfs.fat -F32 -n BOOTFS /dev/nvme0n1p1
mkswap -L SWAPFS /dev/NIXOS_LVM/SWAP
mkfs.ext4 -L ROOTFS /dev/NIXOS_LVM/ROOT
# mounting
swapon /dev/NIXOS_LVM/SWAP
mount /dev/NIXOS_LVM/ROOT /mnt
mount --mkdir /dev/nvme0n1p1 /mnt/boot
`}
</SyntaxHighlighter>

Now our disk is fully setup. Let's start the NixOS installation!

## NixOS

Thankfully, this part is pretty simple thanks to NixOS's tooling. We generate the
config (and I prefer a flakified version), make edits where necessary, and then install. 
After installing, we enter the system and can start editing our config in more detail if
necessary.

<SyntaxHighlighter language="bash">
{`
nixos-generate-config --root /mnt --flake
$EDITOR /mnt/etc/nixos/configuration.nix
nixos-install --root /mnt --flake /mnt/etc/nixos#nixos
nixos-enter --root /mnt
`}
</SyntaxHighlighter>

Below, I would like to point out some required additions to the config to ensure
that the bootloader is configured to correctly handle LVM on LUKS on reboot.

<SyntaxHighlighter language="nix">
{`
{
    # ensures the systemd boot loader is installed
    boot.loader.systemd-boot.enable = true;
    boot.loader.efi.canTouchEfiVariables = true;

    # IMPORTANT: without these additions the LUKS device will not be found
    # and therefore decrypted, making boot fail
    boot.initrd.kernelModules = [ "dm-snapshot" "cryptd" ];
    boot.initrd.luks.devices."cryptroot".device = "/dev/disk/by-label/NIXOS_LUKS";

    # the system will automatically generate these but will use uuid's instead of
    # labels. Labels provide more flexibility and allow for an easier reinstall.
    fileSystems."/" =
        { device = "/dev/disk/by-label/ROOTFS";
          fsType = "ext4";
        };

    fileSystems."/boot" =
        { device = "/dev/disk/by-label/BOOTFS";
          fsType = "vfat";
          options = [ "fmask=0022" "dmask=0022" ];
        };

    swapDevices =
        [ { device = "/dev/disk/by-label/SWAPFS"; }
        ];
}
`}
</SyntaxHighlighter>


Installing NixOS on LVM on LUKS

## Why do we care about Git Rebase?

While `git rebase` is probably an intermediate to advanced git topic, every developer
should learn how to use it. This is even more so true for contributors to Nixpkgs and
the Linux Kernel. As I prepare to be an Outreachy mentor, I was thinking about ways I
can help my mentees with the developer soft skills that are not necessarily taught in
any Computer Science course or video but are essential and good software development
practices. Learning to use `git rebase` is one of those skills!

## What is Git Rebase?

Essentially, `git rebase` is a way to manipulate and edit git histories. A common
use case is reordering a series of commits. In Nixpkgs this is commonly used for new
contributors who try to submit a package. They successfully create a derivation and
build the package but do not add themselves as the maintainer. Then, a reviewer comes
along and asks them to add themselves as a maintainer, and they do so, but as a
separate commit. However, according to the style guidelines (and to not break
git-bisect, but that is for another post), the maintainer commit needs to be first in
the series. I recently reviewed a [PR with this exact problem](https://github.com/NixOS/nixpkgs/pull/389852 "Use of Git Rebase in the wild!"), and it inspired me to
write this post!

Another use case in Nixpkgs is when someone submits a PR adding a package or updating
something, and a reviewer asks them to make a change. According to the style guidelines,
creating a package should happen in one commit with a commit message of `anakron: init at 0.3.1`
However, most new contributors will make subsequent commits, which in theory is a good idea!
It just is not what the style guide calls for. The preferred course of action is to make
the suggested changes locally and then use `git rebase` to squash them and then force push
the branch for the reviewer to respond to.

This scenario applies to Linux Kernel development as well. I recently posted an 8 patch series
[introducing APFS support](https://lore.kernel.org/lkml/20250314-apfs-v1-0-ddfaa6836b5c@ethancedwards.com/ "APFS Patch Series") to the Linux Kernel. There are over 26K lines of code within
the patch set. Inevitably, the code reviewers will want me to make changes to the code for
the next series. Instead of making a commit for each change and taking the series from 8 patches
to potentially 20 or more, I can use `git rebase` and squash all the changes into the initial
commit where the files are introduced. It can get complicated and hard to track, but the
alternative, starting from scratch with a new series of commits, is worse!

## How do I use Git Rebase?

Since this post is written with my Outreachy mentees in mind, I will provide an example
for using `git rebase` within Nixpkgs. I recently packaged a [TUI tetris clone called `yetris`](https://github.com/NixOS/nixpkgs/pull/388319 "Yetris PR")
as part of my efforts to package [TUI/retro games in Nixpkgs](https://github.com/NixOS/nixpkgs/issues/380688 "Issue Tracker").
I had the program building and it could be run, but instead of changing the directory where
the package is installed I copied the package to `$out/bin/`. While this solution works,
it is hacky in that two copies of the binary would be included in the final build, wasting
space, and that I could instead use `makeFlags` to redirect the install directory. I had
already committed the package:

<SyntaxHighlighter>
{`
commit 18b222d5cba16d200a61f876a7d05db112bb1a3b (HEAD -> master)
Author: Ethan Carter Edwards <ethan@ethancedwards.com>

    yetris: init at 2.1.0

    Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
`}
</SyntaxHighlighter>

A reviewer came by and suggested that I use `makeFlags` to redirect it instead. I made
the changes and committed them, but then I had separate commits!

<SyntaxHighlighter>
{`
commit 21025f648cb730caa783954d063d3990f7d1ca1e (HEAD -> master)
Author: Ethan Carter Edwards <ethan@ethancedwards.com>

    yetris: use makeFlags to redirect install location

    Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>

commit 18b222d5cba16d200a61f876a7d05db112bb1a3b
Author: Ethan Carter Edwards <ethan@ethancedwards.com>

    yetris: init at 2.1.0

    Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
`}
</SyntaxHighlighter>

Once I was confident that my package was building and my changes were correct, I ran
`git rebase -i HEAD~2`. While this command may seem scary, it is pretty simple once
it is broken down and explained. `git rebase` tells git we want to start rebasing.
`-i` means we want to do it interactively. `HEAD~2` means we want to start at the HEAD
of the repository (which means the most up-to-date commit, in this case), and go back `2`
commits. Once running the command, we are presented the `todo` screen.

<SyntaxHighlighter>
{`
pick 18b222d yetris: init at 2.1.0
pick 21025f6 yetris: use makeFlags to redirect install location
`}
</SyntaxHighlighter>

Here we see a few important pieces of information. Command `pick` means we will keep the
commit after rebasing. It is followed by the commit ID. You will noticed that it
matches the longer commit IDs shown above. Then we have the commit messages, which
also match. Depending on your `git` version, a series of comments about the available
commands should be below commits.

While there are tons of different ways to use `rebase`, here we are going to focus
on `pick` and `squash`. Some of the different commands are simple and others are quite
complicated. A simple one is `drop`. It just deletes the commit altogether.
In our case, we want to squash the two commits together.
This just means that we want to combine their changes into one commit. We can do this
by changing `pick` on the second commit to `squash`. We could technically squash additional
commits into this first commit as well. The most commits I have squashed together is
10, but Git supports much larger numbers than that.

<SyntaxHighlighter>
{`
pick 18b222d yetris: init at 2.1.0
squash 21025f6 yetris: use makeFlags to redirect install location
`}
</SyntaxHighlighter>

After saving and exiting (`:wq` in vim), we are given the opportunity to edit our
squashed commits message and log. I recommend removing the commit logs from the squashed
commits, but it is not a hard requirement by any means. After editing the log to reflect
your wishes, save and exit again. Git will squash the commits:

<SyntaxHighlighter>
{`
commit 1398b15ecb5aa80d25ae202b44b09532a1ddfb49 (HEAD -> master)
Author: Ethan Carter Edwards <ethan@ethancedwards.com>

    yetris: init at 2.1.0

    Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
`}
</SyntaxHighlighter>

Notice that our commit ID has changed! That is because this is a totally new commit
with a new set of changes, despite the commit message and log being the same. Git
generates IDs based off the hash of the changes, timestamp, author and committer info,
tree info, and more. Because we created a new commit, the timestamp is different and we
have different changes, resulting in a new commit ID.

If you are interested in learning more about `git rebase` and its internals, I recommend
checking out [https://git-rebase.io/](https://git-rebase.io/. "git-rebase.io tutorial").
As you grow as a developer, maintaining clean git histories is an important skill to have.
`git rebase` is one of many ways to do that.

## Extra bits

While `git rebase` worked here, it was not completely necessary. We could have used
`git commit --amend` to add any staged changes to the previous commit. However, this
only works to edit the previous commit and is not as powerful as rebasing (it allows squashing
`n` many commits). I chose to focus on rebase here because my Outreachy mentees will
need it as a skill.

As a side tangent, you may have noticed the weird `Signed-off-by:` tag on my commit
messages. While Nixpkgs does not formally require them, they are encouraged in the
Free and Open Source community and even required in some projects like the Linux Kernel.
This pattern of "signing off" on code is called the [Developer Certificate of Origin](https://developercertificate.org/). It
basically means that you are guaranteeing that you wrote the code and that you did not
steal it from anyone else. I recommend getting in the habit of adding it to your commits.


Learning Git Rebase for Nixpkgs Development

How to Use Git Rebase

## Linux Kernel Hacking

Ever since I started using Linux in 7th grade, I have been fascinated by and fervently
believed in the Free Software Movement and the projects that emerged as a result. One
of these projects is the Linux Kernel. Started as a small hobby project and to solve
a real problem by developer Linus Torvalds, it is now the most widely used operating
system in the world. While nowadays it is mostly funded and developed by corporations,
non-trivial amounts of development are done by hobbyists and hackers. Some people work
on simple drivers for pieces of hardware that they have that are not yet supported,
while others are trying to bring [Linux to Apple hardware](https://asahilinux.org/ "Asahi Linux").

Naturally, I wanted to join the community of kernel hackers (or contributors). I
found Greg Kroah-Hartman's [video at FOSDEM](https://www.youtube.com/watch?v=LLBrBBImJt4) showing how to write and submit a kernel patch (a fancy word for a piece of code).
For those who do not know, Greg KH is Linus's right-hand man. Greg does it all, and
is one of the most respected members of the kernel community. Also, funnily enough,
while this video was made more than 15 years ago, it is still 100% accurate and relevant.
For better or worse, not many projects can say their development process has remained unchanged for 15 years.

After watching the video, I searched through the directories of projects I was interested
in. At the time, I was familiarizing myself with SELinux, so I looked through the source
tree to try to grok how everything worked and learn the development process. Thankfully,
I was fortunate enough that [Paul Moore](https://paul-moore.com/about), the maintainer of the SELinux subsystem, was
kind and patient enough to take [my code](https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=65d96351b135c2a694814520a6031f3721020ba9 "My SELinux Contribution").
While it did nothing but appease the static code analyzers, it was exciting for 14 year
old me! I had contributed to the most prolific operating system in the world. Due to
SELinux's use in Android, my code runs on billions of devices around the world. ;)

A few weeks after that, I started poking around in the `staging/` directory. This location
folder holds all the drivers that have been submitted and accepted upstream but are not yet
parts of the core kernel. They remain in `staging/` until the code meets style guides and
features are more fully flushed out. This is where most beginner contributors start. I
fixed a few documentation errors in the [comedi driver](https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f6a1a425cbb74f4836f2e21e0110330c65e33ad2).
Greg KH, who I mentioned above, maintains the `staging/` directory. This means that he
was the one who responded to my emails and accepted my code. Pretty neat!

## The Kernel Self Protection Project (KSPP)

Most of my earlier contributions were pretty insignificant. However, I have found a way
to meaningfully contribute needed and valuable security fixes to the Linux Kernel via the Kernel Self Protection Project.
Founded by Google employee [Kees Cook](https://github.com/kees "Kees Cook's GitHub"), the project is dedicated to making the kernel
more secure and more resilient to attacks. Specifically, his work focuses on making
C safer by default and fixing bugs long before they are ever discovered. [Gustavo Silva](https://embeddedor.com/ "Gustavo's website")
is another very active contributor. In fact, he has reviewed some of my code, which
is neat considering his presentations are responsible for my involvement in the KSPP. Thanks, Gustavo!

While I may not have the knowledge to rewrite a driver from scratch to be more
performant or have the skills to reverse engineer Apple hardware, I am capable
of critical thinking and analyzing small sections of code in detail. This is what
the KSPP is about. Most of the changes within the project
are small changes: a few lines of code here or there. Some are as simple as changing a single
character from the `strncpy` function to `strscpy`! But there is a purpose behind
each patch.

There are over 100 open issues on the [KSPP's GitHub tracker](https://github.com/KSPP/linux/issues).
Each one focuses on a different part of the Kernel. While some issues focus on
working towards the enabling of a compiler flag that hardens the kernel, some are
design changes and code changes. One of the easier ones to learn about and understand
is the migration from [open coded arithmetic to helper functions](https://github.com/KSPP/linux/issues/162).
Essentially, instead of using `kzalloc(nr * sizeof(*int), ...)` we should use
`kcalloc(nr, sizeof(*int), ...)`. This change not only increases code readability,
but there are built in protections within `kcalloc` against overflows due to casting or memory weirdness.
This is a really easy way to contribute and make the code verifiably safer and better.

The past few weeks I have sent a litany of patches on to the mailing lists changing
code in the [erofs](https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a78c5c2269e39544fab4140105f55fca4502e915), gpu/drm, scheduler, thermal, and sound subsystems. This has been an excellent way
to practice using tools like `b4`, `git rebase`, writing good commit messages, and
learning the netiquette of email-based workflows. I even found a set of code to
practice sending multiple patches, or a series, at once. I sent [4 patches](https://lore.kernel.org/lkml/20250227-amd-display-v1-0-52a060a78d08@ethancedwards.com/) for
various AMD drivers in `gpu/drm/amd`.

## Getting started

For those who are interested, I recommend watching the above video and reading
the [official kernel documentation](https://docs.kernel.org/process/submitting-patches.html) on contributing.
After cloning the source code, run `git grep -n kzalloc | grep ' \* ' | grep -v ':\s\+\*'`
and find instances of code that can be improved! Sometimes while searching
for KSPP issues to fix, I come across ways to make the code better in other ways.
For example, in the sound subsection I removed more than 30 lines of code by
[combining two functions](https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e576e7843c0d65b82d4092e5b386d9fbf5bc10c3).

So, my final advice for readers who are interested in learning to hack on the
kernel is to jump in! It takes some persistence, especially when learning the
tooling, but the effort is worth it. Find a subsystem that is interesting
and exciting and start poking around. Think of ways to improve code, break it,
fix it, and do it all over again. It is incredibly gratifying and rewarding
to have one's first contribution merged! If this little blog post has inspired
anyone to get started and submit their first patch, please CC me on the email
and I would be more than happy to review it and provide feedback.


Learning Kernel hacking and increasing security, courtesy of the Kernel Self Protection Project!

The KSPP and Linux Kernel Hacking

## Background

I started using Nix and NixOS around four years ago because I appreciated the declarative
nature and features it brought. At the time,
I had an internship with a local web-hosting company and one of the problems we faced was
our bring-up process for provisioning new servers. One of the company's goals at the time
was simplifying the process so that an admin could run one command and we would have a
functional system that could integrate securely with our Docker Swarm.

We explored various tools like simple Bash scripts, more complex Python scripts, and even
Ansible (which is really just a glorified Python script), but each of them presented the
same issue: state. We did not have an easy way to keep track of when things changed.
Further, when we did push a change with Ansible or modified one of our scripts, we could
not guarantee that the change was made on each system without manually checking them
ourselves.

After some research and tinkering, I proposed that we try NixOS. We gave it a try and in a few weeks had switched
over most of the systems. While the company eventually switched back over to Debian, it
proved to be an invaluable experience using Nix in enterprise systems. Its (mostly)
stateless configuration options were exactly what I needed. The configuration files became
the single source of truth for our systems, and we did not have to worry about forgotten
packages and services becoming security vulnerabilities. If it was not in the file, it
was not on the system. This idea was only strengthened when we implemented [impermanence](https://grahamc.com/blog/erase-your-darlings/).

At the same company, we had a variety of custom Docker images for products developed
in-house and others with some slight modifications for popular pieces of software like
WordPress. One of the tasks I was assigned was to create a CI (Continuous Integration) system that built and
pushed the Docker images to a container registry. In about a day, I figured out how to
integrate with GitLab CI and push to our instance's GitLab Container Registry. This was
my first taste of using CI to automate the DevOps process.

Nowadays, I use GitHub Actions (GHA) for a variety of jobs. For example, this website and the
APIs that support it are built by GitHub Actions. Each code repository has a Dockerfile
and GHA workflow file that builds an OCI image and pushes it to a registry.

While I was at this internship, I also started migrating my personal devices over to
NixOS. I went pretty deep down the rabbit hole. However, I started high school a few
months later, and with sports, extracurriculars, and homework, I mostly stopped
tinkering with NixOS and largely stepped away from Linux and the Open Source community.
A lot has changed since then!

As my high school graduation approaches and I start to have more free time, I have picked up some of
my old hobbies again. The past three months I have dived back into the world of NixOS and
resumed my contributions to [nixpkgs](https://github.com/nixos/nixpkgs). Additionally,
I declared "nix bankruptcy" and rebuilt my [configuration](https://github.com/ethancedwards8/dotfiles/tree/master/.nix)
from scratch.

## Integrating GitHub Actions with my NixOS and nix-darwin configurations

This whole time, I had been thinking about how I could integrate my NixOS system and
nix-darwin (which offers NixOS-like reproducibility on MacOS) system configurations with
GitHub Actions like nixpkgs does. I thought I could benefit from automatic builds
that are cached by [Cachix](https://cachix.org), especially when building my Raspberry
Pi's configuration. It turns out, I'm not the only person who has thought of this. Domen Kožar,
founder of Cachix, utilizes GitHub's free CI system to [build and apply](https://github.com/domenkozar/homelab/blob/main/.github/workflows/deploy.yml)
his system configurations to his computer automatically. While I do not need the CD (Continuous Deployment)
service offered by Cachix, I am a customer of Cachix's caching service. I decided to model my CI after his.

GitHub Action Workflows and Jobs are defined by YAML files in the `.github/workflows` directory.
Below is the code that creates the jobs that run on the GitHub Actions runners. I use the
`x86_64-linux`, `aarch64-darwin` (MacOS), and `aarch64-linux` runners that are defined below. They
build my NixOS, nix-darwin, and NixOS-arm systems respectively. Apparently, the ARM runners are
[a recent addition](https://github.com/orgs/community/discussions/148648#) to GitHub Actions and are experimentally supported.

<SyntaxHighlighter language="yaml">
{`
name: Build & Push

on:
  push:
    branches:
      - master

jobs:
  build:
    name: Build and Push Config
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, ubuntu-24.04-arm]
        include:
          - os: ubuntu-latest
          - os: macos-latest
          - os: ubuntu-24.04-arm
    runs-on: \${{ matrix.os }}
`}
</SyntaxHighlighter>

After the runners are defined, we have to declare what they are actually going to do.
Below is the code that installs Nix into the GHAs runner environment. Cachix has an
action that nicely integrates with GHA to quickly install Nix and configure
pushing/pulling from Cachix.

<SyntaxHighlighter language="yaml">
{`
    steps:
      - run: sudo rm -rf /opt&
      - uses: actions/checkout@v4
      - uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
      - uses: cachix/cachix-action@v15
        with:
          name: ethancedwards8
          authToken: "\${{ secrets.CACHIX_AUTH_TOKEN }}"
`}
</SyntaxHighlighter>

Next is the actual building of each system. Obviously, MacOS cannot build Linux systems
and vice-versa (at least without the use of emulation/virtual machines, but that is
too much overhead when I can just use multiple runners). Consequently, I use conditional
statements to only build x86 targets on the x86 runner, Darwin targets on the MacOS runner,
and aarch64 targets on the ARM runner. The targets are the different Nix flake outputs
defined in my [configuration's `flake.nix`](https://github.com/ethancedwards8/dotfiles/blob/master/.nix/flake.nix).
At the very end of the file, Cachix will push the result of any of the builds to the
caching service, allowing my downstream computers to pull the results from them, saving
time and energy. Essentially, I am offloading the building of configuration files, USB
ISOs, development environments, and custom packages to GitHub.

<SyntaxHighlighter language="yaml">
{`
      - name: x86_64-linux Build
        if: matrix.os == 'ubuntu-latest'
        run: nix build -L .nix#{nixvm,usb,archpc,devShell.x86_64-linux}

      - name: aarch64 Build
        if: matrix.os == 'ubuntu-24.04-arm'
        run: nix build -L .nix#{nixrpi,devShell.aarch64-linux}

      - name: MacOS Build
        if: matrix.os == 'macos-latest'
        run: nix build -L .nix#{mbair,devShell.aarch64-darwin}

      - name: Deploy
        run: |
          cachix push ethancedwards8 ./result*
`}
</SyntaxHighlighter>

The biggest benefit I get from this setup is the building of a USB ISO that has my configurations
on it. It builds each time I make a change to my setup or update my inputs, meaning I always have
the freshest software and newest configurations that I can flash to a flash drive to use as a
portable Linux machine. Instead of having to build it manually each time I need it, GHA automatically
builds it and Cachix stores it. When I need it, I run `nix build` locally and it is retrieved from
Cachix and downloaded into my local Nix store.

While my use case is somewhat academic and not super practical, there are instances
where I, and others, have used GitHub Actions to automate and accelerate the development process
in software development. Popular new terminal emulator [Ghostty](https://github.com/ghostty-org/ghostty)
written in Zig is an excellent example. Their developers use Nix to build and create development
environments that are built by GitHub Actions and cached. This allows users and programmers to
do work faster instead of waiting for things to compile or Nix to finish evaluating.


Learning to take advantage of GitHub action's powerful CI system with Nix!

Building Nix Systems with GitHub Actions and Cachix

## Background

A few years ago, I started learning about the Pretty Good Privacy (PGP) security model. Essentially, it is a
collection of tools that allow you to encrypt, sign, and authenticate using cryptographic technologies.
Common uses include signing Git commits and tags, sending encrypted emails, publishing signed messages, and more.
I was really into online privacy at the time, so I thought this was something I should learn more about.
The whole idea is that an individual has two types of keys: public and private. The public key can
and should be shared with the rest of the world. It is your identifier. Private keys are, like the name suggests, private.
Messages are encrypted with your public key and decrypted with your private key. Everyone has a master key. Some individuals
choose to allow their master key to also serve as Authentication, Signing, and Encryption keys, but this is generally
considered insecure. The most important job of the master key, however, is creating subkeys and revocation certificates.
Subkeys can be assigned any combination of Authentication, Signing, or Encryption roles. Revocation certificates allow you
to permanently proclaim that your key is no longer in use and disable it. This can be done for a number of reasons like
having your private key compromised, but also for more benign reasons like you wanted to upgrade to the newest
cryptographic algorithm. The most common practice is to create the master key so that it only has the ability to
create new subkeys, and disallow it from Encrypting, Signing, or Authenticating, leaving that up to three individual subkeys.
There are also identities. Multiple identities (a name and email address, with an optional comment) can be stored in a single key.

A graphic may help us understand this. As you can see below, this is my current master key with a C. Below it are three subkeys
each with a capability (S, E, or A). My identity is also there. Don't be intimidated by those strings of hexadecimal characters.
Those are just the key IDs.

![My subkeys](/blogimages/keyoutput.png)

I immediately wanted to make my own keys. So I did. I followed [Dr. Duh's guide](https://github.com/drduh/YubiKey-Guide/tree/84c9d9654d73ad679aa8554b0819f93f397c61a8), which I highly recommend.
Unfortunately, I was a little bit overzealous when I did this. Like I mentioned earlier, it is generally considered a good practice
to create subkeys for each of the capabilities (S, E, or A). I decided I wanted a separate set of subkeys for each of my devices.
This led to me creating **nine** subkeys. I did not realize it at the time, but they would not play nice with each other.
Also, it was just ugly. Each time I listed my keys to use them or share them, all nine subkeys would appear. I also created three
identities, one for each of my email addresses. Finally, I put comments in my identities, a practice that is [generally frowned upon.](https://web.archive.org/web/20160306174622/https://debian-administration.org/users/dkg/weblog/97)
Afterwards, a few of my close friends and I signed each other's keys, verifying that their identities matched their keys. This
creates the "Web-of-Trust" that PGP is famous for.

One feature of PGP that I have not mentioned yet is its permanence. Once a key is uploaded to the internet, like most things, it is
there **forever**. While you can request that keyservers delete your key, they are not obligated to honor that request and it is
likely that thousands of other people around the world already have downloaded a copy. However, it is possible to revoke a key,
declaring to everyone that it should no longer be used. Because of this, I was hesitant to stop using this key.
For the past four years, I have used my original key, 0xF93DDAFA26EF2458, despite the multiple identities and excessive number of keys.
But today, I revoked my old one and created a new one.

## The New Key, 0x34C04305D581DBF

Armed with experience and a bit more knowledge, I created a new key with ID 0x34C04305D581DBF. A few paragraphs ago I briefly
mentioned signatures. In order to verify that this new key belongs to me and it is not someone masquerading as me, I signed
my new key with my old one. As you can see below, my new key is signed by itself (standard practice) as well as signed by
my old key. Immediately after, I sent the revocation of my old key to the keyservers. Therefore, if you trusted my old key
then you should trust my new one.

![Signatures on new key](/blogimages/keysignatures.png)

Another change I made was which algorithm I used. When I made my original key in 2020, it utilized RSA4096. It takes advantage
of some properties of prime numbers which make it very secure. However, for my new key, I chose to use ed25519, an algorithm
that uses elliptic curve cryptography. While my understanding on this topic is limited, ed25519 is just as secure as RSA4096,
but much faster and has shorter keys.

That being said, if you used my old key and have it in your keyring, please remove it and updated it with my current one
with fingerprint 2E51 F618 39D1 FA94 7A73  00C2 34C0 4305 D581 DBFE.


GPG Key Fun

## Hello World! How does this site work?

This is my blog, which features some pretty cool stuff. For example, code highlighting, quote changers, and an about page.

Code highlighting!
<SyntaxHighlighter language="javascript">
{`
const doStuff = () => {
	return console.log('hey');
}
`}
</SyntaxHighlighter>

It is built on NextJS, React, and Express (although not much express is used.). I also use some pretty cool smaller libraries for various different functionalities.

Blog posts are written in MDX.

Additionally, the cool quote changer on the main page is powered by an [API](https://github.com/ethancedwards8/ethancedwards-quotes/) that I wrote! Powered by Python and Flask.

Although at the time of writing, the site may not be the prettiest, I am confident that it will look good in enough time.

You can view the site source code on [GitHub](https://github.com/ethancedwards8/ethancedwards.com), feel free to submit pull requests if you see anything you can improve on!

## A bit about me

Right now, I am a full time student, working concurrently on both my high school and college degrees. Despite being a student, I do work as consulting and engineering for various small businesses around me. I also write for [StorageReview](https://storagereview.com) occasionally. I have been using Linux full time since 7th grade, and my current distro of choice is [Arch Linux](https://archlinux.org) with LVM on LUKS. My daily driver is a FrameWork laptop, and I have a desktop computer with a Ryzen 2600X alongside 16G of RAM. These machines however are dwarfed in power by my homelab, which consists of a cluster of Raspberry Pis ;). My homelab is currently hosting my site, but it may move locations in the future, but that's for another post.

I also have hobbies outside of tech. I am a cuber, reader, language learner, and mathematics lover. I am teaching myself Spanish through [Refold](https://refold.la), of which I am a huge proponent. This topic also deserves its own post. I plan on writing here a lot, although, everyone says that.

I am also super excited to talk about the books I am reading. I mostly read fiction, primarily Sci-Fi and Fantasy. But I also read lots of non-fiction, ranging from the history of an obscure religion to how electronics work. I love learning and I will read anything that you put in front of me.

## Bye!

This is the end of my first blog post, I hope you enjoyed reading it.


"Live Free or Die."

- John Stark

Recent Blog Posts: