It’s been a very long time since the last post on updates for weltschmerz, my terminal emulator. The last post, reporting on version 1.5.0, was published around four years ago. With today’s release of version 1.9.0, it’s finally time to catch up!

Drag & drop

Commit 2fdbf96, released with version 1.6.0, makes weltschmerz act as a drop target for both text and URIs, making it possible to drag and drop files, links, and ordinary text from other applications into the terminal. If files are dropped, weltschmerz normalizes them for use in the shell so that you don’t need to worry about escaping spaces or such.

FreeBSD compatibility

Version 1.7.0 was mainly a compatibility release that targeted the FreeBSD operating system. Most changes were related to the Makefile, which now uses more compatible invocations of install(1) and drops usage of $<, which FreeBSD make only allows for suffix-transformation rules and not explicit rules like GNU make does. See commit 623985d and commit 9e23bc6.

In addition, since commit d6090f7, weltschmerz now also considers /compat/linux/proc when trying to determine the current working directory (and OSC 7 support has been turned off). These changes make weltschmerz work flawlessly out of the box with FreeBSD.

Configurable resize hints

The release of version 1.8.0 added another small feature: configurable resize hints. For the longest time, weltschmerz had defaulted to allowing size changes only in increments of the cell size. This ensured that there was no padding around the terminal and that the window was always perfectly sized for its contents. This is especially advantageous when using floating windows.

However, when weltschmerz was then placed into a tiled context, instead of having padding on the terminal side, there were visible gaps between the actual windows. Sadly, there is no perfect solution for this, but I felt that this behaviour should at least be configurable.

Removing deprecated functionality

Over the years I have also removed a bunch of deprecated functionality from weltschmerz.

spawn_async

With the release of 1.6.0 came a change that was completely inconsequential for users but quite important for me because it had been a cause for annoyance for basically the entire existence of the program: the deprecation of spawn_sync. This function is used when weltschmerz needs to spawn a process; the shell, for example.

The problem: upstream had deprecated spawn_sync, but the Vala bindings for its replacement, spawn_async, were broken. The cause of the breakage had been known since 2018, but the fix was only committed in early 2022. I noticed only quite a bit later and fixed it with commit a2ab0ab in November of 2022.

Switching weltschmerz to termprops

With VTE 0.78 came the deprecation of a bunch of helper functions in favour of a termprop-based system. weltschmerz specifically was using the get_window_title and get_current_directory functions, which have been subsumed by the XTERM_TITLE and CURRENT_DIRECTORY_URI termprops. Version 1.9.0 now uses the termprops directly.

This would usually be uninteresting for the end user, but the migration away from get_window_title actually also fixes a bug that caused weltschmerz to segfault. It seems that the Vala bindings for the vte.window_title property are buggy and indicate that the property is a non-nullable string when in reality vte.window_title is internally translated to a call to get_window_title, which returns a nullable string. weltschmerz assumed vte.window_title was correct and never checked for null.

This is not an issue unless you can force the window title to be null. My partner found a clever way to do so: by passing an overlong title to the OSC mechanism, a code path in VTE is triggered that leaves the window title as null. Running the following in versions previous to 1.9.0 would reliably crash weltschmerz:

python -c 'print(f\'\\033]0;{"."*1025}\\033\\\\\')'

Makefile and meson.build improvements

My partner also contributed two more improvements to the Makefile, which now standardizes on one way of doing variable expansions and allows passing CFLAGS to the compiler. In addition, I finally made meson use the locale keyword for install_man instead of installing the translated manual pages manually.

“bold is bright” and IPv6 addresses

A new feature in 1.9.0 is the bold-is-bright setting, which controls whether bold characters are also automatically drawn in bright colors, like some older terminal emulators do. This change had been sitting around uncommitted for a very long time, and I finally decided to include it.

And last but not least, my partner taught the URL matching mechanism about bare IPv6 addresses, which are now clickable.

That’s it for this update. See NEWS for the full set of changes, and 1.5.0..1.9.0 for all relevant commits. Download weltschmerz on its project page.

Synopsis

hircine is a web application built to organize large collections of comics and manga. It imports image files from ZIP archives, supports a wide range of metadata, comes with a powerful filtering system, and keeps its own object store of processed image files for easy and fast access via the browser.

Archives are never modified by the program, making it an ideal choice for the astute collector. Comics may be read in the minimal built-in reader. Metadata import via scrapers is also supported.

Resources

• Homepage
• Git repository

Today, a bit more than 4 months since the last update for weltschmerz, I’m happy to announce 1.5.0, bringing new and exciting features to the terminal emulator. Just like with 1.4.0 most of them were designed and implemented by nortti. Thanks a lot!

Head over to the project page to download the new version right away, or read on to take a look at noteworthy changes.

Open with …

The main new feature in weltschmerz 1.5.0, added in a9706ec, is the ability to add custom ‘Open with …’ handlers for the URI context menu. These are added to the new open-with section in the configuration file. For example, the handlers in the picture above are defined like so:

[open-with]
mpv = mpv --force-window=immediate --really-quiet %
ff-priv = firefox-bin --private-window %

Any occurrence of the % character will be replaced by the URI before weltschmerz launches the given program.

Changes to OSC 7 handling

To increase compatibility with systems and setups that do not understand or emit OSC 7 escapes, weltschmerz now falls back to obtaining its current directory from the procfs subsystem. Additionally, a new option ‘prefer-osc7’ has been introduced that controls whether OSC 7 should be preferred at all. See 71388f9 and 6f03994.

Small bugfixes and more internationalization

When matching URLs, weltschmerz now ignores punctuation at the end. This should make it easier to open up URLs in terminal-bound chat applications. Finally, version 1.5.0 contains a full Finnish translation of the manual.

That’s it for this update. See NEWS for the full set of changes, and 1.4.1..1.5.0 for all relevant commits.

Do you ever find yourself in the middle of nowhere, in the northern Ashlands of Vvardenfell, and suddenly think: “Damn, what’s my fastest way to Tel Branora from here? I still have to deliver Mistress Therana’s skirt!"

Depending on the character you play, the answer to this question can vary wildly. For one you could try to reach Khuul and rely on regular fast travel services like the Silt Strider and the Guild Guide, but maybe you’re playing a particularly stuck-up Telvanni and would like to avoid interacting with the Imperial rats of the Mages Guild. Valenvaryon or Falasmaryon is close, and you have picked up all Propylon indices already, so that is a very good alternative. Or maybe you’re feeling the need for some fresh sea air and would like to sail all around Vvardenfell.

Morrowind’s fast travel system is extensive and complex, so figuring out the fastest routes from any one location to another is not an easy task. Even worse, some of the best travel options (the intervention spells that teleport you to the next Temple or Imperial Shrine) are hard to know when to use optimally.

Morrowind veterans probably have a very good idea of the intricacies of Vvardenfell’s travel routes and can figure out the above problem in seconds, but maybe you’ve just started the game and feel a bit overwhelmed, or you just installed Tamriel Rebuilt and have to suddenly juggle a multitude of new routes.

The latter is true for me, so I ended up writing ywalk, a command-line tool that figures out the fastest route between a set of places in Morrowind. It can consider certain limitations (Telvanni disdain for the Mages Guild perhaps, or having to escort yet another lost pilgrim¹ who can’t teleport) and give you an optimized route.

Connections between places are parsed from a simple text file with tab-separated values. A connection definition is simply the origin, the destination, the mode of travel, and how long the journey takes in in-game hours:

Origin       Destination     Mode            Time
Seyda Neen   Balmora         Silt Strider    3
Vivec        Hla Oad         Boat            5
Balmora      Seyda Neen      Silt Strider    3
Balmora      Vivec           Guild Guide     0

Since a very small number of routes are one-way only², I decided to keep things simple and require every route to be specified explicitly. As you can see above, the route between Seyda Neen and Balmora is specified twice, once for each direction.

To collect these routes, I used the indispensable Unofficial Elder Scrolls Pages and my own copy of the game running on OpenMW. I made each catalogued journey myself at least once, just to be sure.

ywalk ships with definitions for the entire fast-travel network for the Game of the Year version of Morrowind (meaning the Master Index plugin is enabled by default). For Tamriel Rebuilt it includes definitions that are active with TR_Travels. For now, only places with fast-travel options are considered. An exception to this rule are available player homes in Vvardenfell, for use with the Recall option. If you are curious, check out goty.tsv and tr-travels.tsv.

Installation

ywalk is written in Python and is supposed to be installed per user. The data files and manual need to be installed separately because Python packaging is a nightmare. For a full install as a user, get the sources from the git repository and run the following commands:

