In their own words, taken from the docs, “Codeberg is a democratic community-driven, non-profit software development platform operated by Codeberg e.V. and centered around Codeberg.org, a Gitea-based software forge.”. Essentially, it is a non-profit platform run on donations for sharing free and open source software by providing a collaborative VCS environment based on Gitea. One good day I decided to move all my open source repositories from GitLab over to Codeberg, and that includes the hosting of this very website. This is the story of this migration.

From time to time I profile Gaia Sky to find CPU hot-spots that are hopefully easy to iron out. To do so, I launch my profiler of choice and look at the CPU times for the top offender methods. Today I went through such a process and was surprised to find a forEach() method of the Java streams API among the worst offenders. Was the forEach() slowing things down or was it simply that what’s inside the loop took too long to process? I found conflicting and inconsistent reports in the interwebs, so I set on a quest to provide my own answers.

Wayland is a modern display server protocol that will eventually replace X11. It is still not quite a hundred percent there, but it has been improving steadily and gaining ground over the past years. It is expected to become the new default display server on Linux systems at some point in the near future… Whatever near means in that context.

This past weekend I had some time to play around with Sway, a window manager and Wayland compositor that mimics i3. How did it go?

I have recently implemented a procedural generation system for planetary surfaces into Gaia Sky. In this post, I ponder about different methods and techniques for procedurally generating planets that look just right and explain the process behind it in somewhat detail. This is a rather technical post, so be warned. As a teaser, the following image shows a planet generated using the processes described in this article.

When I started using git as my VCS I skimmed the docs and git-bisect caught my eye. I got acquainted with it rather quickly and have been using it regularly ever since. git-bisect is a little handy git sub-command typically used to quickly narrow down the commit where a bug was introduced in a code base. It uses a simple binary search tree algorithm (BST) to test out different revisions by parting the remaining search space in half.

Do you often find yourself using “New feature”, “More” or similar short, useless and generic strings as your git commit messages? I know I did. Until I learned about semantic commit messages, that is. What are they and how can they exponentially improve your commit history and make it actually useful? I’m discussing it in this post.