,
-}
-```
-
-Here we see two things of note. First, the `ClapConfig` implements `Serialize`,
-not `Deserialize`. This is because we'll be using the `Serialize`
-implementation later when combining the configuration sources. We also add a
-`#[serde(skip_serializing_if = "Option::is_none")]` attribute to each variable
-that can be overwritten. This tells Serde to ignore the variable altogether if
-its value is `None` as a workaround for Figment not being able to ignore `None`
-values. Important here is how the variables names in the `ClapConfig` struct
-are the same as those in the `Config` struct. This is required for Figment to
-be able to combine these configuration sources.
-
-Finally, we combine everything using Figment:
-
-```rust
-let mut figment = Figment::new();
-
-if let Some(config_path) = &self.config.config_file {
- figment = figment.merge(Toml::file(config_path));
-}
-
-let config: crate::config::Config = figment
- .merge(Env::prefixed("OTTER_"))
- .merge(Serialized::defaults(self.config.clone()))
- .extract().unwrap();
-```
-
-We start by defining an empty figment. In the Figment library, a "figment" is a
-combination of configuration providers that can be deserialized using Serde. A
-provider is an object that can provide configuration variables from some
-source, be it a TOML file or environment variables. Figments can be combined
-with providers in various ways. Here, we make use of "merge", which overwrites
-any existing configuration variables with the values received from the new
-provider.
-
-We merge the empty figment with the `Toml` provider, which reads a TOML file
-for configuration variables. Then, we merge again, first with the
-`Env::prefixed("OTTER_")` provider, and then with the
-`Serialized::defaults(self.config.clone())` provider. The `Env` provider reads
-variables from environment variables, while `Serialized` provides variables by
-serializing a struct, in this case our `ClapConfig` struct (hence why we need a
-`Serialize` implementation). The result is a figment consisting of variables
-from the config file, environment variables and CLI arguments. This can be
-deserialized into our `Config` struct using `extract`.
-
-In my opinion, all of this combines into a very clean configuration system that
-allows configuration variables from all convenient sources, without sacrificing
-flexibility or resorting to boilerplate code.
-
-I hope to deploy a first build of Otter on my own servers in the near future to
-test it and work out any kinks. Afterwards, I'll announce a `0.1` release!
-
-Thanks for reading.
diff --git a/content/dev/otter/devlog-2.md b/content/dev/otter/devlog-2.md
deleted file mode 100644
index cd49644..0000000
--- a/content/dev/otter/devlog-2.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: "Working on Web UI & Admin Features"
-date: 2025-06-29
----
-
-Last couple of weeks, I've started working on the web UI using HTMX and
-PicoCSS. Development's been going pretty well, as I already had some experience
-working with HTMX from a previous project.
-
-Currently, the login page is implemented, as well as a session management page.
-I'm working towards building an initial version that can be used by multiple
-users, complete with admin user management features and sign-up functionality.
-Specifically, I'm prioritizing the following features:
-
-* Admin user management page
-* Sign-up flow, including sign-up links for private instances
-* Support for public instances (a.k.a. add a sign-up button and flow)
-
-These together would already make Otter a pretty nice Gpodder server, usable by
-multiple people. After that, I can focus on the smaller features and bug fixes
-(such as trying to make the Gpodder client work at all). I've released versions
-[0.2.0](https://git.rustybever.be/Chewing_Bever/otter/releases/tag/0.2.0) and
-[0.2.1](https://git.rustybever.be/Chewing_Bever/otter/releases/tag/0.2.1)
-containing the login view and session management page. Ideally, I'm going to
-keep releasing these smaller versions, so there's a relatively constant stream
-of new features to try.
-
-While developing the sessions and user management page, I've noticed I'm
-basically already implementing everything required for a RESTful API. Tables
-are implemented using paginated API requests, so having these routes return
-JSON instead of HTML depending on the `Content-Type` header wouldn't be a lot
-of work. The Gpodder API isn't the greatest, so having this more standardized
-API would be quite nice for third-party integrations.
-
-That's about it for this devlog, have a nice day.
diff --git a/content/dev/rieter/_index.md b/content/dev/rieter/_index.md
deleted file mode 100644
index 8ea5868..0000000
--- a/content/dev/rieter/_index.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: "Rieter"
-summary: "Easy-to-use Pacman repository server designed for the self-hosting enthusiast"
-type: "project"
-params:
- links:
- - name: Source
- url: 'https://git.rustybever.be/Chewing_Bever/rieter'
----
-
-This project is a reimagining of my Vieter project. While its goal is to
-eventually fully replace Vieter, I'm following a different mindset on how to
-get there.
-
-First and foremost, I want to make a well-designed Pacman repository server
-that anyone can set up on any device, be it a Raspberry Pi or a beefy server.
-Rieter should be usable for anything from a small personal repository all the
-way to a full mirror of a distribution's package server.
-
-Something that also fits nicely in this concept is mirroring. Rieter will
-support automatically mirroring upstream repositories. This could be used to
-support your distribution by setting up a new public mirror, or to speed up
-your updates by keeping a mirror of the repositories in your local network.
-
-Only once I've created a robust repository server that can be used on its own
-will I start looking towards the package build system. This system will of
-course be redesigned from the ground up to (hopefully) eliminate all the
-technical debt that's been accumulating in the Vieter codebase over the years.
-
-With these two concepts combined, I hope to create a great ecosystem on which
-one can build anything from personal repositories to entire distributions.
diff --git a/content/dev/rieter/devlog-1.md b/content/dev/rieter/devlog-1.md
deleted file mode 100644
index 1a9f627..0000000
--- a/content/dev/rieter/devlog-1.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: "Rethinking the Vieter project"
-date: 2024-06-08
----
-
-I've been meaning to recreate my Vieter project for a while. The codebase is
-full of technical debt, and I've grown dissatisfied with the language it was
-originally written in. That's where the Rieter project comes in: a full
-reimagining and reimplementation of the core ideas of the project, in Rust. I
-am however following a different mindset this time around.
-
-My plan is to develop the project in two stages. The first stage involves
-creating a well-designed general-purpose repository server. This includes
-serving and storing packages, as well as providing a REST API and web UI to
-interact with the repository packages. In this stage I'll also add mirroring
-functionality to allow a Rieter server to automatically maintain a local copy
-of another repository. This could be used to easily create another mirror for a
-distribution's servers, or perhaps to create a local mirror for faster
-downloads.
-
-Once the first stage is finished, we have a solid foundation on which we can
-build the second stage: the build system. This will involve redesigning the
-agent-server architecture that's currently used in Vieter, with the goal of
-completely replacing Vieter in due time.
-
-This post is the first in a hopefully plentiful series of devlogs for this
-project where I'll document my progress along the way.
-
-## Current progress
-
-The implementation of the repository server itself is almost done. A user can
-publish, request and remove packages for any number of repositories and
-architectures. Repositories are then further grouped into distributions,
-allowing a single server to be used for multiple distributions if need be (e.g.
-I would for example have `arch` and `endeavouros` as distributions on my
-personal server). A package's information is added to the database, and this
-data is then exposed via a paginated REST API.
-
-The only real hurdle left for a first release is concurrency, which brings with
-it a couple of problems. With the current implementation, it's possible for
-concurrent uploads of packages to corrupt the repository. The generation of the
-package archives happens inside the request handler for each upload, meaning
-multiple requests basically do duplicate work and can cause CPU usage spikes.
-The parsing of packages is also done inside the request handler, which once
-again causes the server to spike in CPU usage if multiple packages are uploaded
-in parallel. These things combined make concurrent uploads of packages a rather
-painful problem to deal with.
-
-My solution for these problems consists of two parts. First I want to add a
-queueing system for new packages. Instead of parsing the packages directly in
-the request handler, they would get added to a queue, with the server then
-responding with a [`202
-Accepted`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/202). The
-actual parsing of the packages would be done asynchronously by a configurable
-number of worker threads that parse the packages.
-
-The second part involves serializing and stalling the generation of the package
-archives until needed. Instead of actually generating the package archives for
-each uploaded package, we simply notify some central worker thread that the
-repository has been altered. This worker would then generate the package
-archives, after ensuring the queue is empty and no new packages have arrived in
-the last `n` seconds. This pattern accounts for groups of packages being
-uploaded at once without needlessly stressing the server.
-
-By implementing these features, the server should be able to handle a large
-number of package uploads without using excessive resources, ensuring Rieter
-can scale to proper sizes.
-
-## First release
-
-Once this is implemented, the codebase should be ready for a 0.1.0 release!
-This version will already be useable as a fully-fletched repository server on
-which I can then build the other parts of the first stage.
-
-For the 1.0 release, I'll be adding a web UI, as this was something that I was
-sorely missing from Vieter. Perhaps most exciting of all, automatic mirroring
-will also be added which I'm definitely looking forward to! I hope to publish
-another post here soon, but until then, thanks for reading.
diff --git a/content/dev/rieter/devlog-2.md b/content/dev/rieter/devlog-2.md
deleted file mode 100644
index 3fffcea..0000000
--- a/content/dev/rieter/devlog-2.md
+++ /dev/null
@@ -1,140 +0,0 @@
----
-title: "Progress on concurrent repositories"
-date: 2024-06-18
----
-
-During the last devlog I was working on a system for concurrent repositories.
-After a lot of trying, I've found a system that should work pretty well, even
-on larger scales. In doing so, the overall complexity of the system has
-actually decreased on several points as well! Let me explain.
-
-## Concurrent repositories
-
-I went through a lot of ideas before settling on the current implementation.
-Initially both the parsing of packages and the regeneration of the package
-archives happened inside the request handler, without any form of
-synchronisation. This had several unwanted effects. For one, multiple packages
-could quickly overload the CPU as they would all be processed in parallel.
-These would then also try to generate the package archives in parallel, causing
-writes to the same files which was a mess of its own. Because all work was
-performed inside the request handlers, the time it took for the server to
-respond was dependent on how congested the system was, which wasn't acceptable
-for me. Something definitely had to change.
-
-My first solution heavily utilized the Tokio async runtime that Rieter is built
-on. Each package that gets uploaded would spawn a new task that competes for a
-semaphore, allowing me to control how many packages get parsed in parallel.
-Important to note here is that the request handler no longer needs to wait
-until a package is finished parsing. The parse task is handled asynchronously,
-allowing the server to respond immediately with a [`202
-Accepted`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/202). This
-way, clients no longer need to wait unnecessarily long for a task that can be
-performed asynchronously on the server. Each parse task would then regenerate
-the package archives if it was able to successfully parse a package.
-
-Because each task regenerates the package archives, this approach performed a
-lot of extra work. The constant spawning of Tokio tasks also didn't sit right
-with me, so I tried another design, which ended up being the current version.
-
-### Current design
-
-I settled on a much more classic design: worker threads, or rather, Tokio
-tasks. On startup, Rieter launches `n` worker tasks that listen for messages on
-an [mpsc](https://docs.rs/tokio/latest/tokio/sync/mpsc/index.html) channel. The
-receiver is shared between the workers using a mutex, so each message only gets
-picked up by one of the workers. Each request first uploads its respective
-package to a temporary file, and sends a tuple `(repo, path)` to the channel,
-notifying one of the workers a new package is to be parsed. Each time the queue
-for a repository is empty, the package archives get regenerated, effectively
-batching this operation. This technique is so much simpler and works wonders.
-
-### Package queueing
-
-I did have some fun designing the intrinsics of this system. My goal was to
-have a repository seamlessly handle any number of packages being uploaded, even
-different versions of the same package. To achieve this I leveraged the
-database.
-
-Each parsed package's information gets added to the database with a unique
-monotonically increasing ID. Each repository can only have one version of a
-package present for each of its architectures. For each package name, the
-relevant package to add to the package archives is thus the one with the
-largest ID. This resulted in this (in my opinion rather elegant) query:
-
-```sql
-SELECT * FROM "package" AS "p1" INNER JOIN (
- SELECT "repo_id", "arch", "name", MAX("package"."id") AS "max_id"
- FROM "package"
- GROUP BY "repo_id", "arch", "name"
-) AS "p2" ON "p1"."id" = "p2"."max_id"
- WHERE "p1"."repo_id" = 1 AND "p1"."arch" IN ('x86_64', 'any') AND "p1"."state" <> 2
-```
-
-For each `(repo, arch, name)` tuple, we find the largest ID and select it, but
-only if its state is not `2`, which means *pending deletion*. Knowing what old
-packages to remove is then a similar query to this, where we instead select all
-packages that are marked as *pending deletion* or whose ID is less than the
-currently committed package.
-
-This design not only seamlessly supports any order of packages being added; it
-also paves the way for implementing repository mirroring down the line. This
-allows me to atomically update a repository, a feature that I'll be using for
-the mirroring system. I'll simply queue new packages and only regenerate the
-package archives once all packages have successfully synced to the server.
-
-## Simplifying things
-
-During my development of the repository system, I realized how complex I was
-making some things. For example, repositories are grouped into distros, and
-this structure was also visible in the codebase. Each distro had its own "disto
-manager" that managed packages for that repository. However, this was a
-needless overcomplication, as distros are solely an aesthetic feature. Each
-repository has a unique ID in the database anyways, so this extra level of
-complexity was completely unnecessary.
-
-Package organisation on disk is also still overly complex right now. Each
-repository has its own folder with its own packages, but this once again is an
-excessive layer as packages have unique IDs anyways. The database tracks which
-packages are part of which repositories, so I'll switch to storing all packages
-next to each other instead. This might also pave the way for some cool features
-down the line, such as staging repositories.
-
-I've been needlessly holding on to how I've done things with Vieter, while I
-can make completely new choices in Rieter. The file system for Rieter doesn't
-need to resemble the Vieter file system at all, nor should it follow any notion
-of how Arch repositories usually look. If need be, I can add an export utility
-to convert the directory structure into a more classic layout, but I shouldn't
-bother keeping it in mind while developing Rieter.
-
-## Configuration
-
-I switched configuration from environment variables and CLI arguments to a
-dedicated config file. The former would've been too simplistic for the later
-configuration options I'll be adding, so I opted for a configuration file
-instead.
-
-```toml
-api_key = "test"
-pkg_workers = 2
-log_level = "rieterd=debug"
-
-[fs]
-type = "local"
-data_dir = "./data"
-
-[db]
-type = "postgres"
-host = "localhost"
-db = "rieter"
-user = "rieter"
-password = "rieter"
-```
-
-This will allow me a lot more flexibility in the future.
-
-## First release
-
-There's still some polish to be done, but I'm definitely nearing an initial 0.1
-release for this project. I'm looking forward to announcing it!
-
-As usual, thanks for reading, and having a nice day.
diff --git a/content/dev/site/_index.md b/content/dev/site/_index.md
deleted file mode 100644
index dee8d6a..0000000
--- a/content/dev/site/_index.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: "Site"
-summary: "The infrastructure for this site"
-type: "project"
-params:
- links:
- - name: Backend
- url: 'https://git.rustybever.be/Chewing_Bever/site-backend'
- - name: Hugo
- url: 'https://git.rustybever.be/Chewing_Bever/site'
----
-
-This site is created using [Hugo](https://gohugo.io/), an easy-to-use static
-site generator that I've used for years. The static assets are built in my CI,
-where they are then published to my custom backend server.
-
-The backend server's main role is to allow me to publish built static sites to
-various routes on my domain. I use this both to publish this site, as well as
-deploying documentation for my various projects.
diff --git a/content/dev/site/devlog-1.md b/content/dev/site/devlog-1.md
deleted file mode 100644
index 9bf22c8..0000000
--- a/content/dev/site/devlog-1.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-title: "Switching to Axum"
-date: 2022-04-02
-tags:
- - rust
----
-
-In classic Jef fashion, it took me less than a week to completely overhaul the
-way my site works ;p Visually nothing's changed, but internally the website is
-now being powered by a web server [written in
-Rust](https://git.rustybever.be/Chewing_Bever/site-backend), powered by
-[Axum](https://github.com/tokio-rs/axum).
-
-The reason for this is expandability. While nginx is really good at what it
-does, it's rather limited when it comes to implementing new features on top of
-it. However, even if it wasn't, I would've still switched because I just really
-wanted to work in Rust once more :D
-
-Favoritism aside, the plan is to join the [IndieWeb](https://indieweb.org/)
-network. To quote their homepage:
-
-> The IndieWeb is a people-focused alternative to the "corporate web".
-
-They've got some really great ideas about what the internet could be if we
-tried, and considering I agree with nearly all of them, I wanna join ;p
-
-My first project will be to implement the Webmention protocol. This consists of
-a simple exchange of POST requests, where you notify another user's site
-whenever you mention one of their posts. This in exchange allows them to
-display my response on their website, and vice versa! In essence, it's simple
-decentralized commenting.
-
-My plans after this are still vague. I might dip my toes into
-[IndieAuth](https://indieauth.net/),
-[microformats](https://indieweb.org/microformats) or any of the other cool
-concepts they've got the offer! Either way, the plan is to enjoy myself with
-this site ;p
-
-If all goes well, this post will be the first new post to get published using
-my new deploy system, so fingers crossed :)
-
-Have a lovely day <3
diff --git a/content/dev/site/devlog-2.md b/content/dev/site/devlog-2.md
deleted file mode 100644
index b5c5833..0000000
--- a/content/dev/site/devlog-2.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-title: "Hosting arbitrary static sites"
-date: 2025-01-02T21:15:27+01:00
-tags: [rust, http, api]
----
-
-The backend for this site currently serves four static sites: this blog and
-three Vieter sites, namely its [documentation](/docs/vieter), [API
-documentation](/api-docs/vieter) and [manpages](/man/vieter). These can be
-updated by POSTing tarballs containing the static files to the backend. This
-all works fine, but the API sucked and the four static sites were hardcoded,
-meaning it wasn't possible to add new sites without recompiling the backend.
-
-## The old API
-
-My original choice for this API was rather strange in my opinion. There was a
-single route, `/api/deploy`, where tarballs could be uploaded to, along with an
-optional query parameter specifying which of the sites the tarball contained.
-If the parameter was omitted, it defaulted to the "root site", meaning the
-blog.
-
-This design choice always felt strange to me, but I didn't care enough to
-change it. *Until now*.
-
-## In with the new
-
-The new design is in my opinion a lot more clean and straightforward. I can
-push a tarball to any route, e.g. `/docs/vieter` and the contents of the
-tarball will be mounted there. The server simply unpacks the tarball at the
-specified path and functions as a simple file server. Updating a directory
-overwrites its contents without checking if anything is overwritten, meaning I
-do need to watch out I don't accidentally publish sites to subdirectories of
-other sites. If I do, they will be removed every time the parent directory is
-updated.
-
-An important caveat here is the root directory. The above method would imply
-that updating `/` would overwrite all other sites every time, which is bad. To
-prevent this, a site uploaded to `/` (or `/_root`) is instead stored in `_root`
-on disk. When serving a file, the server first looks in the `/_root` directory
-first, and in the other directories if no file is found.
-
-This setup allows me to create as many static sites as I want and host them on
-subpaths of my domain with ease. I hope to use this feature some time this
-year!
-
-Jef
diff --git a/content/dev/vieter/0.2.0.md b/content/dev/vieter/0.2.0.md
deleted file mode 100644
index ae78ed7..0000000
--- a/content/dev/vieter/0.2.0.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: "Vieter 0.2.0"
-date: 2022-04-11
----
-
-When this post gets published, I'll have successfully released version 0.2.0 of
-[Vieter](https://git.rustybever.be/Chewing_Bever/vieter)! For the uninitiated,
-Vieter is currently my biggest passion project. It's an implementation of an
-Arch repository server, paired with a build system for automatically building
-packages from the AUR & other sources.
-
-This release brings a lot of goodies; the changelog & release binaries can be
-found
-[here](https://git.rustybever.be/Chewing_Bever/vieter/releases/tag/0.2.0). The
-biggest changes are that Vieter now supports multiple repositories with support
-for packages for multiple architectures! Besides that, there's some bug fixing,
-improvements to the CLI & an added setting for the build system that allows for
-building on other architectures. The [docs](https://rustybever.be/docs/vieter/)
-have also been updated to reflect this new update.
-
-Of course, development won't just stop now, I have too many ideas for that ;p
-[0.3.0](https://git.rustybever.be/Chewing_Bever/vieter/milestone/27) will bring
-with it some big improvements to the builder system, allowing for more
-flexibility & configuration.
-
-If you're interested in the project, join me over at
-[#vieter:rustybever.be](https://matrix.to/#/#vieter:rustybever.be) on Matrix!
-
-Cheers <3
diff --git a/content/dev/vieter/0.3.0.md b/content/dev/vieter/0.3.0.md
deleted file mode 100644
index 6d6bd52..0000000
--- a/content/dev/vieter/0.3.0.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: "Vieter 0.3.0"
-date: 2022-06-13
----
-
-When this post is live, Vieter 0.3.0 will have been released! This release
-really does come with a lot of new features, including more reliable builds and
-a new cron implementation!
-
-This release ended up taking me over two months, but I'm quite proud of it :)
-It not only adds a lot of useful features, but also paves the way for a lot
-more cool features down the road!
-
-## What is Vieter?
-
-Vieter consists of two independents parts, namely an implementation of an Arch
-(Pacman) repository, & a build system to populate said repository. The goal is
-to remove the need for an AUR helper & move all builds to a remote server. Not
-only does this greatly reduce update times on lower-end systems, it also
-prevents AUR packages from being built multiple times on different systems.
-
-The repository can also be used independently, providing a convenient server
-for publishing Arch packages from CI builds for example.
-
-While I specifically mention Arch & the AUR, Vieter is compatible with any
-Pacman-based distro & can build PKGBUILDs provided from any Git source.
-
-## What's changed?
-
-### New cron daemon
-
-Perhaps the most important feature in this release is the implementation of a
-cron daemon. While 0.2.0 still relied on crond to periodically start builds,
-0.3.0 can schedule builds completely independently.
-
-The daemon understands a subset of the cron expression syntax. The build
-schedule can be either configured globally or on a per-repo basis. This allows
-the user to fine-tune certain packages, e.g. if they want them to be updated
-more regularly than all the rest.
-
-### More robust builds
-
-Often, a build would fail with exit code 8. This error indicates that makepkg
-wasn't able to install all dependencies, caused by the builder image not being
-up to date enough. Due to this, each build now runs `pacman -Syu` before
-running the actual build.
-
-Builds can now also use dependencies that are part of the target repository.
-This allows building packages with AUR dependencies, as long as all
-dependencies are also being built for said repository.
-
-### Build logs
-
-The main server now stores the logs of each build, including the exit code.
-This makes it a lot easier to debug why builds fail.
-
-### Improved documentation
-
-The [Vieter documentation](https://rustybever.be/docs/vieter/) has had a pretty
-major re-write to get it up to date with this new release. Now there's also
-[HTTP API docs](https://rustybever.be/docs/vieter/api/#introduction) & [man
-pages](https://rustybever.be/man/vieter/vieter.1.html).
-
-## Interested?
-
-If you're interested in Vieter, considering joining
-[#vieter:rustybever.be](https://matrix.to/#/#vieter:rustybever.be) on Matrix!
-The source code can be found on my personal
-[Gitea](https://git.rustybever.be/vieter/vieter).
diff --git a/content/dev/vieter/0.4.0.md b/content/dev/vieter/0.4.0.md
deleted file mode 100644
index 74c61e8..0000000
--- a/content/dev/vieter/0.4.0.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: "Vieter 0.4.0"
-date: 2022-10-01
----
-
-Right at the start of October, I managed to release another version of Vieter!
-
-## What is Vieter?
-
-Vieter consists of two independents parts, namely an implementation of an Arch
-(Pacman) repository, & a build system to populate said repository. The goal is
-to remove the need for an AUR helper & move all builds to a remote server. Not
-only does this greatly reduce update times on lower-end systems, it also
-prevents AUR packages from being built multiple times on different systems.
-
-The repository can also be used independently, providing a convenient server
-for publishing Arch packages from CI builds for example.
-
-While I specifically mention Arch & the AUR, Vieter is compatible with any
-Pacman-based distro & can build PKGBUILDs provided from any Git source.
-
-## What's changed?
-
-### Renaming `repos` to `targets`
-
-Before 0.4.0, "repos" was the term used to describe the list of Git
-repositories that periodically get built on your Vieter instance. This term
-however was rather confusing, as the Vieter server itself also hosts Pacman
-repositories, making it difficult to correctly talk about the features. That's
-why I've made the decision to rename this to "targets". All CLI commands
-previously found under `vieter repos` can now be used via `vieter targets`
-instead. API routes have also been renamed.
-
-Along with this, a new kind of target can now be added which specifies the link
-to a PKGBUILD file, instead of a Git repository. This can for example be used
-to link a PKGBUILD that's contained inside some other Git repository that's not
-specifically used for that PKGBUILD.
-
-### Refactored web framework
-
-The underlying web framework has seen a proper refactor to better accomodate
-the rest of the codebase. All API routes can now be found under a versioned
-`/api/v1` prefix.
-
-The repository endpoints now support `DELETE` requests to remove packages,
-arch-repos & repos. All routes serving files (e.g. the repository routes) now
-support HTTP byte range requests, which not only allows Pacman to resume
-downloads after failure, but also allows tools such as
-[`axel`](https://github.com/axel-download-accelerator/axel) to work properly
-using a Vieter server.
-
-Endpoints creating new entries on the server now return the ID of the newly
-created object (e.g. a target or a build log).
-
-### CLI UX
-
-The CLI has seen some useful changes. There's now a `-r` flag that makes
-Vieter's output better for scripting. Besides that, a small tool has been added
-to interact with the AUR and add AUR packages directly to your list of targets!
-
-`vieter targets add` and `vieter logs add` now return the ID of the newly
-created entry.
-
-## Interested?
-
-If you're interested in Vieter, considering joining
-[#vieter:rustybever.be](https://matrix.to/#/#vieter:rustybever.be) on Matrix!
-The source code can be found on my personal
-[Gitea](https://git.rustybever.be/vieter/vieter).
diff --git a/content/dev/vieter/0.5.0.md b/content/dev/vieter/0.5.0.md
deleted file mode 100644
index 8bed0ec..0000000
--- a/content/dev/vieter/0.5.0.md
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: "Vieter 0.5.0"
-date: 2022-12-29
----
-
-As 2022 comes to a close, and in the middle of exams, I'm ready to release
-another version of Vieter!
-
-## What's Vieter?
-
-As usual, a small refresher on what Vieter actually is for the new readers.
-Vieter provides two main services: a Pacman repository server and a build
-system for publishing Arch packages to said server. The goal is to fully
-replace any need for an AUR helper, with the AUR packages being built "in the
-cloud" instead. Of course, one can also publish their own packages to this
-server, allowing you to create your very own customized Arch repositories!
-
-## What's changed?
-
-### Server-agent architecture
-
-The biggest change this version introduces is the migration to a polling-based
-server-agent architecture.
-
-Previous versions relied on a "cron daemon". This daemon needed to be deployed
-on every architecture the user wanted to build packages for, with the daemon
-periodically polling the server for the list of targets to build. All
-scheduling was done on the node performing the builds.
-
-While this system served me well for a while, it did limit possibilities for
-improvement. Building on multiple servers wasn't possible, as the cron daemons
-had no way of synchronizing with each other, meaning they'd all run all builds.
-There was also no way for the server (or the user for that matter) to control
-these daemons; they had a fixed build schedule that could only be changed by
-changing a target's configuration.
-
-Due to these limitations, I've decided to revamp the build system & convert it
-to a server-agent architecture! With this new system, the main server handles
-all scheduling. On each server running builds, a "build agent" is deployed
-which periodically polls the main server for new jobs. This allows a Vieter
-instance to run builds on an arbitrary number of build nodes! Thanks to this,
-I'm able to run 137 builds in under 40 minutes, whereas before, I needed this
-time to process less than half of that :) As a bit of a stress test for my
-instance, I've started replicating the EndeavourOS repository for fun.
-
-With the main server now being in control of scheduling, I've also been able to
-implement manual scheduling of builds on the server. If a package needs to be
-rebuilt, you can simply send an HTTP request (or use the accompanying CLI
-command) to schedule a build job.
-
-### Quality-of-life improvements
-
-This release was mostly the build system redesign, but I've also added some QoL
-improvements. Noteable additions are the option to periodically remove logs, as
-an active Vieter instance can collect thousands over time. The CLI tool should
-now also be a lot more stable, and will correctly display HTTP errors if
-needed. There's also the option to specify what subdirectory of a Git
-repository to use for a build. This is for example useful when building
-packages using a Git repository [containing multiple
-PKGBUILDs](https://github.com/endeavouros-team/PKGBUILDS).
-
-## What's to come?
-
-My brain never stops, so I still have a lot of cool ideas I wish to implement
-in the coming months.
-
-For starters: better build awareness. The build system right now does not track
-the progress of jobs. Once a job is dispatched to an agent, the main server
-forgets about it and moves on. If a build fails due to unknown means causing
-the logs to never be uploaded, it'll be as if the build never happened. I'd
-like to change this. I want the main server to be aware of what jobs are
-running, have failed, or have perhaps timed out. This information could then be
-made available through the API, providing the user with valuable insight into
-the workings of their Vieter instance.
-
-Building on this idea, I wish to know what specific command caused the build to
-fail. Was it makepkg, an HTTP error? And if it was makepkg, what error code?
-can the build system respond to it by itself? The main goal is to provide a
-deeper understanding into the workings of builds and the build system as a
-whole.
-
-Another big one to tackle is API access to the repositories. These are
-currently only accessible through Pacman, but having this information available
-as a convenient REST API, useable from the CLI tool, sounds like a valuable
-asset. This would pave the way towards repository-level configuration.
-
-Of course there's a lot more ideas, but the list would be too long to put here
-;p
-
-## Conclusion
-
-As you can see, I still have *a lot* of ideas for Vieter. As usual however, I
-can't predict when any of these features will get implemented. It all depends
-on whether the uni life leaves me some time :)
-
-If you're interested in Vieter, considering joining
-[#vieter:rustybever.be](https://matrix.to/#/#vieter:rustybever.be) on Matrix!
-The source code can be found on my personal
-[Gitea](https://git.rustybever.be/vieter-v/vieter).
diff --git a/content/dev/vieter/0.6.0.md b/content/dev/vieter/0.6.0.md
deleted file mode 100644
index 65da6c0..0000000
--- a/content/dev/vieter/0.6.0.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: "Vieter 0.6.0"
-date: 2023-07-20
----
-
-It's been a while since I've released a new version of Vieter. A busy semester
-combined with a lack of interest in the project has definitely slowed down
-development. Nonetheless, I've got a new release ready for you!
-
-## What's Vieter?
-
-Vieter consists of two central components: an Arch Linux (well, Pacman
-actually) repository server that supports uploading package archives, combined
-with a build system to populate this server by periodically building select
-packages. The goal of this is to completely remove the need for an AUR helper,
-and moving all build times to the cloud, allowing for smooth updates across as
-many machines as required.
-
-## What's changed?
-
-This is a rather small update, and it mostly contains a few quality-of-life
-improvements.
-
-For one, there's now a Prometheus metrics endpoint so you can integrate Vieter
-into your existing stack. Currently the metrics are limited to API request
-timings, but this could be expanded upon in the future.
-
-The API can now filter the list of targets, allowing you to more easily search
-for specific targets. This functionality has also been added to the CLI.
-
-Builds can now be configured with a timeout, with build containers being
-automatically killed if this timeout is reached.
-
-Behind the scenes, the codebase has been updated to a compiler commit after the
-0.3.3 release, and the cron logic has been rewritten in C using the
-[libvieter](https://git.rustybever.be/vieter-v/libvieter) library. Agents now
-use worker threads, meaning they will not spawn a new thread anymore for each
-new build. Package uploads now properly fail if the TCP connection was closed
-before all bytes of a file were received. Lastly, the deprecated cron daemon
-has been removed.
-
-### What's next?
-
-Throughout the last couple of months, I've grown more and more tired of the V
-programming language, and the codebase in general. There's a lot of technical
-debt present, and due to the limitations of the language and existing
-frameworks, I've had to resort to questionable practices for a lot of the
-features (e.g. POST request data as query parameters). Due to this, I've
-decided to restart this project in Rust, under the name
-[rieter](https://git.rustybever.be/Chewing_Bever/rieter). With this, I hope to
-move away from this technical debt, and build a new solid foundation on which I
-can further expand this project. I'm not going to be making any promises on
-when this will be ready to replace Vieter, but I hope to get there soon.
-
-## Conclusion
-
-Just picture a very creative ending of this post here ;)
-
-If you're interested in Vieter, consider joining
-[#vieter:rustybever.be](https://matrix.to/#/#vieter:rustybever.be) on Matrix!
-The source code can be found on my personal
-[Gitea](https://git.rustybever.be/vieter-v/vieter).
diff --git a/content/dev/vieter/_index.md b/content/dev/vieter/_index.md
deleted file mode 100644
index 0f8f993..0000000
--- a/content/dev/vieter/_index.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: "Vieter"
-summary: "Arch Linux repository server & build system, written in V"
-type: "project"
-params:
- links:
- - name: Source
- url: 'https://git.rustybever.be/vieter-v/vieter'
- - name: Docs
- url: '/docs/vieter'
- - name: API Docs
- url: '/api-docs/vieter'
----
-
-Vieter is my personal solution to a problem I’ve been facing for months:
-extremely long AUR package build times. I run EndeavourOS on all my systems,
-meaning I'm updating my systems fairly frequently. I really like being a
-beta-tester for projects & run development builds for multiple packages.
-Because of this, I have to regularly re-build these packages in order to stay
-up to date with development. However, these builds can take a really long time,
-even on my more powerful laptop. This project is a solution to that problem:
-instead of building the packages locally, I can build them automatically in the
-cloud & just download them whenever I update my system! Thanks to this
-solution, I’m able to shave 10-15 minutes off my update times, just from not
-having to compile everything every time there’s an update.
-
-Besides this, it’s also just really useful to have a repository server that you
-control & can upload your own packages to. For example, I package my st
-terminal using a CI pipeline & upload it to my repository!
diff --git a/content/garden/_index.md b/content/garden/_index.md
deleted file mode 100644
index 9f051d8..0000000
--- a/content/garden/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-title: "Digital Garden"
----
-
-This section is meant to be a digital garden of sorts where I can write down
-thoughts without the pressure of a full-on blog post.
diff --git a/content/garden/chezmoi.md b/content/garden/chezmoi.md
deleted file mode 100644
index e68eaba..0000000
--- a/content/garden/chezmoi.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: "I like Chezmoi"
-date: 2025-01-31T09:08:10+01:00
----
-
-After stubbornly (lazily) refusing to fix my Neovim config on my "desktop"
-(a.k.a an older laptop with a GPU), I finally caved in and planned to fix it.
-My dotfiles were (still are) a mess as well, so I figured I'd look for a
-dotfiles manager to tidy things up.
-
-Originally I used a Git bare repo, but that's a lot of manual labour and it was
-in complete disarray, so I decided to start an entirely [new
-one](https://git.rustybever.be/Chewing_Bever/dotfiles2). A friend of mine
-coincidentally just talked to me about [Chezmoi](https://www.chezmoi.io/), so I
-decided to give it a go.
-
-Its installation was as easy as can be, with it being in the official
-repositories on Arch, and getting started with it is pretty simple. `chezmoi
-init` initializes a local repository where Chezmoi stores all your dotfiles.
-
-Chezmoi is basically a wrapper around Git that tracks some extra metadata where
-required. `chezmoi add` adds files to the staged files, and `chezmoi git` is
-used to actuallly commit and push dotfiles to the repository. At first I was a
-little confused as to how I was supposed to actually commit files, but after
-having discovered the Git wrapper, I was honestly quite happy with it.
-Offloading all Git-related commands to the actual Git tool is much less error
-prone and allows you to still organize your commits the way you want. Chezmoi
-does however support automatic commits and pushes; I might look into that some
-day.
-
-Setting up your dotfiles on another machine is straightforward. Running
-`chezmoi init [your repo]` on the machine clones your dotfiles, and `chezmoi
-apply` will apply the changes to the machine, simple as that.
-
-There's a lot more features such as secret management and templates, but I
-haven't had a need for those (yet). Either way, I think Chezmoi is a nice tool
-that will hopefully help me keep my dotfile madness in check.
diff --git a/content/garden/digital-garden.md b/content/garden/digital-garden.md
deleted file mode 100644
index 30300d3..0000000
--- a/content/garden/digital-garden.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: "Digital Garden"
-date: 2025-01-02T20:54:30+01:00
----
-
-We're trying something new for 2025. I've been wanting to write more, but most
-of the ideas I had weren't "good enough" (according to me) or I got stuck
-trying to perfect whatever it was I wanted to write about. This caused me to
-never write anything past June.
-
-I want to change that by setting up a digital garden of sorts. The idea is to
-add a zero-pressure section to my site where I can write less polished and
-shorter articles about anything. I like writing on this site, but I've gotten
-stuck in trying to perfect everything, so I'm hoping this section can remedy
-that.
-
-Hopefully this is one of many articles to come!
diff --git a/content/posts/switch-to-axum.md b/content/posts/switch-to-axum.md
new file mode 100644
index 0000000..eebc60e
--- /dev/null
+++ b/content/posts/switch-to-axum.md
@@ -0,0 +1,5 @@
+---
+title: "Switching to Axum"
+date: 2022-04-02
+draft: true
+---
diff --git a/content/blog/welcome.md b/content/posts/welcome.md
similarity index 100%
rename from content/blog/welcome.md
rename to content/posts/welcome.md
diff --git a/nginx/default.conf b/nginx/default.conf
new file mode 100644
index 0000000..1c28faa
--- /dev/null
+++ b/nginx/default.conf
@@ -0,0 +1,15 @@
+# vim: ft=nginx
+
+# =====FRONTEND HOSTING=====
+location / {
+ root /usr/share/nginx/html;
+ index index.html;
+}
+
+error_page 404 /404.html;
+
+# redirect server error pages to the static page /50x.html
+error_page 500 502 503 504 /50x.html;
+location = /50x.html {
+ root /usr/share/nginx/html;
+}
diff --git a/nginx/matrix.conf.template b/nginx/matrix.conf.template
new file mode 100644
index 0000000..abc2879
--- /dev/null
+++ b/nginx/matrix.conf.template
@@ -0,0 +1,49 @@
+# vim: ft=nginx
+
+# =====MATRIX WELL-KNOWN FILES=====
+# Used for server federation
+location = /.well-known/matrix/server {
+ charset utf-8;
+ default_type application/json;
+
+ if ($request_method = 'GET') {
+ add_header Access-Control-Allow-Origin '*';
+ add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE, OPTIONS';
+ add_header Access-Control-Allow-Headers 'X-Requested-With, Content-Type, Authorization';
+
+ return 200 '{"m.server":"${MATRIX_SERVER}"}';
+ }
+
+ if ($request_method = 'OPTIONS') {
+ add_header Access-Control-Allow-Origin '*';
+ add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE, OPTIONS';
+ add_header Access-Control-Allow-Headers 'X-Requested-With, Content-Type, Authorization';
+ add_header 'Content-Length' 0;
+ return 204;
+ }
+
+ return 405;
+}
+
+location = /.well-known/matrix/client {
+ charset utf-8;
+ default_type application/json;
+
+ if ($request_method = 'GET') {
+ add_header Access-Control-Allow-Origin '*';
+ add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE, OPTIONS';
+ add_header Access-Control-Allow-Headers 'X-Requested-With, Content-Type, Authorization';
+
+ return 200 '{"m.homeserver":{"base_url":"${MATRIX_CLIENT_SERVER}"}}';
+ }
+
+ if ($request_method = 'OPTIONS') {
+ add_header Access-Control-Allow-Origin '*';
+ add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE, OPTIONS';
+ add_header Access-Control-Allow-Headers 'X-Requested-With, Content-Type, Authorization';
+ add_header 'Content-Length' 0;
+ return 204;
+ }
+
+ return 405;
+}
diff --git a/nginx/nginx.conf b/nginx/nginx.conf
new file mode 100644
index 0000000..561a1bb
--- /dev/null
+++ b/nginx/nginx.conf
@@ -0,0 +1,37 @@
+user nginx;
+worker_processes auto;
+
+error_log /var/log/nginx/error.log notice;
+pid /var/run/nginx.pid;
+
+
+events {
+ worker_connections 1024;
+}
+
+
+http {
+ include /etc/nginx/mime.types;
+ default_type application/octet-stream;
+
+ log_format main '$remote_addr - $remote_user [$time_local] "$request" '
+ '$status $body_bytes_sent "$http_referer" '
+ '"$http_user_agent" "$http_x_forwarded_for"';
+
+ access_log /var/log/nginx/access.log main;
+
+ sendfile on;
+
+ keepalive_timeout 65;
+
+ gzip off;
+
+ server {
+ listen 80;
+ listen [::]:80;
+
+ # This order is important, as the Matrix matches should be evaluated first
+ include /etc/nginx/conf.d/matrix.conf;
+ include /etc/nginx/conf.d/default.conf;
+ }
+}
diff --git a/renovate.json b/renovate.json
new file mode 100644
index 0000000..7190a60
--- /dev/null
+++ b/renovate.json
@@ -0,0 +1,3 @@
+{
+ "$schema": "https://docs.renovatebot.com/renovate-schema.json"
+}
diff --git a/themes/etch b/themes/etch
new file mode 160000
index 0000000..1969ea2
--- /dev/null
+++ b/themes/etch
@@ -0,0 +1 @@
+Subproject commit 1969ea26457aef716efae848c5d08c8a00d75a69
diff --git a/themes/rb/.gitignore b/themes/rb/.gitignore
deleted file mode 100644
index e43b0f9..0000000
--- a/themes/rb/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-.DS_Store
diff --git a/themes/rb/LICENSE b/themes/rb/LICENSE
deleted file mode 100644
index 37209a9..0000000
--- a/themes/rb/LICENSE
+++ /dev/null
@@ -1,20 +0,0 @@
-The MIT License (MIT)
-
-Copyright (c) 2020 Lukas Joswiak
-
-Permission is hereby granted, free of charge, to any person obtaining a copy of
-this software and associated documentation files (the "Software"), to deal in
-the Software without restriction, including without limitation the rights to
-use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
-the Software, and to permit persons to whom the Software is furnished to do so,
-subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
-FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
-COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
-IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
-CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
diff --git a/themes/rb/README.md b/themes/rb/README.md
deleted file mode 100644
index e46750b..0000000
--- a/themes/rb/README.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# Etch
-
-Etch is a simple, responsive theme for [Hugo](https://gohugo.io) with a focus on writing. A live demo is available at https://lukasjoswiak.github.io/etch/.
-
-🙈 :see_no_evil:🙉 :hear_no_evil:🙊 :speak_no_evil:
-`—`` elements represent six levels of section headings. `` is the highest section level while `` is the lowest.
-
-# H1
-## H2
-### H3
-#### H4
-##### H5
-###### H6
-
-## Paragraph
-
-Xerum, quo qui aut unt expliquam qui dolut labo. Aque venitatiusda cum, voluptionse latur sitiae dolessi aut parist aut dollo enim qui voluptate ma dolestendit peritin re plis aut quas inctum laceat est volestemque commosa as cus endigna tectur, offic to cor sequas etum rerum idem sintibus eiur? Quianimin porecus evelectur, cum que nis nust voloribus ratem aut omnimi, sitatur? Quiatem. Nam, omnis sum am facea corem alique molestrunt et eos evelece arcillit ut aut eos eos nus, sin conecerem erum fuga. Ri oditatquam, ad quibus unda veliamenimin cusam et facea ipsamus es exerum sitate dolores editium rerore eost, temped molorro ratiae volorro te reribus dolorer sperchicium faceata tiustia prat.
-
-Itatur? Quiatae cullecum rem ent aut odis in re eossequodi nonsequ idebis ne sapicia is sinveli squiatum, core et que aut hariosam ex eat.
-
-## Blockquotes
-
-The blockquote element represents content that is quoted from another source, optionally with a citation which must be within a `footer` or `cite` element, and optionally with in-line changes such as annotations and abbreviations.
-
-#### Blockquote without attribution
-
-> Tiam, ad mint andaepu dandae nostion secatur sequo quae.
-> **Note** that you can use *Markdown syntax* within a blockquote.
-
-#### Blockquote with attribution
-
-> Don't communicate by sharing memory, share memory by communicating.
-> — Rob Pike[^1]
-
-
-[^1]: The above quote is excerpted from Rob Pike's [talk](https://www.youtube.com/watch?v=PAAkCSZUG1c) during Gopherfest, November 18, 2015.
-
-## Tables
-
-Tables aren't part of the core Markdown spec, but Hugo supports supports them out-of-the-box.
-
- Name | Age
---------|------
- Bob | 27
- Alice | 23
-
-#### Inline Markdown within tables
-
-| Inline | Markdown | In | Table |
-| ---------- | --------- | ----------------- | ---------- |
-| *italics* | **bold** | ~~strikethrough~~ | `code` |
-
-## Code Blocks
-
-#### Code block with backticks
-
-```
-html
-
-
-
- Example HTML5 Document
-
-
- Test
-
-
-```
-#### Code block indented with four spaces
-
-
-
-
- Example HTML5 Document
-
-
- Test
-
-
-
-#### Code block with Hugo's internal highlight shortcode
-{{< highlight html >}}
-
-
-
- Example HTML5 Document
-
-
- Test
-
-
-{{< /highlight >}}
-
-## List Types
-
-#### Ordered List
-
-1. First item
-2. Second item
-3. Third item
-
-#### Unordered List
-
-* List item
-* Another item
-* And another item
-
-#### Nested list
-
-* Item
-1. First Sub-item
-2. Second Sub-item
-
-## Other Elements — abbr, sub, sup, kbd, mark
-
-GIF is a bitmap image format.
-
-H2 O
-
-Xn + Yn = Zn
-
-Press CTRL +ALT +Delete salamanders are nocturnal, and hunt for insects, worms, and other small creatures.
-
diff --git a/themes/rb/exampleSite/content/posts/placeholder-text.md b/themes/rb/exampleSite/content/posts/placeholder-text.md
deleted file mode 100644
index 378b995..0000000
--- a/themes/rb/exampleSite/content/posts/placeholder-text.md
+++ /dev/null
@@ -1,58 +0,0 @@
-+++
-author = "Hugo Authors"
-title = "Placeholder Text"
-date = "2019-03-09"
-description = "Lorem Ipsum Dolor Si Amet"
-tags = [
- "markdown",
- "text",
-]
-+++
-
-Lorem est tota propiore conpellat pectoribus de
-pectora summo. Redit teque digerit hominumque toris verebor lumina non cervice
-subde tollit usus habet Arctonque, furores quas nec ferunt. Quoque montibus nunc
-caluere tempus inhospita parcite confusaque translucet patri vestro qui optatis
-lumine cognoscere flos nubis! Fronde ipsamque patulos Dryopen deorum.
-
-1. Exierant elisi ambit vivere dedere
-2. Duce pollice
-3. Eris modo
-4. Spargitque ferrea quos palude
-
-Rursus nulli murmur; hastile inridet ut ab gravi sententia! Nomine potitus
-silentia flumen, sustinet placuit petis in dilapsa erat sunt. Atria
-tractus malis.
-
-1. Comas hunc haec pietate fetum procerum dixit
-2. Post torum vates letum Tiresia
-3. Flumen querellas
-4. Arcanaque montibus omnes
-5. Quidem et
-
-# Vagus elidunt
-
-
- {{- block "main" . }}{{- end }}
-
- {{- partial "footer.html" . -}}
-
-
diff --git a/themes/rb/layouts/_default/li.html b/themes/rb/layouts/_default/li.html
deleted file mode 100644
index 190260f..0000000
--- a/themes/rb/layouts/_default/li.html
+++ /dev/null
@@ -1,6 +0,0 @@
-
-
- {{ .Title }}
- {{ .Date | time.Format (i18n "posts.date") }}
-
diff --git a/themes/rb/layouts/_default/section.html b/themes/rb/layouts/_default/section.html
deleted file mode 100644
index 9a03772..0000000
--- a/themes/rb/layouts/_default/section.html
+++ /dev/null
@@ -1,9 +0,0 @@
-{{ define "main" }}
-{{ .Content }}
-{{ i18n "posts.title" }}
-
-{{- range .Pages }}
- {{ .Render "li" }}
-{{- end }}
-
-{{ end }}
diff --git a/themes/rb/layouts/_default/single.html b/themes/rb/layouts/_default/single.html
deleted file mode 100644
index 2e025e7..0000000
--- a/themes/rb/layouts/_default/single.html
+++ /dev/null
@@ -1,21 +0,0 @@
-{{ define "main" }}
-
-
- {{- .Content -}}
-
-{{ end }}
diff --git a/themes/rb/layouts/_default/taxonomy.html b/themes/rb/layouts/_default/taxonomy.html
deleted file mode 100644
index 86677c2..0000000
--- a/themes/rb/layouts/_default/taxonomy.html
+++ /dev/null
@@ -1,8 +0,0 @@
-{{ define "main" }}
-{{ .Title }}
-
-{{- range .Pages }}
- {{ .Render "li" }}
-{{- end }}
-
-{{ end }}
diff --git a/themes/rb/layouts/blog/section.html b/themes/rb/layouts/blog/section.html
deleted file mode 100644
index 9a03772..0000000
--- a/themes/rb/layouts/blog/section.html
+++ /dev/null
@@ -1,9 +0,0 @@
-{{ define "main" }}
-{{ .Content }}
-{{ i18n "posts.title" }}
-
-{{- range .Pages }}
- {{ .Render "li" }}
-{{- end }}
-
-{{ end }}
diff --git a/themes/rb/layouts/dev/section.html b/themes/rb/layouts/dev/section.html
deleted file mode 100644
index 4c770cd..0000000
--- a/themes/rb/layouts/dev/section.html
+++ /dev/null
@@ -1,12 +0,0 @@
-{{ define "main" }}
-{{ .Content }}
-Projects
-
-{{ range .Pages }}
-
- {{ .Title }}
- {{ .Summary }}
-
-{{ end }}
-
-{{ end }}
diff --git a/themes/rb/layouts/index.html b/themes/rb/layouts/index.html
deleted file mode 100644
index afc13ef..0000000
--- a/themes/rb/layouts/index.html
+++ /dev/null
@@ -1,9 +0,0 @@
-{{ define "main" }}
-{{ .Content }}
-Latest posts
-
-{{ range first 15 .Site.RegularPages }}
- {{ .Render "li" }}
-{{ end }}
-
-{{ end }}
diff --git a/themes/rb/layouts/partials/footer.html b/themes/rb/layouts/partials/footer.html
deleted file mode 100644
index 73420ef..0000000
--- a/themes/rb/layouts/partials/footer.html
+++ /dev/null
@@ -1,3 +0,0 @@
-
diff --git a/themes/rb/layouts/partials/head.html b/themes/rb/layouts/partials/head.html
deleted file mode 100644
index 5fa3a6a..0000000
--- a/themes/rb/layouts/partials/head.html
+++ /dev/null
@@ -1,31 +0,0 @@
-
- {{ .Title }}
-
diff --git a/themes/rb/layouts/partials/header.html b/themes/rb/layouts/partials/header.html
deleted file mode 100644
index 9a66449..0000000
--- a/themes/rb/layouts/partials/header.html
+++ /dev/null
@@ -1,12 +0,0 @@
-
-
-
-
- {{ range .Site.Menus.main.ByWeight -}}
-
- {{ .Pre }}{{- .Name -}} {{ .Post }}
-
- {{- end }}
-
-
-
diff --git a/themes/rb/layouts/partials/posts.html b/themes/rb/layouts/partials/posts.html
deleted file mode 100644
index 3d28ff7..0000000
--- a/themes/rb/layouts/partials/posts.html
+++ /dev/null
@@ -1,6 +0,0 @@
-{{ i18n "posts.title" }}
-
-{{- range .Pages }}
- {{ .Render "li" }}
-{{- end }}
-
diff --git a/themes/rb/layouts/project/section.html b/themes/rb/layouts/project/section.html
deleted file mode 100644
index ccf5b7d..0000000
--- a/themes/rb/layouts/project/section.html
+++ /dev/null
@@ -1,26 +0,0 @@
-{{ define "main" }}
-{{ .Title }}
-
-
-
- {{ range .Page.Params.links -}}
-
- {{- .name -}}
-
- {{- end }}
-
-
-
-
-{{ .Content }}
-
-{{ if compare.Gt .Pages.Len 0 }}
-{{ i18n "posts.title" }}
-
-{{- range .Pages }}
- {{ .Render "li" }}
-{{- end }}
-
-{{ end }}
-
-{{ end }}
diff --git a/themes/rb/layouts/shortcodes/toc.html b/themes/rb/layouts/shortcodes/toc.html
deleted file mode 100644
index 22da6e7..0000000
--- a/themes/rb/layouts/shortcodes/toc.html
+++ /dev/null
@@ -1,4 +0,0 @@
-
- Table of Contents
- {{ .Page.TableOfContents }}
-
diff --git a/themes/rb/theme.toml b/themes/rb/theme.toml
deleted file mode 100644
index 07f201a..0000000
--- a/themes/rb/theme.toml
+++ /dev/null
@@ -1,13 +0,0 @@
-name = "Etch"
-license = "MIT"
-licenselink = "https://github.com/LukasJoswiak/etch/blob/master/LICENSE"
-description = "Lightweight Hugo theme with a focus on content"
-homepage = "https://github.com/LukasJoswiak/etch"
-demosite = "https://lukasjoswiak.github.io/etch/"
-tags = ["simple", "minimal", "clean", "fast", "blog", "responsive", "dark mode", "privacy"]
-features = ["fast", "blog", "syntax highlighting", "dark mode"]
-min_version = "0.41"
-
-[author]
- name = "Lukas Joswiak"
- homepage = "https://lukasjoswiak.com"
-
-## Features:
-
-* Homepage with list of posts.
-* Support for pages.
-* Responsive design for optimized mobile experience.
-* Syntax highlighting with customizable theme.
-* Dark theme which automatically adjusts based on users' setting ([example](https://github.com/LukasJoswiak/etch/wiki/Dark-mode)).
-* No external dependencies, no JavaScript, no web fonts.
-* Internationalization friendly: use default English translations or create your own
-
-## Installation
-
-To install `etch`, download the repository into the `themes` folder in the root of your site.
-
-```
-$ git submodule add https://github.com/LukasJoswiak/etch.git themes/etch
-```
-
-Then, use the theme to generate your site.
-
-```
-$ hugo server -t etch
-```
-
-Use the [sample configuration](https://github.com/LukasJoswiak/etch/wiki/Configuration#sample-configuration) as a starting point. See the [configuration](https://github.com/LukasJoswiak/etch/wiki/Configuration) page for more info.
-
-Read the [wiki](https://github.com/LukasJoswiak/etch/wiki) to learn about more options.
diff --git a/themes/rb/archetypes/default.md b/themes/rb/archetypes/default.md
deleted file mode 100644
index ac36e06..0000000
--- a/themes/rb/archetypes/default.md
+++ /dev/null
@@ -1,2 +0,0 @@
-+++
-+++
diff --git a/themes/rb/assets/css/dark.css b/themes/rb/assets/css/dark.css
deleted file mode 100644
index 3ea1dd8..0000000
--- a/themes/rb/assets/css/dark.css
+++ /dev/null
@@ -1,62 +0,0 @@
-{{ if not (eq .Site.Params.dark "on") -}}
-@media (prefers-color-scheme: dark) {
-{{ end -}}
-html {
- scrollbar-color: #6c6c6c #2e2e2e;
-}
-
-body {
- color: #ebebeb;
- background: #121212;
- -webkit-font-smoothing: antialiased;
- -moz-osx-font-smoothing: grayscale;
-}
-
-header#banner a {
- color: #e0e0e0;
- text-decoration: none;
-}
-
-header#banner nav ul li a {
- color: #cccccc;
-}
-
-header#links a {
- color: #e0e0e0;
- text-decoration: none;
-}
-
-header#links nav ul li a {
- color: #00b1ed;
-}
-
-main#content a {
- color: #00b1ed;
-}
-
-main#content p {
- color: #f5f5f5;
-}
-
-main#content hr {
- background: #5c5c5c;
-}
-
-main#content #toc h4 {
- color: #d4d4d4;
-}
-
-main#content ul#posts small {
- color: #a7a7a7;
-}
-
-main#content ul#posts li a:hover {
- color: #21c7ff;
-}
-
-main#content header#post-header div {
- color: #a7a7a7;
-}
-{{- if not (eq .Site.Params.dark "on") -}}
-}
-{{- end -}}
diff --git a/themes/rb/assets/css/main.css b/themes/rb/assets/css/main.css
deleted file mode 100644
index 6b2598a..0000000
--- a/themes/rb/assets/css/main.css
+++ /dev/null
@@ -1,307 +0,0 @@
-*, *:before, *:after {
- box-sizing: border-box;
-}
-
-html {
- font-size: 62.5%;
-}
-
-body {
- font-size: 16px;
- font-size: 1.6rem;
- font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
- color: #313a3d;
- width: 100%;
- margin: 0 auto;
- padding: 0 16px;
- line-height: 1.6;
-}
-
-header#banner {
- margin: 25px 0;
-}
-
-header#banner a {
- color: #313a3d;
- text-decoration: none;
-}
-
-header#banner a:hover {
- text-decoration: underline;
-}
-
-header#banner h2 {
- display: inline;
- font-size: 21px;
- font-size: 2.1rem;
- margin: 0 8px 0 0;
-}
-
-header#banner nav {
- display: inline-block;
-}
-
-header#banner nav ul {
- list-style-type: none;
- font-size: 1.05em;
- text-transform: lowercase;
- margin: 0;
- padding: 0;
-}
-
-header#banner nav ul li {
- display: inline;
- margin: 0 3px;
-}
-
-header#banner nav ul li a {
- color: #454545;
-}
-
-main#content a {
- color: #007dfa;
- text-decoration: none;
-}
-
-main#content a:hover {
- text-decoration: underline;
-}
-
-main#content h1,
-main#content h2,
-main#content h3,
-main#content h4,
-main#content h5,
-main#content h6 {
- margin-bottom: 0;
- line-height: 1.15;
-}
-
-main#content h3 {
- font-size: 19px;
- font-size: 1.9rem;
-}
-
-main#content h1 + p,
-main#content h2 + p,
-main#content h3 + p,
-main#content h4 + p,
-main#content h5 + p,
-main#content h6 + p {
- margin-top: 5px;
-}
-
-main#content p {
- color: #394548;
- margin: 16px 0;
-}
-
-main#content hr {
- height: 1px;
- border: 0;
- background: #d8d8d8;
-}
-
-main#content abbr {
- cursor: help;
-}
-
-/* index.html styles */
-main#content ul#posts {
- list-style-type: none;
- font-size: 16px;
- font-size: 1.6rem;
- margin-top: 0;
- padding: 0;
-}
-
-main#content ul#posts li {
- margin: 5px 0;
- padding: 0;
-}
-
-main#content ul#posts small {
- font-size: 0.8em;
- color: #767676;
- margin-left: 10px;
-}
-
-main#content ul#posts li a {
- text-decoration: none;
-}
-
-main#content ul#posts li a:hover {
- color: #369aff;
-}
-
-main#content ul#posts li a:hover small {
- color: inherit;
-}
-
-/* single.html styles */
-main#content header#post-header h1 {
- display: block;
- font-size: 23px;
- font-size: 2.3rem;
- font-weight: 600;
- line-height: 1.15;
-}
-
-main#content header#post-header > div {
- display: block;
- font-size: 0.85em;
- color: #767676;
-}
-
-main#content #toc {
- border: 1px solid #b1b1b1;
- border-radius: 1px;
- line-height: 26px;
- margin: 16px 0;
- padding: 9px 14px;
-}
-
-main#content #toc h4 {
- font-size: 1.06em;
- color: #3d3d3d;
- margin: 0;
-}
-
-main#content #toc nav#TableOfContents {
- margin-top: 4px;
-}
-
-main#content #toc nav#TableOfContents > ul, main#content #toc nav#TableOfContents > ol {
- margin-left: -40px;
-}
-
-main#content #toc ul, main#content #toc ol {
- font-size: 0.98em;
- margin: 0;
- padding: 0 0 0 40px;
-}
-
-main#content #toc ul {
- list-style-type: none;
-}
-
-main#content #toc ol {
- counter-reset: item;
-}
-
-main#content #toc ol li {
- display: block;
-}
-
-main#content #toc ol li:before {
- content: counters(item, ".") ". ";
- counter-increment: item;
-}
-
-main#content img {
- max-width: 100%;
- margin: 0 auto;
-}
-
-main#content figure {
- margin: 16px 0;
-}
-
-main#content figure img {
- display: block;
- max-width: 100%;
- margin: 0 auto;
-}
-
-main#content figure figcaption {
- font-size: 0.92em;
- font-style: italic;
- line-height: 22px;
- text-align: center;
- margin-top: 6px;
- padding: 0 10px;
-}
-
-main#content figure figcaption h4 {
- font-style: normal;
- display: inline;
- margin: 0;
-}
-
-main#content figure figcaption p {
- display: inline;
- margin: 0;
- padding-left: 8px;
-}
-
-main#content blockquote {
- font-style: italic;
- margin-top: 10px;
- margin-bottom: 10px;
- margin-left: 50px;
- padding-left: 15px;
- border-left: 3px solid #ccc;
-}
-
-main#content code,
-main#content pre {
- font-family: 'Menlo', monospace;
-}
-
-main#content code {
- font-size: 0.96em;
- padding: 0 5px;
-}
-
-main#content pre {
- display: block;
- overflow-x: auto;
- font-size: 14px;
- font-size: 1.4rem;
- white-space: pre;
- margin: 20px 0;
- padding: 1.5rem 1.5rem;
- line-height: 1.4;
-}
-
-main#content pre code {
- padding: 0;
-}
-
-main#content section.footnotes {
- font-size: 0.9em;
-}
-
-footer#footer {
- font-size: 14px;
- font-size: 1.4rem;
- font-weight: 400;
- color: #b3b3b3;
- margin: 40px 0;
-}
-
-header#links {
- display: inline-block;
-}
-
-header#links nav {
- display: inline-block;
-}
-
-header#links nav ul {
- list-style-type: none;
- font-size: 1.05em;
- text-transform: lowercase;
- margin: 0;
- padding: 0;
-}
-
-header#links nav ul li {
- display: inline;
- margin: 0 3px;
-}
-
-header#links nav ul li a {
- color: #007dfa;
- text-decoration: none;
-}
diff --git a/themes/rb/assets/css/min770px.css b/themes/rb/assets/css/min770px.css
deleted file mode 100644
index 076fdee..0000000
--- a/themes/rb/assets/css/min770px.css
+++ /dev/null
@@ -1,52 +0,0 @@
-@media (min-width: 770px) {
-body {
- width: 600px;
- line-height: 1.5;
-}
-
-main#content hr {
- width: 108%;
- margin-left: -3.8%;
-}
-
-/* index.html styles */
-header#banner h2 {
- font-size: 25px;
- font-size: 2.5rem;
-}
-
-main#content h3 {
- font-size: 20px;
- font-size: 2rem;
-}
-
-main#content ul#posts {
- font-size: 18px;
- font-size: 1.8rem;
-}
-
-/* single.html styles */
-main#content header#post-header h1 {
- font-size: 24px;
- font-size: 2.4rem;
-}
-
-main#content img {
- max-width: 108%;
- margin-left: -3.8%;
-}
-
-main#content figure {
- margin-left: -3.8%;
-}
-
-main#content figure img {
- max-width: 108%;
-}
-
-main#content pre {
- width: 108%;
- margin-left: -3.8%;
- padding: 1.5rem 2.2rem;
-}
-}
diff --git a/themes/rb/assets/css/syntax.css b/themes/rb/assets/css/syntax.css
deleted file mode 100644
index 350286e..0000000
--- a/themes/rb/assets/css/syntax.css
+++ /dev/null
@@ -1,59 +0,0 @@
-/* Background */ .chroma { color: #f8f8f2; background-color: #272822 }
-/* Error */ .chroma .err { color: #960050; background-color: #1e0010 }
-/* LineTableTD */ .chroma .lntd { vertical-align: top; padding: 0; margin: 0; border: 0; }
-/* LineTable */ .chroma .lntable { border-spacing: 0; padding: 0; margin: 0; border: 0; width: auto; overflow: auto; display: block; }
-/* LineHighlight */ .chroma .hl { display: block; width: 100%;background-color: #ffffcc }
-/* LineNumbersTable */ .chroma .lnt { margin-right: 0.4em; padding: 0 0.4em 0 0.4em;color: #7f7f7f }
-/* LineNumbers */ .chroma .ln { margin-right: 0.4em; padding: 0 0.4em 0 0.4em;color: #7f7f7f }
-/* Keyword */ .chroma .k { color: #66d9ef }
-/* KeywordConstant */ .chroma .kc { color: #66d9ef }
-/* KeywordDeclaration */ .chroma .kd { color: #66d9ef }
-/* KeywordNamespace */ .chroma .kn { color: #f92672 }
-/* KeywordPseudo */ .chroma .kp { color: #66d9ef }
-/* KeywordReserved */ .chroma .kr { color: #66d9ef }
-/* KeywordType */ .chroma .kt { color: #66d9ef }
-/* NameAttribute */ .chroma .na { color: #a6e22e }
-/* NameClass */ .chroma .nc { color: #a6e22e }
-/* NameConstant */ .chroma .no { color: #66d9ef }
-/* NameDecorator */ .chroma .nd { color: #a6e22e }
-/* NameException */ .chroma .ne { color: #a6e22e }
-/* NameFunction */ .chroma .nf { color: #a6e22e }
-/* NameOther */ .chroma .nx { color: #a6e22e }
-/* NameTag */ .chroma .nt { color: #f92672 }
-/* Literal */ .chroma .l { color: #ae81ff }
-/* LiteralDate */ .chroma .ld { color: #e6db74 }
-/* LiteralString */ .chroma .s { color: #e6db74 }
-/* LiteralStringAffix */ .chroma .sa { color: #e6db74 }
-/* LiteralStringBacktick */ .chroma .sb { color: #e6db74 }
-/* LiteralStringChar */ .chroma .sc { color: #e6db74 }
-/* LiteralStringDelimiter */ .chroma .dl { color: #e6db74 }
-/* LiteralStringDoc */ .chroma .sd { color: #e6db74 }
-/* LiteralStringDouble */ .chroma .s2 { color: #e6db74 }
-/* LiteralStringEscape */ .chroma .se { color: #ae81ff }
-/* LiteralStringHeredoc */ .chroma .sh { color: #e6db74 }
-/* LiteralStringInterpol */ .chroma .si { color: #e6db74 }
-/* LiteralStringOther */ .chroma .sx { color: #e6db74 }
-/* LiteralStringRegex */ .chroma .sr { color: #e6db74 }
-/* LiteralStringSingle */ .chroma .s1 { color: #e6db74 }
-/* LiteralStringSymbol */ .chroma .ss { color: #e6db74 }
-/* LiteralNumber */ .chroma .m { color: #ae81ff }
-/* LiteralNumberBin */ .chroma .mb { color: #ae81ff }
-/* LiteralNumberFloat */ .chroma .mf { color: #ae81ff }
-/* LiteralNumberHex */ .chroma .mh { color: #ae81ff }
-/* LiteralNumberInteger */ .chroma .mi { color: #ae81ff }
-/* LiteralNumberIntegerLong */ .chroma .il { color: #ae81ff }
-/* LiteralNumberOct */ .chroma .mo { color: #ae81ff }
-/* Operator */ .chroma .o { color: #f92672 }
-/* OperatorWord */ .chroma .ow { color: #f92672 }
-/* Comment */ .chroma .c { color: #75715e }
-/* CommentHashbang */ .chroma .ch { color: #75715e }
-/* CommentMultiline */ .chroma .cm { color: #75715e }
-/* CommentSingle */ .chroma .c1 { color: #75715e }
-/* CommentSpecial */ .chroma .cs { color: #75715e }
-/* CommentPreproc */ .chroma .cp { color: #75715e }
-/* CommentPreprocFile */ .chroma .cpf { color: #75715e }
-/* GenericDeleted */ .chroma .gd { color: #f92672 }
-/* GenericEmph */ .chroma .ge { font-style: italic }
-/* GenericInserted */ .chroma .gi { color: #a6e22e }
-/* GenericStrong */ .chroma .gs { font-weight: bold }
-/* GenericSubheading */ .chroma .gu { color: #75715e }
diff --git a/themes/rb/exampleSite/config.toml b/themes/rb/exampleSite/config.toml
deleted file mode 100644
index 527434a..0000000
--- a/themes/rb/exampleSite/config.toml
+++ /dev/null
@@ -1,38 +0,0 @@
-baseURL = "https://example.com"
-title = "Website Name"
-theme = "etch"
-languageCode = "en-US"
-enableInlineShortcodes = true
-pygmentsCodeFences = true
-pygmentsUseClasses = true
-
-[params]
- description = "Your site description"
- copyright = "Copyright © 2021 Your Name"
- dark = "auto"
- highlight = true
-
-[menu]
- [[menu.main]]
- identifier = "posts"
- name = "posts"
- title = "posts"
- url = "/"
- weight = 10
-
- [[menu.main]]
- identifier = "about"
- name = "about"
- title = "about"
- url = "/about/"
- weight = 20
-
-[permalinks]
- posts = "/:title/"
-
-[markup.goldmark.renderer]
- # Allow HTML in Markdown
- unsafe = true
-
- [markup.tableOfContents]
- ordered = true
diff --git a/themes/rb/exampleSite/content/_index.md b/themes/rb/exampleSite/content/_index.md
deleted file mode 100644
index 2a74490..0000000
--- a/themes/rb/exampleSite/content/_index.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: "Home"
----
-This is some info about me.
diff --git a/themes/rb/exampleSite/content/about/index.md b/themes/rb/exampleSite/content/about/index.md
deleted file mode 100644
index eb5384b..0000000
--- a/themes/rb/exampleSite/content/about/index.md
+++ /dev/null
@@ -1,21 +0,0 @@
-+++
-title = "About"
-+++
-
-Written in Go, Hugo is an open source static site generator available under the [Apache Licence 2.0.](https://github.com/gohugoio/hugo/blob/master/LICENSE) Hugo supports TOML, YAML and JSON data file types, Markdown and HTML content files and uses shortcodes to add rich content. Other notable features are taxonomies, multilingual mode, image processing, custom output formats, HTML/CSS/JS minification and support for Sass SCSS workflows.
-
-Hugo makes use of a variety of open source projects including:
-
-* https://github.com/yuin/goldmark
-* https://github.com/alecthomas/chroma
-* https://github.com/muesli/smartcrop
-* https://github.com/spf13/cobra
-* https://github.com/spf13/viper
-
-Hugo is ideal for blogs, corporate websites, creative portfolios, online magazines, single page applications or even a website with thousands of pages.
-
-Hugo is for people who want to hand code their own website without worrying about setting up complicated runtimes, dependencies and databases.
-
-Websites built with Hugo are extremelly fast, secure and can be deployed anywhere including, AWS, GitHub Pages, Heroku, Netlify and any other hosting provider.
-
-Learn more and contribute on [GitHub](https://github.com/gohugoio).
diff --git a/themes/rb/exampleSite/content/posts/emoji-support.md b/themes/rb/exampleSite/content/posts/emoji-support.md
deleted file mode 100644
index ecf6c86..0000000
--- a/themes/rb/exampleSite/content/posts/emoji-support.md
+++ /dev/null
@@ -1,47 +0,0 @@
-+++
-author = "Hugo Authors"
-title = "Emoji Support"
-date = "2019-03-05"
-description = "Guide to emoji usage in Hugo"
-tags = [
- "emoji",
-]
-+++
-
-Emoji can be enabled in a Hugo project in a number of ways.
-
-The [`emojify`](https://gohugo.io/functions/emojify/) function can be called directly in templates or [Inline Shortcodes](https://gohugo.io/templates/shortcode-templates/#inline-shortcodes).
-
-To enable emoji globally, set `enableEmoji` to `true` in your site’s [configuration](https://gohugo.io/getting-started/configuration/) and then you can type emoji shorthand codes directly in content files; e.g.
-
-
-