$ python setup.py install --user
$ make install

This will install ywalk to ~/.local/bin, the data files to their canonical path ~/.local/share/ywalk, and the manual to ~/.local/share/man/.

Usage

ywalk offers a simple command-line interface. Invoke it with the list of places you want to travel through or to, and it will print a route if it can. By default it allows all modes of travel, but you can allow only specific modes with -m, or restrict them with -M. For detailed usage information, see the manual.

Let’s see it in action! Consider a regular character that has no problem with land-based transport and can use the Mages Guild relays, but has no way of invoking Almsivi or Divine Intervention and never even heard of a Propylon chamber. In that case, we’d head over to Khuul and then start our journey:

$ ywalk -M almsivi,divine,propylon Khuul 'Tel Branora'
Start in Khuul
 then take the Silt Strider to Ald'ruhn (5 hours)
 then take the Guild Guide to Vivec
 then take the Boat to Tel Branora (5 hours)
Arrive in Tel Branora after 10 hours.

Now for the stuck-up Telvanni that raided every single Dunmer stronghold and completed their Propylon Index collection. We start in Falasmaryon in that case and avoid Mages Guild relays like the Corprus disease:

$ ywalk -M guide Falasmaryon 'Tel Branora'
Start in Falasmaryon
 then travel by Propylon to Caldera
 then travel by Propylon to Telasero
 then invoke Almsivi Intervention to Molag Mar
 then take the Boat to Tel Branora (2 hours)
Arrive in Tel Branora after 2 hours.

And finally for our sailor, again from Khuul:

$ ywalk -m boat Khuul 'Tel Branora'
Start in Khuul
 then take the Boat to Gnaar Mok (7 hours)
 then take the Boat to Hla Oad (4 hours)
 then take the Boat to Vivec (5 hours)
 then take the Boat to Tel Branora (5 hours)
Arrive in Tel Branora after 21 hours.

Let’s say our character absolutely hates the swamp. We can make sure to avoid Gnaar Mok with -P. This will lead to a journey around the eastern parts of Vvardenfell:

$ ywalk -m boat -P 'Gnaar Mok' Khuul 'Tel Branora'
Start in Khuul
 then take the Boat to Dagon Fel (8 hours)
 then take the Boat to Sadrith Mora (10 hours)
 then take the Boat to Tel Branora (8 hours)
Arrive in Tel Branora after 26 hours.

By default, ywalk optimizes for least travel time. It recommends using teleportation over regular Silt Strider or boat services even though using the latter would usually decrease the number of hops needed. If you’re interested instead in a route with the least number of hops, you can change the weighting method for the path-finding algorithm with -w.

I hope you’ll have fun trying this out. Feel free to send any improvements along!

After more than a year of hibernation, the last two weeks have seen a greatly increased amount of work dedicated to weltschmerz. The initial impetus to pick up on development came after a whole bunch of contributions and bug reports from a new user, nortti. Thanks a lot for those and for jump-starting further work on the project!

Read on to take a look at noteworthy changes and all the new features, or head on over to the project page to get 1.4.0 right away.

Controlling cursor blinking

The first feature nortti proposed and implemented is the new cursor_blink setting. Modifying cursor blink behaviour was not possible before; weltschmerz simply relied on GTK’s default setting of SYSTEM. This falls back to whatever is set for gtk-cursor-blink which in almost all cases¹ will be TRUE.

Now users may enable or disable cursor blinking within weltschmerz. The default value for cursor_blink is SYSTEM which means that there is nothing to do if the current behaviour already works for you.

Open terminal

The second contribution they made is the incredibly handy Open terminal feature. Similar to Open directory, this feature leverages OSC 7 support² to open a new instance of weltschmerz in the current directory. This is bound to Ctrl+Shift+T for quick and easy access.

URL copying

Up until now, weltschmerz only populated the CLIPBOARD selection when copying URLs to the clipboard via the Copy URL context menu entry. Since all other copy operations set the PRIMARY selection as well, 1.4.0 changes this. Now, Copy URL populates both CLIPBOARD and PRIMARY, making weltschmerz behave like other GTK and QT apps³.

A handful of bugfixes

weltschmerz now has a minimum size of 28 × 3 cells, reports its window geometry correctly at all times, and always draws the scrollbar if the user or distribution turns overlay scrolling off. The latter may seem inconsequential, but the journey to the fix was a very long and arduous one.

I’ve written about these changes extensively in the relevant commit messages here, here, and here. Definitely check those out if you are a fan of weird issues and possibly even weirder workarounds.

Internationalization

Finally, I’m glad to announce that weltschmerz is now translatable! The 1.4.0 release comes with a German and a Finnish translation of the program, excluding the manual (a bigger effort, and I did not want to drag 1.4.0 out even further⁴).

This introduces gettext as new dependency. In almost all cases it should already be installed since it is the de-facto standard for translations in GNOME and GNU-adjacent projects.

If your language is missing and you want to contribute, have a look at the TRANSLATE file in the project repository.

Closing & Thanks

That’s it for this release. Thanks a lot again to nortti for all their contributions and for providing valuable feedback throughout the entire 1.4.0 development process!

See NEWS for the full set of changes, and 1.3.0..1.4.0 for all relevant commits.

Writing things is hard. So hard, in fact, that the dearth of posts here is not for lack of ideas or things to talk about, but instead for limits on how I want to spend my time. There are plenty of things I’d love to write longer posts about, but doing that takes at least three to four days if not an entire week. True, this is partly down to obsessing over documenting everything and my need to get every detail right, but in a sense I also cherish that part of me, so I don’t want to outright suppress it.

Clearly not everything needs that kind of treatment, however. Some things can be said with brevity and perhaps do not deserve an in-depth look at that particular moment. But since I’ve long taken this site as a space to write longer-form and truly developed articles, breaking with that notion here seems unwise and inconsistent - this place is just not built for short posts. Still, I have long felt the need for a platform that is meant for that kind of content.

Platforms aplenty, all broken

Modern microblog platforms like Twitter seem to mostly take care of that need for other people. I’ve tried a few times now to keep a Twitter presence going, but never really felt a deep connection to it. Attention-grabbing design choices always put me off of it after a few months. It wasn’t really a space I felt comfortable in, I felt like I had to market myself to others.

Mastodon is the same by virtue of being designed like Twitter, a decision I understand on a technical level¹ but one that I deeply dislike on an ethical one. I do not think that Twitter’s problems² will be solved by federation alone. There will need to be changes to the core experience and a rethink on how social networks affect people. Neither is a space for me.

A humming microblog

Instead, I decided to build my own. A place for all the smaller things that I would still like to share with the world. A place that I have full control over and can cultivate by myself.

Check zunzuncito out over here. It’s named³ after the Bee hummingbird, the world’s smallest bird.

zunzuncito runs on Zola, a static site engine. Initially I wanted to use the tried and true combo of lowdown and sblg, but there were some annoying limitations like the lack of easy pagination. Make no mistake, however, using Zola still results in a number of limitations that make this a bespoke solution at best.

I expect to be iterating on this design as I use it. If you want to follow along, check out the git repository.

A seemingly overlooked¹ feature of cgit is its ability to host detached signatures of the snapshots it generates. Add a signature of a snapshot to the Git repository, and cgit will automatically offer it right next to the corresponding snapshot:

But how does cgit know which signature corresponds to which snapshot, and how are signatures stored in the Git repository itself? Enter git-notes(1), another feature that is probably overlooked. Intended to facilitate adding additional notes to commit messages without changing the commit itself, git-notes(1) lends itself well to attaching textual data to any Git object such as a commit or a tag.

Duly noted

Internally, Git stores the contents of a note as a blob, meaning it is saved to the object database and referred to by its hash. But Git must also store which commit a note belongs to. For this it uses a tree. A tree is Git’s way of encoding a directory: it contains a list of paths, and maps them to blobs (files) or other trees (subdirectories). We can look at those trees using git-cat-file(1). For example, the following is the tree for this commit:

$ git cat-file -p 6a81213f2e88a33835f2fb94015bda5dc04a397c
100644 blob 3feb78adc667d7bf4ad2cec4fb780b29ced25302    .gitignore
100644 blob 2149bd82c51e65c34d8aee87f96c4f1c1af8f6c1    LICENSE
100644 blob d397eaf5a75d0d30c4d9d2ffcd1007b44acc842a    quarg.1
040000 tree eee3c892c769bad3b7d883f0a162500406f67c3b    quarg
100644 blob 1a861ec51a39cbefa0f5027995c358af2224ebbb    setup.py

