But to be honest… I’ll probably change it again, when I have more time.
]]>I did not sign up for marketing emails and actively work to keep them out of my inbox by whatever means necessary.
This unsolicited notice has finally convinced me that GitHub as it currently stands is no longer somewhere that I wish
to promote by continuing to push my code to its platform. This is a relatively minor event overall, but I had already
been considering dropping GitHub as I find the site more and more non-functional for my day-to-day usage. I haven’t
been affected much by the downtime yet, but I am continually affected by their code viewer introducing weird jank by its
nature of being <canvas> based now, resulting in misaligned text, copying issues, problems jumping to lines, and more.
It worries me that they had a search downtime so severe that issues and PRs could not be properly searched for multiple days. The SPA nature of the site continually breaks my back button and history, and recently it has started failing to load new pages completely, requiring me to manually refresh the page to force it to actually make a normal web request and get the full page state. This entirely defeats the point of even having an SPA in the first place.
I haven’t kept a good record of everything that annoys me about GitHub, and I’m sure there’s more I don’t remember. But hopefully, this shows that the email I got is just the latest in a long-standing decline in quality at GitHub.
I need to balance a few different concerns when selecting where to host my code. In approximate order of importance:
Transferrable. I should be able to export my data, for the inevitable future migration.Open Source. The project should be open source, so it’s at least possible for me to use the exported data in the
original form.Social. Others should be able to easily file issues and make PRs, with minimal friction.Sustainable. The company or person hosting it must have a sound plan for keeping financial incentives away from the
project, so it is less likely to be cost-cut to death. In practice, this means it should be a non-profit corporation or
public service; or self-hosted.Vibe. I should like the vibe of people working on and owning it. This is pretty subjective of course.With these in mind, here are the options I considered.
Tangled is something I recalled going around BlueSky last year. They are Open Source, and their AT Protocol base
means that it can be considered Transferrable and Social as well. However, they fail my Vibe check by having some
of their primary discussion platforms be Discord and X. I’d like to reduce my reliance on these platforms due to their
closed nature (both proprietary and having login walls). They also fail at being Sustainable, as they are funded by
VC money. At some point, those investors will want a return, and I’ve seen what happens then many times
over. So I discarded Tangled as an option.
I’d also heard about Radicle a little bit. They are again Open Source and, due to being decentralized entirely, also
Transferrable. However, the current state of it is that all operations must be performed by CLI or their Desktop app.
This severely limits how Social it is, as it’s much more involved for someone to even file an issue on my project.
Their Vibe is a little bit uncertain for me. In terms of communication, they do still have a presence on X, but the
primary development communication occurs on Zulip, which I like. Their primary funding comes from Radworks, which
appears to be some kind of variant on a DAO. I’ve heard some good arguments against these, essentially that because it
still has to interact with the traditional expectations of other entities, someone will always be holding the power to
make changes without going through the formal on-chain process, making it not much different from a normal organization
but with a lot more overhead. For example, someone has to own the domain and DNS for it, and whoever has access to that
can make whatever changes they want.
However, the Radicle devs seem to be considering moving away from this as their primary funding. I’m
also still not sure myself if I consider it a problem. Radworks seems to be somewhat aware that they are not entirely
bound to the blockchain, and explicitly have some off-chain mechanisms. And Radicle itself is actually owned by the
non-profit Better Internet Foundation. Overall, I’m not sure how I feel about them being Sustainable.
If Radicle had a usable web interface and some more time to build trust that Radworks is sustainable, I would likely pick them. I really like the ideas, but it seems they still need some more time to cook.
Self-hosting, to me, is the ultimate Transferrable and Sustainable option, as I would only shut down the service if
I did not need it any more. Due to my preferences, anything I picked would obviously also be Open Source, and
obviously I like my own Vibe. But the one way that this currently fails is Social. The established options that are
self-hostable (Radicle again, Forgejo, GitLab, etc.) all would still require users to either use weird interfaces or
to sign up for an account on my personal instance. I consider that unacceptable friction. I would really like it if
there was an option for federated or decentralized forges, but it’s just not there yet as far as I can tell.
I unfortunately must discard this option.
I did not spend much time looking at GitLab as I’ve previously tried using it, and found that I really did not like how
the website felt. I just don’t like the Vibe, and for me, that was enough to barely consider it.
We now come to Codeberg. Based on the Open Source Forgejo, they even advertise on their docs that you can migrate
from their instance to another Forgejo instance using the same migration tools they offer, easily making it
Transferrable as well. I’ve seen a lot of projects moving here, and they already have a sizable userbase, making it a
pretty good Social contender. As a non-profit with a decent donation record, they look pretty Sustainable. And
finally, I do like their Vibe. They even kept the Anubis mascot on!
So clearly, I’m going to start moving over to Codeberg. My account is at the typical octylFractal. I won’t be moving over existing repositories en-masse, but whenever I update one, I will be copying it to Codeberg first and archiving the GitHub original with a notice. I’ve started with this very site, which used to live at https://github.com/octylFractal/octylFractal.github.io, and now lives at https://codeberg.org/octylFractal/octylsite.
Let’s keep fighting the enshittification of the online web as best we can; by making conscious choices to use better things where we can.
]]>Well, I have now. Instead of loading a prebaked PNG and tiling it, the pattern is now generated procedurally wherever I need it, during the static site generation. It bakes an SVG that is then repeated to fill the sidebar background. The advantage of this is a lot smaller file size, and since it can be trivially inlined, it saves an extra request and no longer flickers so badly when navigating. It also fits the vibe I was going for a lot more.
The implementation does make me think about retiring Jekyll though. I really would like to be able to write with, y’know, actual functions ‘n’ stuff. Jekyll is also getting quite slow with how complex my Liquid usage is. I would probably switch to a custom system that uses JSX/TypeScript and emits a static site from that, with extension points. Why that over Java? Because JSX is well-integrated for writing HTML.
That’s all for now. See you in another two years :)
]]>audio-bicycle, 2022-2024I recently went to make some changes to my old project, audio-bicycle, but I found that it was no longer necessary! PipeWire now has built-in VBAN support (send, recv), and this works well enough for me that I no longer need audio-bicycle. I’m kind of sad to see it go, but its name will live on in the configuration of my new setup.
However, there were a few gotchas I encountered while setting this up. For context, my configuration is designed to take outgoing audio from my Linux desktop running PipeWire, and send it to my Windows machine running VoiceMeeter to be output on the speakers. The Windows machine also sends microphone audio back to the Linux machine, for use in voice calls. I like to listen to music while I work, so I need a completely clean signal with no noise.
The defaults for the VBAN modules are not very good, picking 44100 Hz rate and S16LE format. This requires remixing
from my 48000 Hz S24LE audio, which introduces some artifacts. I recommend checking what you’re using with pw-top
and setting the VBAN modules to match, or at least transferring S24LE audio. Here’s the settings I used on each module:
audio.format = "S24LE"
audio.rate = 48000
You should also make sure that VoiceMeeter is configured to use the same settings on its sending side, as PipeWire will
not check or do any conversion for you :(. [2025-17-02] I believe this is no longer the case as of
this commit, but
I don’t think it’s released anywhere yet.
PipeWire’s VBAN modules also pick very high latency numbers, presumably because they expect to be used over the internet. I adjusted these down for the very low latency I have on my local network:
# For send and recv, keeps a smaller buffer.
sess.latency.msec = 2
# For send only, minimizes the time between packets
sess.min-ptime = 1
I needed to increase the quantum in order to prevent certain applications from not having enough buffer, like mpv.
Putting node.force-quantum = 512 on each module’s stream seemed to be enough, but this is likely
environment-dependent.
Finally, I had to set node.always-process = true on both modules to ensure that the audio was always being sent and
received. This is because the modules will stop processing audio if there is no stream connected otherwise, and this
can cause noise when starting a new stream. This made noticeable pops when starting music or skipping tracks, which
was very annoying. I assume the same could occur with the microphone, but I haven’t tested it. The cost of ~3% of one
CPU core is worth it to me to avoid this noise.
[2025-17-02] None of this is necessary now, due to many improvements in Pipewire. It’s working fine on 1.2.7.
For reference, here’s my final configuration file 01-audio-bicycle.conf:
context.modules = [
{
name = libpipewire-module-vban-recv
args = {
source.ip = 10.190.229.127
sess.latency.msec = 10
sess.name = "audio-bicycle"
audio.format = "S24LE" # [2025-17-02] This and `audio.rate` might not be necessary soon.
audio.rate = 48000
stream.props = {
media.class = "Audio/Source"
node.name = "VBAN Mic"
node.description = "VBAN Mic"
}
}
}
{
name = libpipewire-module-vban-send
args = {
source.ip = 10.190.229.127
destination.ip = 10.190.229.105
sess.min-ptime = 1
sess.latency.msec = 2
sess.name = "audio-bicycle"
audio.format = "S24LE"
audio.rate = 48000
stream.props = {
media.class = "Audio/Sink"
node.name = "VBAN Speakers"
node.description = "VBAN Speakers"
}
}
}
]
There was also a ton of adjustments to improve mobile behavior.
]]>In order to ensure it meshes with the existing page, the new patterns have shadows around the edges. I also added a shadow around the navbar and footer to make them stand above the content. I’m quite happy with the results, and I hope you enjoy them as well!
]]>As usual, I’ve also updated some dependencies to the latest version as of writing: Bootstrap (5.2.3), Jekyll (4.3.1), and Jekyll Feed (0.16.0).
]]>