Bastian Greshake Tzovaras

[![a black and white photo of a swarm of pigeons
mid-flight](/assets/images/2024-09-10-birds.jpg)](/assets/images/2024-09-10-birds.jpg)

I have recently [started to move my personal code repositories away from
GitHub](/from-codeberg), in favor of hosting them with a [smaller,
independent and collectively managed
alternative](https://codeberg.org/) - including for this static website.
In the same spirit, I was also interested in whether I could be doing my
small part to diversify my overall web hosting approach. Because, as
nicely outlined in [*Any Technology Indistinguishable From Magic is
Hiding
Something*](https://www.fromjason.xyz/p/notebook/any-technology-indistinguishable-from-magic-is-hiding-something/)
by Jason, the cloud is not only just other people's computers, but 3/4th
of those computers are owned by Google, Amazon & Microsoft.

So, I wanted to get started with non-essential services that I could
potentially self-deploy on some small hoster (i.e. I didn't want to run
my own mail server just yet). As a simple and affordable,
pay-what-you-want hoster, I went with
[*Uberspace*](https://uberspace.de/en/), which provides a simple but
well-equipped Linux shell to run your things on.

I decided to start off with
[*FreshRSS*](https://github.com/FreshRSS/FreshRSS/)^[\[1\]](#fn1)^ -
which is an RSS reader that can be accessed from the web, but also
through an API to tie in with my RSS-reader programs on my computers and
phone - and a *[Wallabag](https://github.com/wallabag)*, a read-later
service to jot down things to read. And luckily, the [collectively
written experimental documentation of
Uberspace](https://lab.uberspace.de/) helpfully provided instructions
for easily setting up both tools!

At about the same time I also [moved the code for my little
*PersonalAPI* Django-app to
*Codeberg*](https://codeberg.org/gedankenstuecke/personal-api). As part
of that move, I had to figure out how to get
*[Woodpecker](https://woodpecker-ci.org/)*, the CI that Codeberg kindly
provides, to automatically deploy any changes to *Heroku* - where the
little Django-app lived so far. In the end, [I managed to write a little
CI
script](https://codeberg.org/gedankenstuecke/personal-api/src/commit/b2058c9d617cea07d42015e63683f9ecd04963ff/.woodpecker.yaml)
that used the Heroku API to push changes.

But that made me wonder: Instead of using Heroku, could I just get that
Django-app to run on Uberspace too? [Heroku was bought by Salesforce in
2010](https://en.wikipedia.org/wiki/Heroku), and while for a while it
used to be free for small hobby projects like my *Personal API* project,
just using their smallest database by now costs a good bit of money. And
remember how 75% of all "cloud" services are just Amazon, Google or
Microsoft? Heroku is also just Amazon's AWS with a fake mustache.

Just as for *Wallabag* and *FreshRSS*, the Uberspace Lab docs have a
good [starting point on how to get Django apps running on their
infrastructure](https://lab.uberspace.de/guide_django/). I just made
some minor tweaks to that, to re-use the `pipenv`{.language-plaintext
.highlighter-rouge}-setup of the existing deployment to encapsulate the
dependency/Python versions. But even with that, it was extremely quick
and painless to get it up and running! It led to the next problem
though: How to automate the deployment on the Uberspace?

The Uberspace lab docs didn't provide a best pathway for CI deployments
that weren't just based on `rsync`{.language-plaintext
.highlighter-rouge}-ing files over. But with some research I found
[`webhook`{.language-plaintext
.highlighter-rouge}](https://github.com/adnanh/webhook), which can
provide a quite simple way to setup your own webhooks that can be
triggered by sending `GET`{.language-plaintext .highlighter-rouge} or
`POST`{.language-plaintext .highlighter-rouge} requests. It turned out
to be quite easy to install even. In the spirit of giving back to the
great *lab*-documentation, I've already [made a successful PR to expand
the documentation on a section on how to install
`webhook`{.language-plaintext
.highlighter-rouge}](https://lab.uberspace.de/guide_webhook/).

When triggered, my webhook for deploying the *PersonalAPI* fetches the
latest version of the code from *Codeberg*, applies any potential
database migrations, re-collects the static files and restarts the
web-server for good measure. With that in place, I just needed to [adapt
the CI-script that is triggered on
Codeberg](https://codeberg.org/gedankenstuecke/personal-api/src/commit/f083ef8ed01777c1ecc797684d38a9d2a6cb9e33/.woodpecker.yaml)
to be good to go.

I'm really happy with that strung-together solution (and the other small
bits of self-deployed solutions). First of all, it lets me take some
more control over things, while learning a few new things in the process
and hopefully also lessening the burden on others that kindly host
publicly accessible tools. Secondly, it helps me to move away from the
over-reliance on big-tech hosters. Instead of throwing too much money
each month at Heroku/Salesforce/AWS (or some *Software as a
Service*-provider), I'd much rather throw about the same amount of money
at a small, independent hoster.

------------------------------------------------------------------------

Links to the respective how-tos/configs:

- [Installing Webhooks on
  Uberspace](https://lab.uberspace.de/guide_webhook/)
- [My *Woodpecker* CI
  pipeline](https://codeberg.org/gedankenstuecke/personal-api/src/commit/f083ef8ed01777c1ecc797684d38a9d2a6cb9e33/.woodpecker.yaml)

My `redeploy.sh`{.language-plaintext .highlighter-rouge} simply consists
of:

:::: {.language-plaintext .highlighter-rouge}
::: {.highlight}
``` highlight
#!/bin/env bash

REPO="${HOME}/personal-api/"

git -C ${REPO} fetch && git -C ${REPO} rebase
cd ${REPO}
pipenv run ./manage.py migrate
pipenv run ./manage.py collectstatic --noinput

supervisorctl restart myapi
```
:::
::::

------------------------------------------------------------------------

[[\[1\]](#fn1-anchor) I already switched to another free FreshRSS
instance back when *Feedly* had [started its union-busting
services](https://www.citationneeded.news/feedly-launches-strikebreaking-as/),
but thought I could just as well deploy it myself.]{.small}


I have recently started to move my personal code repositories away from GitHub, in favor of hosting them with a smaller, independent and collectively managed alternative - including for this static website. In the same spirit, I was also interested in whether I could be doing my small part to diversify my overall web hosting approach.

Self-deploying more of my own small web

A video of Panoramax in action. Starting out with a map view which has
small orange lines for where images are available. Then going into the
actual 360 degree images and moving around.

[Above: a video showcasing the panoramax viewer, with a map to see where
(most^[\[1\]](#fn1)^) images are, and the 360º views.]{.small}

**tl;dr: If you are interested in contributing to a street-level imagery
commons, [check out *Panoramax*](https://panoramax.fr/)**

Street-level images are not just a great way to virtually explore places
(or for playing the not-so-occasional round of
[GeoGuessr](https://www.geoguessr.com/)), but are also extremely useful
for providing detailed local information when contributing to
[OpenStreetMap](https://www.openstreetmap.org).

Of course, most of those street-level image collections are produced and
controlled by big tech, including Google, Apple and Microsoft. And so,
I'd been wondering for a while, if there were any free/open alternatives
to those these days. While, back when street-view imagery first started
out, a lot of specialised equipment was needed to get GPS-registered,
360º images, today there's at least somewhat affordable 360º consumer
cameras that directly write GPS coordinates too. And beyond that - if
photospheres aren't a hard requirement - each and every smartphone will
provide geo-located photos.

With some longer road trips in the current and future - and a wish to
convert those into photo data collection trips if possible - I looked
into the topic again a few weeks ago and found this [great overview of
street-level imagery
services](https://wiki.openstreetmap.org/wiki/Street-level_imagery_services)
on the wiki of *OpenStreetMap*. At first glance it might seem that
there's some options to choose from if one wants to record openly
licensed images, but the reality is somewhat sadder: *Mapillary* and
*KartaView* both make use of *CC-BY-SA* as their license, but the
underlaying stack for hosting and controlling those images are far from
open. Not only are their backends, viewers and uploaders all
proprietary, they are owned by big tech - *Facebook* & *Grab*,
respectively. Proprietary tools owned & controlled by big tech promise
the exact opposite of commoning, so those definitely were out. But, then
I saw [*Panoramax*](https://panoramax.fr) in that list, which pretty
much ticks all the boxes for building a sustainable commons.

Supported and developed by the *Geocommons Factory* of the French
[*National Institute of Geographic and Forest
Information*](https://www.ign.fr/institut) (IGN), each part of the whole
*Panoramax* street-level imagery pipeline is openly licensed: From the
different modes of uploading data (there's a web uploader and a CLI tool
already), over the backand and the embeddable viewer, to the data
itself. And not only that, the system is set-up to allow for federation.
Which means that people can spin up their own local instances if they so
wish.

The federation of *Panoramax* helps to address two of the big challenges
with providing comprehensive street-level imagery. The first being the
pure cost of storage. While storage prices are low, keeping around
potentially millions and billions of 360º photospheres from around the
world is still a peta- if not exabyte problem. Just keeping those data
around in a centralised way is expensive.

The second challenge being potential differences in legal requirements
around anonymity/privacy, e.g. in what needs to be blurred/removed.
*Panoramax* provides an API to automatically send each image to a photo
blurring service, to e.g. blur out people's faces or license plates. But
depending on the jurisdiction, other things might need to be anonymised
too, and local Panoramax instances can also chose blurring methods that
suit those needs.

So far, there are two publicly accessible *Panoramax* instances: [One
run by the French IGN](https://panoramax.ign.fr), which is limited in
scope to images taken in France. And [one run by the French chapter of
*OpenStreetMap*](https://panoramax.openstreetmap.fr), which accepts
images from a global scope at least for testing (they do not want to
become the single repository for the world's street-level images).
Lastly, you can see the federation in action [on this joint map that
includes that from both](https://api.panoramax.xyz).

Which is all a long-winded way of saying: I've been contributing images
to Panoramax since mid-July and I'm having a blast. Since then, I've
contributed around 40k images, taken with a 360º camera that takes
images every 2 seconds. Mostly by car, but also [by
foot](https://scholar.social/@gedankenstuecke/112763921080835205) (and
[Eugenia by
bike](https://scholar.social/@gedankenstuecke/112779020016826824)). On
roads, in the woods and some parks. Between England, France, Belgium,
the Netherlands and Germany, for a total distance covered of around
2,500 km.

If you're now interested in contributing: You do not need a 360º camera
that can do photospheres, any smartphone will do to get started. You
[can check out the instructions on the French OSM
instance](https://panoramax.openstreetmap.fr). And if you want to learn
more about *Panoramax*, Christian Quest of the project [gave a talk at
last year's *State of the Map
Europe*](https://www.youtube.com/watch?v=Vh87F5Zie6k).

[[\[1\]](#fn1-anchor) *Mostly*, as currently the cut-off for joining
images on the map visualisation [is too low for the speeds on
highways](https://gitlab.com/panoramax/server/api/-/issues/177) but a
fix has already [been
proposed](https://gitlab.com/panoramax/server/api/-/merge_requests/300).]{.small}


A video of Panoramax in action. Starting out with a map view which has small orange lines for where images are available. Then going into the actual 360 degree images and moving around. Above: a video showcasing the panoramax viewer, with a map to see where (most

 [1]

) images are, and the 360º views.

Openly licensed streetview with Panoramax

[![a black and white photo of a person sitting on a fence overlooking a
mountain
scene](/assets/images/2024-07-22-hagiang.jpg)](/assets/images/2024-07-22-hagiang.jpg)

In the [last blog post](/seizing-means-of-computation/), I had mentioned
that I was looking to move away some of my personal code hosting away
from GitHub (GH), to avoid being locked in into yet another tech giant.
Instead, I wanted to move to a proper free alternative. On Mastodon,
lots of folks recommended checking out [Codeberg](https://codeberg.org/)
as a potential alternative that is based on
[forgejo](https://forgejo.org/) and provides [static page
hosting](https://codeberg.page/).

Beyond actually running on open source software, I particularly like the
idea of how they organize [the governance of the
platform](https://docs.codeberg.org/getting-started/what-is-codeberg/#what-is-codeberg-e.v.%3F):
Codeberg is structured as a registered non-profit association (or
*eingetragener Verein*) in Berlin. And while one doesn't have to become
a (paying & active) member of the association to make an account, I love
that this is an option. Beyond the financial support, the membership
also means having a more active role in the governance, including the
ability to vote on the presidium & board.

And so I made the switch over the last week, at least for the first two
projects: This website you're currently reading and the [*One Button
Tracker* for the Puck.js](https://tzovar.as/one-button-tracker/), which
both are based on static hosting.

As Codeberg, unlike GH pages does not automatically integrate with
static site generators like Jekyll a bit more manual setup was needed,
but [thanks to the extensive
documentation](https://docs.codeberg.org/codeberg-pages/) that was quite
doable. To automate a build from a static site generator like Jekyll
(which this site uses), one can use of Codeberg's deployment of the
[*Woodpecker CI*](https://woodpecker-ci.org/). The CI can can create the
build based on a `source`{.language-plaintext .highlighter-rouge}
repository to then push the output into a `pages`{.language-plaintext
.highlighter-rouge} repository that codeberg.page can then serve.
Luckily, Codeberg [even provides an example `yaml`{.language-plaintext
.highlighter-rouge} Woodpecker config
file](https://codeberg.org/Codeberg-CI/examples/src/branch/main/Jekyll/.woodpecker)
for this.

As this all worked like a charm, I [flipped the DNS settings for my
domain
yesterday](https://scholar.social/@gedankenstuecke/112823968573749986)
and since then this page is being delivered through Codeberg. The one
thing I then noticed was that [Codeberg does not handle custom domain
settings in 100% the same way that GitHub
does](https://codeberg.org/Codeberg/Community/issues/1525): With GitHub,
once you have setup `mydomain.tld`{.language-plaintext
.highlighter-rouge} for the main user GH page, all further
project-repositories will be accessible as
`mydomain.tld/project_repo_name`{.language-plaintext .highlighter-rouge}
(unless you setup a custom domain for them too), which does not happen
with Codeberg.page.

But luckily, there's an easy - albeit slightly inelegant - fix for it:
Codeberg.page also looks for a `_redirects`{.language-plaintext
.highlighter-rouge} file, in [which one can specify
redirects](https://docs.codeberg.org/codeberg-pages/redirects/). Which
is what I did for the *one button tracker*, which before was accessible
at `tzovar.as/one-button-tracker`{.language-plaintext
.highlighter-rouge}, despite being hosted in a different repository.
With the redirect that link will still work, despite now being at
`https://gedankenstuecke.codeberg.page/one-button-tracker/`{.language-plaintext
.highlighter-rouge}.

When I started the process of moving even just these two repositories I
was slightly worried about how many things could (and thus probably
would) break. But it turns out that this was extremely painless! And,
I'm super happy to have these pages and projects now be hosted in a
place a lot more aligned to my own interests and values. Let's see if
replacing Google as my email provider will be on the menu next!

------------------------------------------------------------------------

Yes, I also use these posts to document this stuff for my forgetful
self, so here are the links to the setup files:

- [source repository](https://codeberg.org/gedankenstuecke/pages-source)
- [final pages repository](https://codeberg.org/gedankenstuecke/pages)
- [Woodpecker
  setup](https://codeberg.org/gedankenstuecke/pages-source/src/branch/master/.woodpecker.yaml)
- [`_redirects`{.language-plaintext
  .highlighter-rouge}](https://codeberg.org/gedankenstuecke/pages-source/src/branch/master/_redirects)


In the last blog post, I had mentioned that I was looking to move away some of my personal code hosting away from GitHub (GH), to avoid being locked in into yet another tech giant. Instead, I wanted to move to a proper free alternative. On Mastodon, lots of folks recommended checking out Codeberg as a potential alternative that is based on forgejo and provides static page hosting.

Code from some mountaintop

[![a black and white photo of a fence overlooking some train
tracks](/assets/images/2024-07-04-fence.jpg)](/assets/images/2024-07-04-fence.jpg)

Or: Why 2024 is my personal *year of Linux on the desktop*

According to Doctorow, [*enshittification* might be coming *for
absolutely everything*](https://en.wikipedia.org/wiki/Enshittification).
I've more and more felt this was for my own digital devices and means of
digital production: Be that Apple's just increasing love for walled
gardens - especially since having the opaque app review processes (c.f.
[cpython's `--with-app-store-compliance`{.language-plaintext
.highlighter-rouge}](https://github.com/python/cpython/pull/120984)),
Microsoft's (successful?) attempts to [monopolize open source through
GitHub & VS code](https://ghuntley.com/fracture/), or Google's enclosure
of email, maps, and even the browser market. And then there's Adobe's
lock-in through its subscription model and maybe the [final loss of
trust over whether and how they use their customer data to train
'AI'](https://www.theverge.com/2024/6/7/24173838/adobe-tos-update-firefly-generative-ai-trust).

While none of these troublesome developments are really *new*, I feel
like they now collectively have reached my personal tipping point --- at
which it felt like too much of cognitive dissonance between my own
interests in contributing to an open and collectively owned digital
infrastructure, and the closed tools I used for building those. Which is
why I've recently started to divest my personal computing environments
from closed systems, and started to move towards free/open software
alternatives where possible. Luckily, thanks to efforts by folks like
Robert W. Gehl (of [*FOSS Academic*](https://fossacademic.tech/)),
[David Llwellyn-Jones](https://www.flypig.co.uk/blog), and projects like
the [*Opt-Out Project*](https://www.optoutproject.net/) or [*Switching
Software*](https://switching.software/), there is also plenty of
documentation how to do this.

To dip my toes (back or deeper) into it, I started out by replacing *VS
Code* with good old `vim`{.language-plaintext .highlighter-rouge} a few
weeks ago, and have been refreshing my muscle memory for all the
shortcuts ever since. Similarly, I've started to replace *Google Maps*
with [*Organic Maps*](https://organicmaps.app/), which uses
*OpenStreetMap* for its maps (and which also provides an easy way to
make minor contributions to it). The change I was most worried about was
how I would replace Adobe's *Lightroom* as my main photo editing suite
(as that was always one of the main drivers to stick with Mac OS for
me). But, after [seeing the great work done with *Darktable* on
Mastodon](https://mastodon.social/@darktable) I gave that a go and was
a) impressed with the quality of the output and b) more than happy with
using that for my photo workflows.

And so a couple of weeks ago I ordered a machine to replace my aging
MacBook - the DIY version of the 13\" Framework Laptop, to also benefit
from the modular repairability going forward. The assembly and
installing Ubuntu were both without any issues, and since then I\'ve
been using it as my main (non-paid work) machine! And (as I had hoped),
my day to day kept being nearly^[\[1\]](#fn1)^ drama free! I\'ve already
successfully scanned & edited the first \~10 rolls of film using VueScan
& DarkTable (some of which [are already on
Flickr](https://www.flickr.com/photos/gedankenstuecke/)). If you\'re
looking for a free & open alternative to Lightroom I\'d strongly suggest
giving it a try. The paradigms to editing are a bit different to
Adobe\'s, but nothing one wouldn\'t get quite quickly used to --- I had
used Lightroom for 15+ years and still managed to make the switch.

I'm quite happy with the changes made so far, but of course I know that
there's a lot of more things I could (and hopefully will) replace with
more open alternatives in the future. Which I plan on, once I've made
myself comfortable with the replacements done so far. Here's some rough
next steps I already have on my roadmap:

1.  Leave Google Mail for something non-Google
2.  Move my own projects away from GitHub to a free alternative
3.  In the very long run: replace iOS as my mobile OS

If you have recommendations for any of those, [drop me a line on
Mastodon](https://scholar.social/@gedankenstuecke)!

[[\[1\]](#fn1-anchor) This was actually the one slightly less trivial
thing, so this at least partially serves as my own reminder: My 35mm
negative scanner - a Pacific Image Electronics PrimeFilm XA - didn\'t
allow scanning as non-root with plug & play. I fixed this by adding
`SUBSYSTEMS=="usb", ATTRS{idVendor}=="ID", ATTRS{idProduct}=="ID", MODE="0666"`
into a freshly made `/lib/udev/rules.d/40-scanner.rules` file. The `ID`
can be found via `lsusb`.]{.small}


Or: Why 2024 is my personal

 year of Linux on the desktop

According to Doctorow,

 enshittification

might be coming

 for absolutely everything

. I’ve more and more felt this was for my own digital devices and means of digital production: Be that Apple’s just increasing love for walled gardens - especially since having the opaque app review processes (c.f. cpython’s --with-app-store-compliance), Microsoft’s (successful?)

Messaggi di Rogue Scholar

Self-deploying more of my own small web

Openly licensed streetview with Panoramax

Code from some mountaintop

Seizing my means of computation