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
GPG Key ID:
B75D4F293C7052DB
|
|
@ -2,4 +2,5 @@
|
|||
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"
|
||||
---
|
||||
|
||||
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'
|
||||
---
|
||||
|
||||
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
|
||||
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'
|
||||
---
|
||||
|
||||
My first goal for this project is to create a convenient all-round repository
|
||||
server implementation that could be used for everything from self-hosting a
|
||||
local repository to managing an entire distribution's package repository. It
|
||||
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.
|
||||
This project is a reimaginging of my Vieter project. While its goal is to
|
||||
eventually fully replace Vieter, I'm following a different mindset on how to
|
||||
get there.
|
||||
|
||||
The repositories can be populated by manually uploading packages to the server
|
||||
(e.g. from a CI build), or by mirroring already existing repositories. The
|
||||
mirroring feature in particular makes it trivial to set up a new mirror for a
|
||||
distribution, as the server would take care of keeping the mirror up-to-date.
|
||||
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.
|
||||
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.
|
||||
|
||||
Most users however don't need a full copy of a distro's package repository, so
|
||||
Rieter also provides a "smart mirror" mode. In this mode, a Rieter instance
|
||||
only syncs packages that have been requested before, e.g. from a previous
|
||||
system update. This way, your updates will still be a lot faster as the
|
||||
required packages are cached, but packages you don't use don't get stored,
|
||||
saving you a lot of storage space.
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -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'
|
||||
---
|
||||
|
||||
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" }}
|
||||
{{ .Content }}
|
||||
<h3>Latest blog posts</h3>
|
||||
<h3>Latest posts</h3>
|
||||
<ul id="posts">
|
||||
{{ range first 15 .Site.RegularPages }}
|
||||
{{ .Render "li" }}
|
||||
|
|
|
|||
Loading…
Reference in New Issue