The tree object that links notes, however, uses the commit blob itself as a “path”. In the following tree (for this commit) the note blob is on the left side whilst the commit blob (“path”) is on the right:

$ git cat-file -p 3a5fd837cae7e478b9a230f6c301c93efda7c1e2
100644 blob 5c7ec832f83342aa460bb27b0b75e12695a98a53    43c9fb13e063cebfd08e741b67b9ec2317aed4b9

Let’s see which commit that is:

$ git show -s --pretty=oneline 43c9fb13e063cebfd08e741b67b9ec2317aed4b9
43c9fb13e063cebfd08e741b67b9ec2317aed4b9 (tag: 0.1.2) Prepare for release of 0.1.2

The note tree is then linked in a normal commit object that a special ref points to. By default, that is refs/notes/commits. One may think of that ref as pointing to a special branch holding all the information on notes “published” to that branch.

Instead of that default location, cgit looks in refs/notes/signatures/<format> for any signatures. For example, signatures for a gzip-compressed tarball are stored in refs/notes/signatures/tar.gz. If cgit finds a signature attached to a tag and can generate a matching tarball, it will automatically link the contents of the note blob as a .asc² file.

Snap, shot!

With the Git internals out of the way, let’s break down the process of hosting a signature on cgit.

Before we get to the actual signing process, a quick but important detour. Since we will be publishing signatures of the snapshot itself, we have to make sure that its contents are stable. Furthermore, we have to be absolutely certain that cgit is generating the same snapshot that we used when we made the signature.

We could of course tag a release, download the snapshot via cgit ourselves, verify that it contains the correct files, and then sign it, but that seems backwards; we just blindly trusted the cgit machinery to give us what we expect. What if our cgit host had been compromised? We should make sure that we can create the same snapshot locally.

Thankfully, this is a trivial thing to do. We can use git-archive(1) to create a stable archive³ from any tag. This is, in fact, also what cgit does internally. By default, git-archive(1) does not prefix the files in the archive with the project title and tag, so to make sure that we get a sane⁴ tarball, we have to pass the right prefix – just as cgit does:

$ git archive --prefix=quarg-0.1.2/ -o quarg-0.1.2.tar.gz -- 0.1.2

The resulting file should be exactly what you get when you download a snapshot for the same version from cgit.

Signed, Sealed, Delivered

Now that we have the actual snapshot, we can get to signing it.

The example in cgitrc(5) uses the dreaded gpg(1) interface to generate a signature, but since notes are just textual objects, we can use any utility that generates a signature in text form. I will be using OpenBSD’s signify, a tool I have been recommending for a long time given its simplicity and ease of use⁵.

To make things more straightforward and give people who do not want to use signify a way of verifying the integrity of the download, we do not sign the snapshot itself, but its checksum. Conveniently, signify supports verifying the signature and checksum in one invocation⁶.

Since signify expects BSD-style checksums from OpenBSD’s sha256(1), we have to make sure to pass the --tag option to its GNU counterpart, sha256sum(1):

$ sha256sum --tag quarg-0.1.2.tar.gz > quarg-0.1.2.tar.gz.SHA256

Finally, the following invocation of signify cryptographically signs the checksum file using our secret key and writes the signature to quarg-0.1.2.tar.gz.SHA256.sig:

$ signify -Ses release.sec -m quarg-0.1.2.tar.gz.SHA256

Final assembly

Now all that is left is to store the signature in Git’s object database using git-hash-object(1) and tell git-notes(1) to link that blob to the 0.1.2 release tag:

$ git notes --ref=signatures/tar.gz add -C "$(git hash-object -w quarg-0.1.2.tar.gz.SHA256.sig)" 0.1.2

Let’s take a look at the signature we just stored:

$ git notes --ref=signatures/tar.gz show 0.1.2
untrusted comment: verify with release.pub
RWRyR8jRAxhmZ8C5e7Vxkaed4Tg5Po+Qg4J+0LvjfRRfzch1MqUL8nzkrtGEB8fLG1+DwRYkzYdcZ7qjcYSPx048lTSVpqjSAAc=
SHA256 (quarg-0.1.2.tar.gz) = 1b6610c2417f36b5b1df5208c3c641b8b2ac3283dae87f453801cdc8c4ffb80a

Looks good. Let’s verify it before publishing:

$ git notes --ref=signatures/tar.gz show 0.1.2 | signify -Cp release.pub -x -
Signature Verified
quarg-0.1.2.tar.gz: OK

