Stefan Sperling @stsp@bsd.network

I will be hosting a #GameOfTrees version control system tutorial at #EuroBSDCon 2026, with @op as co-host (edit: Turns out Omar cannot make it; Johannes Thyssen Tishman will be co-hosting instead).

This tutorial will be suitable for both #Git experts and complete beginners. The experts will probably spend significant effort temporarily unlearning some things they know, while the beginners will spend moderate effort learning some things they didn't know. Our goal is that both groups will broaden their version control horizons a bit and have fun doing so ​

https://events.eurobsdcon.org/2026/talk/JJLZXQ/

For my company I have put together #gameoftrees and #OpenBSD support packages which cover tasks I have been doing via ad-hoc consulting gigs for years now. And I asked some freelancing friends from the OpenBSD community to share the work with me.

We support deployments of OpenBSD in server and firewall roles via yearly fixed-price contracts. All base system components can be supported.

From our existing client base we know for a fact that there are small and mid-sized businesses out there who run OpenBSD and would benefit from working with us. We want to find more of them.

https://chirpysoft.be/support.html

I will be hosting #OpenBSD and #PF firewall courses at @linuxhotel in the city of Essen, Germany.

OpenBSD: https://www.linuxhotel.de/course/openbsd-de

PF: https://www.linuxhotel.de/course/pf-de

Currently there are no dates set for either course, but it is possible to send Linuxhotel a proposal for the next date.

The target audience are system administrators who would like to learn about OpenBSD and PF in order to use them as part of their network security tool set.

(Do not be afraid to sign up if you do not understand German. While the courses are advertised in German, written course material will be in English and the presentation will be entirely in English if preferred by participants.)

#Git compatible version control system #GameOfTrees version 0.130 has been released.

This version adds server-side support for SHA256 repositories and defaults to SHA256 for newly created repositories.

We will be upgrading our @gothub hosting service to this version soon.

https://gameoftrees.org/releases/changes.html

"Wir testen einen von Grund auf neu gebauten Shop - probier ihn aus"

("We are testing a newly built from scratch shop -- try it out")

​

@johanneskastl Trying out got-portable binaries from the openSUSE buildservice on openSUSE Leap 16, I noticed a small problem:

Trying to clone a repository from github over HTTPS ends in an error: got-fetch-http: bufio_starttls

Can you reproduce this? If so, any idea why this happens?

When I try the same clone operation on OpenBSD it works as expected.

Is there some problem with libtls maybe?

The Gotweb authenticator app written by Johannes Thyssen Tishman which makes it easy to browse #Git repositories hosted on #GameOfTrees servers which require authentication is now available in #FDroid:

https://f-droid.org/en/packages/org.gameoftrees.gotweb_authenticator/

I have sent out a patch which adds server-side support for SHA256 #Git repositories to #GameOfTrees

https://marc.gameoftrees.org/mail/1791454203.84490_0.html

Patiently waiting for the #GameOfTrees gotweb authenticator app by jtt to appear on #Fdroid.

Removed a couple of idle VMs at @gothub from elapsed subscriptions yesterday. And promptly received a new subscription today ​ Always makes me happy when new people give it a try. And I don't mind people leaving when they discover it is not for them. Anyone who leaves is making space for new subscriptions. And quite a few subscribers do stick around, so we are healthy.

I've asked several @gothub subscribers whether they would consent to be listed on our public list of projects because the list we had was almost empty. A few people obliged, which is great! The list is now less empty.

When some people told me they had no public content to share for this list, I replied this didn't matter because the goal was showing public support for our Git hosting project, not making more of our hosted content visible to the public.

An interesting fact I learned is that some projects are keeping their repositories completely private not because they generally want them to be private, but because they don't want them to be scraped by big tech LLM companies.

This is a use case I had not really considered from this angle before. I assumed every project would follow our recommendation to allow the public "anonymous" user in, unless the project's code was indeed proprietary. Which effectively blocks stupid crawlers that don't know how to log in, but isn't 100% tight and future-proof. And this shows that some projects are starting to shut their doors, not really because they don't want to share code, but because of all this external pressure. Which is sad. But we can give them one way forward. Adding additional accounts for known users is easy to do and accounts are virtually limitless (we could keep adding users until user ID "UINT_MAX - 1", though the /home filesystem would probably give in way before then). It is possible to build sizeable closed communities here without being forced to share code in the open, without allowing any LLM to look at it, and without a need to setup a complicated VPN or similar to hide everything away. Every user account is essentially just a public SSH key. If your key is accepted, you get access. People with access shouldn't be creating public mirrors of the content elsewhere, of course, which is an inherent risk in this big-tech-scraper threat model, and in any closed community really.

But overall, this is a very sad sate of affairs for young FOSS projects who want to avoid big tech. The situation was very different when I started out in the 2000s. Avoiding big tech wasn't difficult.