write intro texts for the various projects
ci/woodpecker/push/woodpecker Pipeline failed
Details
ci/woodpecker/push/woodpecker Pipeline failed
Details
parent
4374c7f280
commit
ea1970caa7
|
@ -2,4 +2,5 @@
|
||||||
title: "Blog"
|
title: "Blog"
|
||||||
---
|
---
|
||||||
|
|
||||||
uwu
|
Sometimes I want to talk about things that aren't related to any of my
|
||||||
|
projects. These posts end up here!
|
||||||
|
|
|
@ -2,4 +2,11 @@
|
||||||
title: "Projects"
|
title: "Projects"
|
||||||
---
|
---
|
||||||
|
|
||||||
Hello!
|
Throughout the years, I've created (and dropped) a lot of projects. Some were
|
||||||
|
built out of necessity, others simply because I thought it was cool. This
|
||||||
|
section of my site is where I can talk about these projects that I'm so
|
||||||
|
passionate about!
|
||||||
|
|
||||||
|
The posts for the various projects mostly consist of devlogs and version
|
||||||
|
release announcements. Each project has its own RSS feed, so you can subscribe
|
||||||
|
to the ones you'd like to follow.
|
||||||
|
|
|
@ -8,4 +8,24 @@ params:
|
||||||
url: 'https://git.rustybever.be/Chewing_Bever/alex'
|
url: 'https://git.rustybever.be/Chewing_Bever/alex'
|
||||||
---
|
---
|
||||||
|
|
||||||
|
Alex was created to solve an issue I'd been having: inconcistent Minecraft
|
||||||
|
server backups.
|
||||||
|
|
||||||
|
My original backup system involved compressing the server world and config
|
||||||
|
directories in a tarball. While this usually worked, the command regularly
|
||||||
|
failed due to conflicts while reading a file the server was writing to. Because
|
||||||
|
the Minecraft server is unaware of the fact it's being backed up, it
|
||||||
|
continuously writes data to disk, preventing the tar command from doing its
|
||||||
|
job.
|
||||||
|
|
||||||
|
My solution for this consisted of designing a process that wraps the Minecraft
|
||||||
|
server process and interacts with its standard input. The Minecraft server
|
||||||
|
accepts certain commands (`save-all` and `save-on`/`save-off`) that allow an
|
||||||
|
admin to control when and if the server writes data to disk. Using this, the
|
||||||
|
wrapper process tells the server to flush all data, stop writing to disk, and
|
||||||
|
only resume writing after a successful backup has been created.
|
||||||
|
|
||||||
|
This idea was then expanded to implement incremental backups, which greatly
|
||||||
|
reduced the time and disk size needed for the backups. For reference, our
|
||||||
|
~2.5GB world folder can be backed up incrementally in less than 5 seconds, with
|
||||||
|
backups running every thirty minutes, without ever turning off the server.
|
||||||
|
|
|
@ -7,3 +7,9 @@ params:
|
||||||
- name: Source
|
- name: Source
|
||||||
url: 'https://git.rustybever.be/Chewing_Bever/lander'
|
url: 'https://git.rustybever.be/Chewing_Bever/lander'
|
||||||
---
|
---
|
||||||
|
|
||||||
|
Lander is my personal URL shortener, pastebin and file-sharing service. I've
|
||||||
|
always wanted to make one of these myself, and as an added challenge, I built
|
||||||
|
everything (except for the HTTP parser) from the ground up. It's built on a
|
||||||
|
home-grown epoll-based event loop on top of which I built an HTTP framework
|
||||||
|
that I'm also planning to use for some other projects.
|
||||||
|
|
|
@ -8,24 +8,24 @@ params:
|
||||||
url: 'https://git.rustybever.be/Chewing_Bever/rieter'
|
url: 'https://git.rustybever.be/Chewing_Bever/rieter'
|
||||||
---
|
---
|
||||||
|
|
||||||
My first goal for this project is to create a convenient all-round repository
|
This project is a reimaginging of my Vieter project. While its goal is to
|
||||||
server implementation that could be used for everything from self-hosting a
|
eventually fully replace Vieter, I'm following a different mindset on how to
|
||||||
local repository to managing an entire distribution's package repository. It
|
get there.
|
||||||
should be easy to deploy, lightweight, and work with any distribution. It
|
|
||||||
should support any number of repositories and packages, and work with any
|
|
||||||
package architecture.
|
|
||||||
|
|
||||||
The repositories can be populated by manually uploading packages to the server
|
First and foremost, I want to make a well-designed Pacman repository server
|
||||||
(e.g. from a CI build), or by mirroring already existing repositories. The
|
that anyone can set up on any device, be it a Raspberry Pi or a beefy server.
|
||||||
mirroring feature in particular makes it trivial to set up a new mirror for a
|
Rieter should be usable for anything from a small personal repository all the
|
||||||
distribution, as the server would take care of keeping the mirror up-to-date.
|
way to a full mirror of a distribution's package server.
|
||||||
Another usecase for this would be creating a local mirror of your
|
|
||||||
distribution's repositories, which can greatly reduce your update times
|
|
||||||
depending on your internet connection.
|
|
||||||
|
|
||||||
Most users however don't need a full copy of a distro's package repository, so
|
Something that also fits nicely in this concept is mirroring. Rieter will
|
||||||
Rieter also provides a "smart mirror" mode. In this mode, a Rieter instance
|
support automatically mirroring upstream repositories. This could be used to
|
||||||
only syncs packages that have been requested before, e.g. from a previous
|
support your distribution by setting up a new public mirror, or to speed up
|
||||||
system update. This way, your updates will still be a lot faster as the
|
your updates by keeping a mirror of the repositories in your local network.
|
||||||
required packages are cached, but packages you don't use don't get stored,
|
|
||||||
saving you a lot of storage space.
|
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.
|
||||||
|
|
|
@ -0,0 +1,19 @@
|
||||||
|
---
|
||||||
|
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.
|
|
@ -12,4 +12,18 @@ params:
|
||||||
url: '/api-docs/vieter'
|
url: '/api-docs/vieter'
|
||||||
---
|
---
|
||||||
|
|
||||||
lmao what
|
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!
|
||||||
|
|
|
@ -1,33 +0,0 @@
|
||||||
---
|
|
||||||
title: "Links"
|
|
||||||
---
|
|
||||||
|
|
||||||
### Vieter
|
|
||||||
|
|
||||||
An implementation of an Arch repository server combined with a build system,
|
|
||||||
written in V.
|
|
||||||
|
|
||||||
* [Source](https://git.rustybever.be/vieter-v/vieter)
|
|
||||||
* [Docs](/docs/vieter)
|
|
||||||
* [API Docs](/api-docs/vieter)
|
|
||||||
|
|
||||||
### Alex
|
|
||||||
|
|
||||||
Minecraft server process wrapper that automates creating (incremental) backups,
|
|
||||||
written in Rust.
|
|
||||||
|
|
||||||
* [Source](https://git.rustybever.be/Chewing_Bever/alex)
|
|
||||||
|
|
||||||
### Site
|
|
||||||
|
|
||||||
This site is fully open-source, and the backend is a custom Rust web server
|
|
||||||
that I've designed to update the hosted files using POST requests from my CI.
|
|
||||||
|
|
||||||
* [Backend Source](https://git.rustybever.be/Chewing_Bever/site-backend)
|
|
||||||
* [Blog Source](https://git.rustybever.be/Chewing_Bever/site)
|
|
||||||
|
|
||||||
## Lander
|
|
||||||
|
|
||||||
My home-grown URL shortener & pastebin, written from the ground up in C.
|
|
||||||
|
|
||||||
* [Source](https://git.rustybever.be/Chewing_Bever/lander)
|
|
|
@ -1,6 +0,0 @@
|
||||||
<h3>{{ i18n "projects.title" }}</h3>
|
|
||||||
<ul id="projects">
|
|
||||||
{{- range where .Site.Pages "Section" "projects" }}
|
|
||||||
{{ .Render "li" }}
|
|
||||||
{{- end }}
|
|
||||||
</ul>
|
|
|
@ -1,4 +0,0 @@
|
||||||
{{ define "main" }}
|
|
||||||
{{ .Content }}
|
|
||||||
{{- partial "projects.html" . -}}
|
|
||||||
{{ end }}
|
|
|
@ -1,6 +0,0 @@
|
||||||
<li>
|
|
||||||
<a href="{{ .PermaLink }}">
|
|
||||||
{{ .Title }}
|
|
||||||
<small>{{ .Summary }}</small>
|
|
||||||
</a>
|
|
||||||
</li>
|
|
|
@ -1,6 +1,6 @@
|
||||||
{{ define "main" }}
|
{{ define "main" }}
|
||||||
{{ .Content }}
|
{{ .Content }}
|
||||||
<h3>Latest blog posts</h3>
|
<h3>Latest posts</h3>
|
||||||
<ul id="posts">
|
<ul id="posts">
|
||||||
{{ range first 15 .Site.RegularPages }}
|
{{ range first 15 .Site.RegularPages }}
|
||||||
{{ .Render "li" }}
|
{{ .Render "li" }}
|
||||||
|
|
Loading…
Reference in New Issue