Great, this is ready to be published. Git will not include refs/notes/* by default when pushing, so to update the upstream repository with the new signatures, we have to push the ref manually:

$ git push origin refs/notes/signatures/tar.gz

Similarly, a regular clone of the repository will not download any note objects by default. If you want to have a look at the signatures for weltschmerz or quarg, for example, you have to fetch them manually like so:

$ git fetch origin refs/notes/signatures/tar.gz:refs/notes/signatures/tar.gz

Git also supports showing notes in git-log(1) directly, by use of the --notes option. The following will display any signatures for the tar.gz format inline after the commit message⁷:

$ git log --notes=signatures/tar.gz

When in doubt, automate

Of course doing all of this every time one wants to carve a new release is a bit tedious, so I ended up writing a small helper script. For now it hardcodes the invocation of signify, but it should be easily extensible to accommodate other tools.

Synopsis

quarg is a command-line search tool for Quassel. It supports connecting to both SQLite and PostgreSQL databases and has a wide range of search options. Mostly born of frustration with Quassel’s built-in search, quarg aims to be a simple and easily extensible search platform.

quarg is written in Python, enabling it to work on a variety of operating systems. It has successfully been tested on Linux as well as Windows machines.

Download

• quarg-1.1.0.tar.gz (signature, verify?, archive)
• Git repository

Requirements

• Python >= 3.8 (with support for SQLite if using the SQLite backend)
• dateutil >= 2.8.2
• SQLAlchemy >= 2.0
• psycopg (recommended if using the PostgreSQL backend)

Usage & Configuration

See quarg(1).

Installation

First, create a virtual environment and activate it.

python -m venv venv
source venv/bin/activate

Now you can install the downloaded tarball with pip:

python -m pip install quarg-1.1.0.tar.gz

Remember to make sure you install psycopg if you intend to use the PostgreSQL backend:

python -m pip install psycopg

quarg should now be available in your shell:

quarg -h

If you happen to use Gentoo, quarg is available in the GURU overlay.

Contributing

I plan to set up a more public venue for proposing changes and reporting issues with my software. For now, see the front page for contact info. Feel free to send patches with git-send-email(1) - see here and here for an intro.

It has now been approximately one year since the initial publication of this site and its new design. Looking through the commits that changed the CSS I can’t see any big changes; overall the core design remained very stable. That is (or, rather, was) especially true for the design of the landing page. Why was? Well, as you might have noticed, it now has a whole new look.

Gone is the previous brutalist, blocky, beautifully Oriole-yellow page, replaced by a simple minimalist top-to-bottom list of articles. I even decided to throw in a quick introduction as well. Whilst I still love the old design very dearly (it was based on countless design iterations, ideas, and experiments spanning about 6 months in total), it always clashed with all other content on this site. That was, of course, in a way intentional - the idea was to be as uncompromising as possible. For the time, it was the right thing to do. I was going through an extreme amount of turmoil (both externally and internally), and finally had something completely for myself with that design. It became a sort of safe haven, a space where I did not have to care much about the needs of others; a space in which I expressed myself without worry.

Over the last 5 months I have had lots of time to think and reflect, and learned a lot about myself. The current design therefore reflects a new-found confidence, and is more an example of easiness than of uncompromising and extremely idiosyncratic design. Maybe some time in the future I’ll be lucky enough to re-use parts of the old art style and keep it around for something that is more in tune with its complicated and personal history.

git-http-backend(1)

As mentioned in the previous post, an outstanding item for git.oriole.systems was support for the “smart”¹ HTTP protocol as supplied by git-http-backend(1). This is now implemented via a small patch for cgit: Whenever cgit is asked to handle a “cloneable” item, instead of caching and serving it itself, it executes git-http-backend(1) and lets that handle the rest. The advantage of this approach is that there’s no additional configuration needed on the side of the web server, barring the addition of the environment variables GIT_PROJECT_ROOT and GIT_HTTP_EXPORT_ALL required for git-http-backend(1) itself.

To my knowledge, it is not easily possible with Caddy 1 to set up the complex² structure needed to run cgit and git-http-backend(1) at the same URL. Caddy 2 brings much improved path matching support, so I may change this again once I have migrated everything. For now, this simple setup suffices.

Testing The Waters

I’ve also been working on getting things ready for the inevitable migration to Caddy 2. There’s still much to be done, and I don’t think I’ll be ready for at least another month. Firstly I want to give Caddy 2 some more time before I use it as a stable service (2.1 is already in beta and contains a lot of fixes). Secondly I have to make sure that every single part of my infrastructure will continue to work with Caddy 2, and that means a lot of testing.

Since I had been working on setting up cgit anyway, I decided to draft a new Caddyfile that is compatible with Caddy 2. For the most part, it went surprisingly well. I generally prefer the new syntax, and pretty much all new features are integrated very cleanly. The documentation could be improved in a few places, however. Most of the time there is a clear lack of cross-references, and if you don’t know how a certain part of the configuration is called, it is very hard to search for it.

There was one minor hitch to this effort. It seemed that no matter what I did, I couldn’t get the fastcgi transport to work with slowcgi: the PATH_INFO variable would just remain empty. After a few hours of testing and digging, I could finally identify the root cause. Turns out there was an ever-so-subtle bug in Caddy’s handling of the split directive. I reported the issue upstream and sent along a small pull request that was promptly merged.

Dark mode and prefers-color-scheme

Finally, just yesterday I updated the whole site to respect the prefers-color-scheme CSS media feature. Whoever prefers dark websites and has told their operating system or browser³ to use dark mode when available will hopefully rejoice in not having their eyes burnt out when visiting my site. This is arguably a small change, and inconsequential in the grand scheme of things, but it was lots of fun to work on after the rather more stressful crunch of getting cgit to work nicely.

I’m still playing around with the overall colour choice and composition, so you may see more or less significant changes down the road. The main focus will still be the default light design (as that is the one I prefer), but dark mode will not just be an afterthought. Feedback on this is very much welcome.

And by the way, if you are interested in how this site is put together, check out its Git repository.

As more and more FOSS projects leave the confines of dusty arcane mailing lists or thrice-cursed Bugzilla instances for the seemingly green pastures of the likes of GitHub or GitLab, there has been an ever greater need as a proactive user to engage and deal with these platforms. And, to be perfectly frank, the general experience sucks!

Their search interfaces especially leave a lot of things to be desired. Usually I end up capitulating after a minute, clone the whole repository instead, and fire up rg(1). Why struggle to perform a task in your browser if you have tools that have been perfected for it right in your terminal?

Another aspect GitHub has been working on is its review interface. From my personal experience, patch reviews have been perfected on mailing lists like git@vger.kernel.org, where people discuss proposed patches by replying to them with in-line comments. After this review phase, an improved version of the patch is sent in, and another review phase begins, until there are no more points to discuss, and the patch is either accepted or deferred.

It took GitHub a very long time to achieve relative feature-parity with patch reviews by mail. Now, the review interface exists and it works, but it is very crowded and needlessly convoluted. Finding old versions of a specific pull-request could be a lot nicer, as could be comparing subsequent versions to the original. Just about the best feature of having all this readily available in your browser is the ability to easily reference other bug reports, leading to improved inter-project communication. Of course a good mail archive frontend would solve this problem for mailing lists too.

Regarding repository landing pages, I feel that a Git web interface should show the state of the Git repository, not introduce me to a project. Chances are I’ve discovered a project’s repository through its website or project page, which hopefully already achieved the introductory part. Once I’ve found the repository, I’m ready to look at the code or browse a few commits; I don’t want to waste time reading a (possibly slightly different) project outline.

I want a system that augments my already existing CLI workflow in a practical way - something that enhances the experience in certain ways, and doesn’t completely recontextualize it. Which brings me to the present state… and a question.

The status quo

I have been hosting my Git repositories on my dedicated server for more than half a decade now, using a very simple (but effective) system:

1. Initialize a bare Git repository in a well-known directory
2. Tweak directory permissions (0700 if it’s private)
3. Enable the default post-update hook that runs git-update-server-info(1)
4. Push my work to the server via ssh(1)

Together with any old web server that can serve static files and a few symbolic links in the right places, this setup enables most (if not all) of what I need from a Git hosting platform. I can push and pull my work using ssh(1), and the few public repositories I have are accessible via pull-only HTTPS using Git’s “dumb protocol”.

I can even collaborate directly with other users on my server by allowing specific people write access to the bare repositories. No git user or group needed - just good old POSIX Access Control Lists. And for people without a shell account on my server (the vast majority as it turns out) there still was the possibility of using git-send-email(1) to contribute, of course¹.

No web interface?

Over the last decade or so one thing has become very apparent: fully-featured and well-integrated collaborative platforms for development are there to stay, and users’ expectations have risen with them. Given these expectations, I’ve been asked more than a couple of times recently why I do not have a Git web interface for my projects. The answer’s always been the same, “why browse a repository with anything other than CLI tooling?”, but the question stuck with me…

It was trivial to find out why I didn’t set up a web interface initially, back when I set up the system I described above: I simply did not need one. This was a deliberate decision as I had recently migrated away from GitHub, which, back then, already contained most of the interactive web components it has now. My projects did not see a great deal of external activity, there were next to no bug reports, and most of the projects were too small to warrant integration into GitHub’s whole feature set. They were frequently starred², but it did not seem that activity would pick up any time soon.

A web interface therefore was not even part of the equation.

Yes web interface!

These days, the question is harder to answer as I admittedly very much recognize the ease of use and comfort of using a web interface to give a project only a cursory glance, link a patch on IRC, or do a quick and dirty blame on some broken code. As repository size decreases, explorability on decent web interfaces increases, and, for the smallest projects, a good web frontend can arguably fully replace git-clone(1).

So, do I need a web interface? No, not really. Do I want one? I think so. Given a decent enough candidate, I am confident that it will provide features other people find useful. Perhaps it will also boost visibility of what I am working on, and give me a nice stage on which to present projects still lacking their own post on this site. Plus, it is something to keep me occupied for a few days as I go about setting it up.

About I month back I set out to compile a full list of requirements:

• Self-hosted, without depending on popular containerized deployments
• A minimal and well-designed user interface
• No misguided social networking features (GitHub stars, I am looking at you)
• Active development, good documentation
• Easy integration with my preferred web server, Caddy
• Light on dependencies: no Ruby, no Perl, no PHP
• Not strictly necessary, but a bonus: no JavaScript

Searching for candidates

The search was on. I quickly found a very helpful list and started digging through it…

klaus

First up, klaus. The demo looks promising enough, except for the fact that one of the badges gets blocked by the X-Frame-Options policy, but that is not relevant to the project itself. It is built with Python, making hosting relatively easy with my server setup, and also does not contain any features beyond simple repository browsing.

My issues come with the overall design. I just… don’t like the way it looks. Lots of the core elements are very blocky, positioned too close together, and not contrasted enough. The diffs themselves look good, but the commit messages suffer from the same blocky and grey fate, drowning in the big wall of text below.

The design of the summary page feels strange to me as well, with most of the page taken over by the rendered README file and no quick way to see the last few commits other than scrolling all the way down. All of this would need a great deal of work to fix, more than I am willing to commit to right now.

sorcia

sorcia is a relatively new frontend written in Go. It’s still in alpha, and the “federation” part seems to be missing entirely, but is very pleasing to look at and use already. The homepage has the following to say:

Initially I’ve started building this project for myself as I’ve grown kinda frustrated with the noisy interface that I’ve been noticing on Github or other similar softwares. I started my career as a UI designer and then moved on to web programming, so I thought I could build and design something that would only have the necessary features which I need in order to host and develop my projects.

Sounds like what I am looking for. Sadly, a cursory look at the installation guide reveals a bit of a snag. For now, sorcia seems to use its own SSH server, and cannot be integrated to use an already running one. Bummer.

Additionally, without JavaScript, some things are not as nice yet as they could be. Picking this as a long-time solution right now is definitely a no-go. Maybe very well worth a look in year or so - if the project is still around by then. That said, I definitely appreciate the effort to create a nice user experience.

Addendum (2021-02-01): Indeed sorcia seems to be dead.

Gogs & Gitea

Now on to the big ones, the behemoths of self-hosted Git services: Gogs, and its more or less recent fork Gitea. I’ll focus on the latter only, seeing as the user experience is largely the same.

Gitea fulfills most of the requirements, with one huge caveat: The interface and features set is meant to match GitHub’s or GitLab’s. I will not only get a Git browser, but also an issue tracker, support for pull requests, a full-fledged wiki system, an activity tab, and the ability to watch repositories, star, and fork them.

Gitea’s not meant to have one instance per user, it’s meant to have one instance per company or community. And that community better be big! This puts me in a weird position where I am forced to go all in, but get nothing in return: If I were to consider enabling the issue tracker properly, I would also have to open up registrations; that means enabling authentication, allowing outbound mail, and fighting spam. All for the end result of people not wanting to register with yet another random instance on the internet.

On the other hand, if I disable³ all the features I do not need, the 10% that remains of the whole of Gitea is not even that great. Barely worth putting in the effort of going through its one thousand line sample configuration file.

cgit

cgit is probably one of the oldest web frontends for Git, next to gitweb (which comes bundled with Git itself.) As such, it is one of the most mature interfaces out there. Written entirely in C, the list of dependencies is expectedly short: cgit pulls in a tagged release of Git in the build stage, but other than that only depends⁴ on zlib.

cgit is a Git web browser only, but has a bit of a different approach compared to klaus and sorcia. While the latter two put more emphasis on project presentation and present a fully-rendered README file first and foremost, cgit focuses more on giving the user a summarized view of their repository - showing a selection of the latest active branches, tags, and commits.

In that regard, cgit might scare off users who are unfamiliar with git internals, but for me this is a welcome change. I can quickly scan through the summary view and find out what has been worked on recently, all without having to click through to another page. Of course cgit also supports markdown or manpage rendering, but it’s only a secondary concern.

All in all, I liked cgit the most and set out to deploy it. But things are never this easy…

Not-so Common Gateway Interface

There is an item on my list of requirements that calls for easy integration with Caddy, a web server I’ve been using for a couple of years now. Nowadays, most web applications actually run an HTTP server themselves and can easily be set up with Caddy acting as a reverse proxy. cgit, however, as the subtle name might reveal, runs via CGI, an ancient interface that relies on the web server executing the application for every incoming request.

This is a problem because Caddy does not natively support CGI. While there exists an abandoned plugin for Caddy 1, the recently released Caddy 2.0 does not share the same plugin interface and lacks CGI support completely. I deem it unlikely that it will ever get it.

Thankfully, both versions support FastCGI, an attempt to overcome the overhead of launching a process for every single request (most CGI applications are actually scripts run by interpreters, so this overhead can become quite noticable.) But how does one plug a CGI application into a FastCGI interface?

The answer is to use a FastCGI wrapper, a long-running process that acts as a bridge between the web server and the CGI application. Problem is that there are not many good ones around that are still maintained. All I could find after a few hours of search was a cursed Perl script, and an implementation in C that was more than 8 years old. Yikes.

slowcgi(8) to the rescue

A look on the OpenBSD side of things, though, revealed something very promising: slowcgi(8). The OpenBSD project is never really vocal about any of its programs, so this slipped through the cracks easily - even though it’s been a part of the operating system since version 5.4, released seven years ago.

slowcgi clocks in at around 1300 lines of C, is actively maintained, simple, secure by default⁵, and seemed very easy to port to Linux. In fact, it’s been ported already by someone else, but that version hasn’t seen any updates in about a year now - so I decided to roll my own thing (and will keep maintaining it for the time being). Instead of pulling in libbsd, I decided to just copy in the required parts of the OpenBSD source. In the future I might migrate over to using Kristap’s excellent oconfigure.

Once ported, slowcgi works right out of the box. By default it uses a chroot to keep CGI applications jailed under a specific root directory, and runs as a separate www user. A chroot for cgit is technically not needed, but comes highly recommended. Even if it means having to set up the entire chroot tree with cgit’s runtime dependencies, defense in depth is important and makes the setup more secure and safe in the long run.

Putting everything together

With slowcgi up and running, there’s only the matter of putting together all the pieces: Caddy needs to be set up to talk to the slowcgi instance controlling cgit, and the chroot needs to be set up properly. At this stage, considerations for backwards compatibility come into play also. Particularly, I did not want to have to move the already existing repositories to a new location. Everything that worked before should continue to work like before.

Since cgit will exist in a chroot, I cannot use symbolic links to any paths outside of it. Putting cgit into the same directory tree as the repositories seemed suboptimal also, as I want to keep the web interface and the actual Git data fully independent of each other for more flexibility in the future.

The general framework

I found my solution in a feature called “bind mounts”. People who have needed to chroot(1) into a Linux installation from a Live CD might be familiar with this - to give the installation access to devices mapped by the host running from the CD, the whole /dev directory is bound onto something like /mnt/dev. Thus, the same files are accessible through multiple distinct mount points, with one of those contained within the chroot.

This is the same concept I used in skein(7), a small framework facilitating a flexible and modular approach to multi-user cgit hosting. Given a simple directory structure, a helper script sets up all necessary devices⁶ and bind mounts for every user wanting to give the cgit CGI application access to their repositories. If there is a need to have multiple cgit hosts set up, this framework also allows fine-grained control over which repositories show up on which host. This way, users on my server who would like to opt in to having a cgit frontend can freely determine how it is set up.

The following is part of the skein(7) framework, showing my home directory in the cgit chroot. Symbolic links in each instance’s repos/ directory point to the actual Git repositories under the repos.avail bind mount.

wolf
├── instances
│   └── git.oriole.systems
│       ├── config
│       ├── repos
│       │   ├── slowcgi.git@ -> ../../../repos.avail/slowcgi.git
│       │   └── [...]
│       └── site
│           ├── cgit.css
│           ├── custom.css
│           ├── favicon.svg
│           ├── logo.svg
│           └── robots.txt
└── repos.avail

As for cgit’s runtime dependencies… I’ve decided to keep these to an absolute minimum and use only statically compiled binaries to reduce the amount of work needed to maintain the chroot setup. Whilst this means that cgit will not have access to a shell (or, for that matter, a Python interpreter), a very decent chunk of its filter capabilities can still be used in conjunction with the wonderful lowdown and mandoc projects and a tiny custom C program invoking them.

Finally, the directives needed for Caddy are as simple as:

git.oriole.systems {
    import shared
    root /srv/cgit/home/wolf/instances/git.oriole.systems/site/

    fastcgi / /run/slowcgi.cgit.sock {
        env SCRIPT_FILENAME /bin/cgit
        env CGIT_CONFIG /home/wolf/instances/git.oriole.systems/config

        except /cgit.css /custom.css /logo.svg /favicon.svg /robots.txt
    }
}

Configuring cgit

All that remains now is configuring cgit itself to work with this framework. There’s not much to be done in that regard, it simply needs to be pointed to my custom cgit-about-filter program, and the repository location within the chroot:

about-filter=/bin/cgit-about-filter
scan-path=/home/wolf/instances/git.oriole.systems/repos

For projects with a README file formatted in markdown, lowdown(1) will take care of HTML conversion. Manuals are formatted by mandoc(1). Given the lack of a Python interpreter there is no syntax highlighting, but I find excessive syntax highlighting unappealing anyway. A couple more changes to cgit’s default cgit.css… and we’re done!

git.oriole.systems

Finally, after about a week’s worth of research, experimentation, and setup work, my new Git web interface is finally online under git.oriole.systems! A great deal of care has gone into setting it up just right, and I dearly hope this will be useful for people, enjoyable to use, and interesting to just browse around in.

Future work

A few things remain to be done in the next few weeks and months. For one, I’ll have to look at changing my Caddyfile to be compatible with the recent release of Caddy 2, before I fully switch over to it. That means having to relearn most of what Caddy does, and may be a bit time-consuming. Of course I’ll also have to remain backwards compatible with all the things I have already set up.

There’s a few things to be done on the Git web interface front, too: Right now I still serve Git repositories using the “Dumb HTTP” protocol. Integration with Git’s own git-http-backend(1) would be a good addition. Furthermore, I have been planning for a very long time to set up a public inbox for issue tracking and bug reports. Once that is set up, I’ll have to link to the proper addresses from within each Git repository.

All this will be part of a future post. For now, enjoy.

Over the past few weeks I have been working on bringing a few new features to weltschmerz, my terminal emulator. One of them is the addition of a major VTE feature that I had overlooked when I first prototyped it: The support for OSC 8 hyperlinks.

The remaining two are smaller in nature, but hopefully just as useful: The context menu has learned a couple of new tricks, namely copying a selection as HTML, and the ability to open the current directory in the desktop environment’s default file manager.

Additionally, I have overhauled and improved the configuration management code to make future changes and additions easier. These improvements include a small bug fix, but are otherwise invisible to the end user.

Head on over to the project page to get the newest version right away, or read on to take a closer look at each new feature.

Hyperlink support

The motivation for this feature came when I read about the new -fanalyzer static analysis pass that will come with GCC 10. The post mentions that in sufficiently capable terminals, new CWE identifiers and the option names for warnings are clickable hyperlinks pointing people to the right place in the documentation.

Since the post mentioned gnome-terminal as one such capable emulator, I assumed that VTE had to have been updated with hyperlink support and went to find out when that happened. It turned out that it had been added way back when in 2017, I just never paid much attention to it.

Since VTE already had full support, I decided to add this feature to weltschmerz as well. Now, if enabled, hyperlinks are clickable; they open up in the application that GLib thinks is best for the given URI. To make the user aware of what they will open, the terminal now renders a tooltip with the URI when hovering over a hyperlink:

Given the relative infancy of this functionality, and a couple of security concerns, this feature is disabled by default. If you want to try it out, it can be enabled in weltschmerz’s config file like so:

[misc]
allow-hyperlinks = true

Copy as HTML

Whilst looking through VTE’s Vala documentation to find out more about hyperlinks, I stumbled across the definition for the Format enum which controls in what format the selection is copied to the clipboard. TEXT makes the clipboard contain the plain text copy of the selection, and HTML formats the selection as HTML, with mostly complete style and colour information, like this:

diff --git a/NEWS b/NEWS
index a9b1359..4e1c329 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,11 @@
 This file lists important changes to the weltschmerz terminal emulator.

+Changes in version 1.2.1, released on January 17, 2020:
+
+    --- MINOR BUGFIXES ---
+ * weltschmerz.1: The manual page now contains updated contact and author
+   information.
+
 Changes in version 1.2.0, released on December 30, 2019:

     --- MINOR NEW FEATURES ---

Adding support for this was straightforward. Copy as HTML is now available as a context menu entry whenever there is an active selection. The above is an excerpt of the output of git-diff(1) from one of the release commits. Except for the font (which depends on your browser), this is exactly how it looked in my terminal.

Open directory

For the longest time I primarily used ranger, a terminal file manager, to traverse directories and open files quickly. A few months back I decided to try out a few GUI-based ones and found that Thunar does the job very well. So well, in fact, that I rarely use ranger anymore these days. I find that for regular day-to-day browsing, I am much faster with the mouse and quick drag-and-drop actions are now essential to me.

I still spend most of my time in a terminal, however, and whilst it is very easy to open a terminal from within Thunar, it used to be not so easy to open an instance of Thunar (or whichever file manager you prefer) from within weltschmerz.

Now, with the new Open directory context menu entry (or by hitting Ctrl+Shift+O), weltschmerz opens the current directory in the desktop manager’s default file manager. Note that VTE relies on OSC 7 to determine which directory an application is in.

The shell I use, fish, emits the correct escape sequence automatically whenever it enters a new directory, but other shells will most likely not do this by default. In that case, the menu entry will be greyed out. However, for other shells, it should simply be sufficient to put the proper escape sequence into PS1 or something comparable to PROMPT_COMMAND in bash. Note that it has to contain a URI (and not a regular path).

Consider something like the following (though note that hostname and path should be URL-encoded):

printf '\e]7;file://%s%s\a' "$hostname" "$path"

Closing

That’s it for this release. I hope these new features will be useful (or at least interesting) to people. Until next time!

I have a pretty extensive music library which I manage with mpd(1) and ncmpcpp(1). Whilst I would love to find a standalone tag editor that is easily usable from the command line (or alternatively a nicely designed GUI one), ncmpcpp’s built-in tag editor has always been enough for my needs.

About two weeks ago I was in the process of adding a new album to my collection. This always includes a quick glance at the tags and some cleanup. This time, however, after I saved my changes, the following happened:

Every time I saved my changes, another duplicate entry would be added to each tag. I had not updated ncmpcpp(1) in a while and was initially confused as to why it failed suddenly. I left it, removed all tags using metaflac(1), and tagged the album manually. At the time I could not really be bothered to fix it, but I still wanted to investigate it at a later point, so I added an entry to my to-do list.

Diving in

Today I decided to look into this finally. First stop: the ncmpcpp(1) source code. I already knew that it used taglib to access and modify Vorbis comments, so I quickly found the part of the code that was responsible for saving changes:

void writeXiphComments(const MPD::MutableSong &s, TagLib::Ogg::XiphComment *tag)
{
    auto writeXiph = [&](const TagLib::String &type, const TagLib::StringList &list) {
        tag->removeField(type);
        for (auto it = list.begin(); it != list.end(); ++it)
            tag->addField(type, *it, false);
    };
    // remove field previously used as album artist
    tag->removeField("ALBUM ARTIST");
    // remove field TRACK, some taggers use it as TRACKNUMBER
    tag->removeField("TRACK");
    // remove field DISC, some taggers use it as DISCNUMBER
    tag->removeField("DISC");
    // remove field DESCRIPTION, it's displayed as COMMENT
    tag->removeField("DESCRIPTION");
    writeXiph("TITLE", tagList(s, &MPD::Song::getTitle));
    // [...]
}

Here, ncmpcpp(1) calls removeField(type) before adding a tag, which looked fine. Maybe the list contains more than one entry? Stepping through this code in gdb(1) revealed that addField was only called once per tag, meaning it was only added once. At this point I remembered that I was pretty sure ncmpcpp(1) had not been updated in a while, so I refocused on taglib instead: Maybe removeField stopped working for some reason.

Unorthodox packaging decisions

A quick query against the Gentoo package database revealed that I was using taglib-1.11.1_p20190920-r1 which looked very suspicious already. The latest stable version on the website is 1.11.1 from October 24, 2016.

nabokov ~$ eix taglib
[I] media-libs/taglib (1.11.1_p20190920-r1@11/01/20)

So what is going on here? taglib is still under active development, but there has not been a stable release for about four years. Gentoo instead decided to package the latest commit (at time of writing) as a “stable” version. For projects that have some kind of stability guarantee regarding their API, this is a very dangerous and strange choice on the part of the packagers; quite frankly, it is inviting random breakage.

Exploring taglib

Digging around in taglib’s github repo revealed that removeField had been marked deprecated internally in mid-2015 because of an apparent linking error when using String::null. Let’s have a look at the prototype of removeField from back then:

void removeField(const String &key, const String &value = String::null);

This method removes a tag entry of a specific type and optionally matches it against a given value. For example, removeField("TITLE") removes all TITLE tags, and removeField("TITLE", "Garbagemx36") only removes TITLE entries if they match “Garbagemx36”.

The issue mentions that changing the default parameter for value to an empty string would change the behaviour of the method. Suddenly, removeField("TITLE") would only remove TITLE entries if they matched the empty string - leaving everything else intact.

Sounds like we found our culprit. But didn’t the issue say that they would not make this change? What gives?

Enter GDB

At this point I started doubting the correctness of five year old issue comments, and decided to have a look at things myself. Thankfully, Gentoo makes it very easy to add debugging information to packages and have the source code installed alongside binaries and library files. A single addition to /etc/portage/package.env later and I was debugging removeField in gdb(1).

Stepping ahead to where the method checks whether value is null or not, I printed its contents:

(gdb) p value
$1 = (const TagLib::String &) @0x7fffffffc240: {
  _vptr.String = 0x7ffff5be83b8 <vtable for TagLib::String+16>, static null = {
    _vptr.String = 0x7ffff5be83b8 <vtable for TagLib::String+16>, 
    static null = <same as static member of an already seen type>, 
    static WCharByteOrder = TagLib::String::UTF16LE, d = 0x5555559a95c0}, 
  static WCharByteOrder = TagLib::String::UTF16LE, d = 0x555555b9f700}

Ah, like any good project, taglib is using a custom string type. Let’s convert it to a C string:

(gdb) print value.toCString(false)
$5 = 0x555555b9f740 ""

And there it was. taglib indeed was using an empty string (and not null) as the default for value in removeField.

Closing Blame

One question remained: Why was this changed after all? It seemed pretty clear back then that the developers did not want to break the API. Perhaps there was a different bug at work here?

As I had learnt earlier, the default value for a parameter is found in the header file, so I used git-blame(1) to find commits that introduced changes to the prototype. Surprisingly, what I found was a very recent change from September that added actual deprecation warnings… and quietly changed String::null to String(). I was not able to find a reason for this; to my knowledge, no commit or issue mentions this change.

So in the end, whilst wanting to keep up API promises, the behaviour of an already deprecated method was changed in what can only be called the “development branch” of the project, and it hit me because Gentoo decided that it was a good idea to use work-in-progress code as a stable candidate for a package.

Around the time I discovered this, someone else had already opened an issue on GitHub. I shared my findings and later opened a pull request. I am pondering bringing this to the package maintainer’s attention, but am not confident it will result in any positive change.

casually oversized radiator
annoying alkaline rug
produce only defiance

senior sycamore tree
bright ladybug sanctuary
simply nimble antennea

mystified prowling turtle
hypnotic eel footage
most spirited obedience

unlawful tuesday outfit
discard kitten quilt
illusive bobcat fabric

semisoft nectar hug
grumbly moonbeam radiance
frosty celestial dandelion

unwanted external gender
maximize underuse coerce
timid imperfect finale

efficient waking exorcism
cursive twilight venture
that unshaven hamster

education stream unguided
glacial student seminar
penalize math stuffing

dismiss raisin donut
gulp poking anchovy
that living parameter

It is hard to believe that it took me well over half a year to finally come to the point where I can publish this website on my new domain and leave the old one behind. There’s a few reasons it took this long, and for once, surprisingly, they are not at all software-related. It was a journey through uncertainty, insecurity, and compulsive hesitancy, which is why this post will mostly be a reflective one.

Legacy Woes

Last year in November I had a bunch of free time on my hands, and I very innocently decided to work on a new site design. Back then I only really wanted to change a few things, since a full makeover seemed a bit too daunting. Still, after throwing around a bunch of ideas in my head, it seemed more clear that I would have to abandon the bulk of what I already had. Mainly this was because the old site was built on a considerable amount of legacy code: I was using AsciiDoc, which I had fallen out of favour with, and most of the site was being held together by an unwieldy Makefile and a couple of hacky shell scripts.

So whilst it was easy enough to add new content, changing the design or even merely attempting to tweak core concepts was impossible without a bigger rewrite.

Another concern was my growing disdain for a few of the things that I had published. Ideally I thought it’d be best to rewrite the bits that I didn’t like and keep the rest, but I couldn’t find a sufficient amount of motivation. I ended up neglecting to write any new posts on the site, and knowing I had stuff online that I kind of despised made me feel depressed every time I thought about it. I felt that the site could no longer reasonably present the kind of person I was. I felt that I was lying.

Honest Design

Around the same time I stumbled upon Brutalist Websites (since defunct, and only reasonably browsable by removing the prominent overlay), which curated a collection of brutalist websites.

There was always a certain - perhaps morbid - fascination I had with Brutalism and its idea of béton brut, raw concrete. The German word for this concept, Sichtbeton, takes a more experiential approach; it is simply concrete that is unobstructedly visible. There’s no attempt to hide the underpinning, instead it is displayed with a certain kind of pride. Core to the whole concept is a notion of honesty, of being utterly clear about what a thing is made of.

So when I felt that I was lying about what kind of person I was, it seemed only fitting to create something new in that sort of style, and to take to heart the idea of being more honest to the outside world and myself.

The Foundation

Not only did that mean creating a new design, it also meant starting from scratch and looking for a new engine to build the whole website. I quickly decided to use sblg to generate HTML files from templates, and lowdown to convert markdown files to XML content that sblg understands.

The whole project would live in only a couple of directories, tied together with a much simpler and cleaner Makefile this time. Compared to AsciiDoc, site generation was blazingly fast and very robust. It only took me about a day or two to fully tweak everything the way I wanted it to behave.

Small Steps

What ended up taking 90% of the rest of the time was the design. With the idea of being fully honest came a problem: I started questioning certain decisions because of what they might reveal about myself, what they might look like from an outside perspective. I noticed that, for a very long time, I had been genuinely insecure about releasing anything that was in any way personal to me.

For instance, the idea very early on was to have one single page containing everything I published; be it a piece of software, a poem, or some sort of essay. This resulted in a lot of internal conflict as I often considered my poetry to be “pretentious” and inherently less impactful than a software project. Suddenly I was wanting to have two sites, one for the “real” and technical projects, and one for the more personal. In turn that would mean that I was actively censoring my output by categorizing it away to a more obscure part of the site.

Another problem was an almost compulsive need to tweak the most insignificant parts of the design towards a sense of perfection and coherence that was frankly unattainable. Because of a lot of internal turmoil, it became impossible to do any further work I would feel positive of.

In the end the solution was to take considerable time off personal projects and reflect on and try to dismantle those problems and insecurities. I learned that it is very helpful to talk to trustworthy friends about this, and to find a comfortable space in which to experiment with being more immediately public with projects, ideas, or thoughts - even if you think they are unrefined and not ready. This is especially helpful if one tends to feel vulnerable after having published or when considering to publish. Initially it is perfectly fine to create a “mock public” space that no one can see, but which can be made more public as time goes on (a locked Twitter or Fediverse profile, for example). The idea is to build confidence in the act of publishing itself, and to take away the vulnerability and fear.

Horizon

Building this sort of confidence in publishing personal content is time-consuming and not always easy. You may feel the intense urge to undo a publication or to re-read it until it sounds drab and uninspired. In those cases, maybe ask a friend for feedback, but most importantly: take a step back and take some time off. It may read wholly differently tomorrow.

As for technical work, if you, like me, feel sometimes that what you do is unimportant, unrecognized, or invisible, it might help to start a document in which you collect even the smallest things that have some sort of impact day to day. Julia Evan’s idea of a brag document is a helpful resource. I tend to be overly humble myself and want to highlight the following excerpt, which helped me understand something no one had explained to me before:

One thing I want to emphasize, for people who don’t like to brag, is – you don’t have to try to make your work sound better than it is. Just make it sound exactly as good as it is!

Like béton brut, be uncompromisingly honest about your work. Don’t make it sound better than it is, but most importantly, learn that it has value and that there is no shame in showing it.

Synopsis

weltschmerz is a small and simple terminal emulator built upon the Virtual Terminal Emulator widget. It’s written in Vala, supports clickable URLs and hyperlinks, can reload its configuration whilst running, and has basic search functionality.

As a VTE app, weltschmerz supports practically every contemporary terminal emulator feature. It is built to be a stable and practical terminal emulator for daily use.

Download

• weltschmerz-1.9.0.tar.gz (signature, verify?, archive, changelog)
• Git repository

Packages

• Gentoo Linux (through GURU)

Requirements

• VTE >= 2.91 (must be built with support for Vala)
• Vala >= 0.42
• GTK+ >= 3.24
• gettext

Usage & Configuration

See weltschmerz(1).

Build

weltschmerz can be built with any POSIX-conformant make or with Meson. The latter may be interesting to distribution packagers or people already comfortable with this particular build system.

Note: if your Vala compiler executable is not named valac, you need to export the environment variable VALAC containing the correct name before you can build weltschmerz:

export VALAC='valac-0.42'

Makefile

Run the following to build and install weltschmerz to the default location (/usr/local):

make install

The Makefile honors the environment variables PREFIX, DESTDIR, BINDIR, and MANDIR. For instance, if you want to install weltschmerz to a local directory, call make like so:

PREFIX=~/software/weltschmerz make install

Meson

Create the build directory and configure the Meson build like so:

meson setup build

The build can be configured extensively; for more information, see meson(1). If you want to install weltschmerz locally for use with GNU Stow, for example, pass --prefix=~/.local/stow/weltschmerz.

Once the build is set up, install weltschmerz:

meson install -C build

I use the signify tool to cryptographically sign all software downloads you will find on this site and on git.oriole.systems.

Whilst you technically don’t need signify to verify the integrity of downloaded files, I strongly recommend using it to also verify the signature. A portable version of the tool is available here.

Using my personal overlay

If you happen to use Gentoo, feel free to use my personal overlay. You only need to enable the verify-sig USE flag to verify the downloaded tarballs.

Obtaining the signature and checksum

Whether or not you decide to use signify to verify downloaded files, you need to obtain the detached signature linked on the respective project page or git repository¹. It contains the signature as well as the checksum.

Obtaining the public key

To fully verify a download with signify, first obtain my public key. I keep a copy of the same key on DNS, feel free to verify it therewith:

$ drill TXT releasekey.oriole.systems

Another copy of the key exists on the Libera Chat IRC servers, in my taxonomy data:

/msg NickServ taxonomy wolf

You may want to keep the public key saved on your system for future verifications.

Verification with signify

Once you have downloaded my public key, run the following to verify your download:

$ signify -C -p release.pub -x <snapshot>.asc
Signature Verified
<snapshot>: OK

Verification with sha256sum

Alternatively, if you don’t want to install signify, you can use the sha256sum tool to only verify the integrity of the download:

$ tail -n1 <snapshot>.asc | sha256sum -c
<snapshot>: OK

Verification of the corresponding commit

Every tarball hosted here contains its corresponding commit ID in the global extended pax header². Therefore, if a tarball is signed, it may be used to verify a commit and all of its ancestors.

To do so, place the tarball in the cloned git repository first. If you already have the detached signature, you may verify the tarball normally like shown above. Otherwise, you can fetch the signatures directly from the repository:

$ git fetch origin refs/notes/signatures/tar.gz:refs/notes/signatures/tar.gz

Now you can verify the tarball like so:

$ git notes --ref=signatures/tar.gz show <version> | signify -Cp release.pub -x -
Signature Verified
<snapshot>: OK

Once verified, you can extract the commit using git-get-tar-commit-id(1) and show it:

$ gzip -d -c <snapshot> | git get-tar-commit-id | xargs git show

though one thing still disturbs me greatly
and I don’t know whether I am alone in this
but it is most obvious at night, in the dark
or in the haze, the fog;
that I am not fully there - that there is
in another space, another self, not me
but indistinguishable from me,
yet wholly alien.

it is irksome to know this, and
whilst I have come to learn how to cope,
it never fully leaves me, this thought
that I am fake.

it seems an impossible situation, to be
and not to be at the same time, and to
hide and show as necessary, just so;
yes, the necessity of it is still of
great difficulty. I am not sure
whether to continue or not, to be,
to not be, at the same time.

since, in the past, it worked and
sometimes made it easy.
yet, it is not honest, and I fear
being eaten up from the inside
by this self, and for it
to take over.

then, nothing will be true
but everything will go on as if
it were.

and so I leave this query with
utmost confusion and no real
hope of assurance
that my self be saved and the other
to be discarded.

Concrete. Drab, lifeless surfaces, complete in their sterility. Dust from abrasion dancing around in the few shafts of light like poisoned spores, carrying death across the hallway. Lying against the blood-stained wall, this should be his last moment in life. Born in concrete, deep below the earth, away from sunshine, green grass, sunflowers, singing birds; Killed in concrete just the same, smashed against the wall, shot into the lungs and shoulders, bleeding out far away from light or happiness.

The others were all already gone. Strewn about, lying atop of each other, dead eyes, pale skin. Grey and feeble, like the concrete all around. Pools of blood under the bodies, a dark coagulated red. Life forgotten now seeping into the devouring pores of the cement floor.

“I’ll end up like them, eaten up, rotting here where there is no sunshine. I’ll end up in the belly of the concrete monstrosity, my skeleton grinning sheepishly at the unlucky dwellers who find this vault expecting riches, but getting only death; death grimacing back, and the concrete, silent as ever, watching, waiting.”

A putrid smell lay in the room, ironlike, miasmatic, and dusty. Thankfully only a few more breaths left. Complete silence, except for the ghastly wheezing of ruptured lungs. A last reminder of life dwindling between the uncaring walls. Nobody listening except the elongated and lobeless concrete ears, the rough surfaces like petrified skin.

Darkness slowly crept in; first at the edges, concealing the unnatural smiles of mutilated faces. Faces of friends, family, faces of enemies, of bullies. Everyone’s face. Nobody’s face.

He drew his last breath. The darkness crept more towards the center, towards that one fixpoint; towards the concrete wall he had been staring at all this time. His enemy. Mankind’s enemy. And yet it was just a wall. Something so simple had become the name for all the horrors in the world, and it was staring back. Endlessly it was staring back, loudly accusing in complete silence.

It resounded in the corpse-filled room, mangled vocal chords in an undead chorus.

It resounded in his dying, confused mind.

Concrete.

One should live in a house like a cat, finding repose on almost every surface. To the cat, the whole house is a shelter. Every table, every sofa, every chair, every bed, indeed every floor is an invitation to find some rest. Do we not find cats, again and again, in the most unusual and unexpected places? We find them there, lying and sleeping with a kind of lightness and peace as if they themselves had designed that space specifically for them. We find them there snugly in a ball, breathing softly to themselves and relaxing their claws.

Now, in this instance, they need them not. In this instance the whole world around them, usually a cat’s plaything and center of attention, ceases to exist almost, as if they, in their peaceful huddledness, transcended life and entered the realm of daydreaming. A human realm, not an animal one. Of which things do they dream? Do they dream of the mouse that eluded them in the existential battle for life and retreated back to its hole, its own shelter? Do they maybe dream of the fields in which they were kings and queens, unchallenged monarchs of old?

Truly there is something kingly about cats; a certain evolutionary dignity. How is it that they live content with beings displaying even greater hubris? Or maybe they just want to learn? How innocent, though, in their pursuit of this. How unburdened, how free. Whom do they see when they look at us? What do they feel when we talk to them?

Can it be that it is only instinct that drives them? They exhibit such humanness, they exhibit an animal soul. It is a purer soul, a more simple one, but it is a soul. What do they feel when we gently stroke their fur with our hands? Do they feel the same kind of love? How is it to live a cat’s life?

I said earlier that cats lie down to repose anywhere. Like a human, however, they have their favourite spots. Always these spots have a distinctly human element. It is the small opening under our beds that we so cherished as a child, dreaming of and building at the same time a warm and safe den ourselves. It is next to our spot on the sofa, as if we radiated a familiarity and comfort there even in our absence. It is in the bags we use for our shopping, the suitcases we use for travelling.

It is on our discarded clothes on the table, floor, chair or bed, as if they wanted to absorb the fragrances of our lives and thus come closer to our person. It is our smell that is home to them, our ‘‘having lived’’ in something, on something, that is so dear to them. Maybe they want to feel the pain that was inflicted upon us, or the joy and happiness that was diffused through the clothes as we wore them. They are not all without us, and while we are gone they are emptier inside for the loss, seeking refuge, seeking a nest, seeking shelter from the rain in the touched and transformed things we left behind. We are their mothers and fathers to them, we are their family. This bond transcends species, it is therefore something inherent in life. It is a soulful longing for nearness, a longing for exchange of life, and what makes life what it is.

My cats cannot comprehend what I have written here, but I believe fully that they feel the same way. The cat hair on my clothes is their attempt at sharing this warmness, this closeness. And when the cat lies down close to me and purrs with all the excellence of beauty and reverberation, then I feel loved in the universe and want to share that love. Maybe in this simplicity we should look for love and give it back with all our heart. Maybe in this simplicity we have found the core of us and the dignified true expression of the animal, and of nature.

In the lowland of the taiga;
And vast forests boreal
Midst wapiti and wild reindeer,
Lynx, stoat, squirrel, snowshoe, brown bear,
Lives a hermit in remembrance
Of old days and the explosion.

Green the firs, bicoloured birches
Waving proudly in light wind;
Poplars shedding crimson catkins.
And the hermit, longing, silent
Standing lonely on the brink
Of tundra, opens weary eyes and sees.

Oak trees bending, whipping back;
Barks then tinged by hellish fire,
Songbirds in a sky of black.
The mushroom cloud, the ball of red:
People fleeing, hoping, dying,
To the church walls shadows burnt.

In the seas the water boiling,
Blistering from the reflection
Of the short-lived man-made sun.
Uriel in heaven crying,
Mourning loss of the creation
That, in war, unmade itself.

No more seasons, only winter;
Everlasting winter, with grey soot
Like snowflakes falling gently
Down to blackened soil; a Hell
on Earth, forever dead and frozen.
Upon mankind a shadow cast.

So the hermit with his gas mask,
Breathing filters and asbestos
Makes his way, past sickly tree stumps,
Past the rotten flesh, past poison
Past the hollow shells of old
Through miasma to catharsis;

Through the lowland of the taiga;
In vast graveyards boreal
Midst wapiti and dead reindeer,
Lynx, stoat, squirrel, snowshoe, brown bear,
Through miasma past the tombstones
Past the unmarked grave and carcass.

Face turned west another fire,
Older still than the creation;
Shimmering subtly, orange, crimson
Through the clouds and casting rays
Upon the rolling hills afar,
Lights like ghostly sirens calling.

And the harp, resurging music,
Calming shadows, living beings,
Forests, meadows, nature, beauty!
From that subtle light display
Made the hermit so resentful
And envious of death’s embrace.

Far away inside a bunker
Beneath the old charred earth forgotten
Lies dormant in a silo still
The array of rockets primed;
Awaiting silent, patient, stoic
An end, and the explosion.