Category: General

Good Bye Tiny Tiny RSS / TT-RSS

Yesterday – after roughly eleven years (just checked the database entries) – I’ve decided to switch from Tiny Tiny RSS to FreshRSS. The transition was quite smooth, but I’ll get to that in a bit.

First let me point out the reasons for me wanting to switch.

  1. Feed refresh issues: About 2-3 months ago, I noticed that when I opened my feed reader app (also called Tiny Tiny RSS) on the phone, I wouldn’t see new articles. Even manually ‘pulling down’ the feed list, which used to force a refresh, didn’t do anything – same article counts as before. You would think the whole thing is broken, except that once I entered a feed, and I pulled down the article list, suddenly all the new articles appeared. So it was definitely something more subtle than “the whole thing is broken”. I tried the obvious thing: Updated the app (which I think was no longer in Google Play, so I got the new version from F-Droid). That didn’t change anything. Then I wanted to update TT-RSS on the server (which I do every couple of months, by pulling the git master branch). Then it didn’t work anymore at all, because…
  2. PHP Version compatibility: The maintainer(s) had decided that PHP 8.1 – despite being the default still in Ubuntu 22.04, and being officially supported until December 2025 – wasn’t worth supporting anymore. Because…
  3. Strong focus on Docker: In many places, for quite a while now, the maintainer(s) make it clear that they don’t care about any other way to deploy TT-RSS than via Docker. Where obviously having a newer basis with a more up-to-date PHP is trivial. I can understand that to some extent, but I just don’t feel like going the container way for something as simple as my PHP-based RSS feed aggregator webapp. I guess I’m just old-fashioned. And why didn’t I attempt to get support with my initial issue (1) from the community? Because…
  4. Unfriendly community, especially the main contributor / maintainer: From previous bug reports / feature requests (which I can’t remember in detail) I remember the harsh tone and unfriendliness, especially from the maintainer ‘fox’. I’ve met my fair share of assholes in FOSS, but he stood out and left a lasting memory. And while I was thinking about that, I also remembered an article from Flameeyes, which really unnerved me back then in 2017. I was quite close to switching to another RSS aggregator then, but since Flameyes’ ModSecurity rule must have malfunctioned or something, and I still got articles from his blog, I stuck with TT-RSS, despite definitely not being a Nazi sympathizer. Call me lazy…

So, root cause: Supermassive asshole (works like a supermassive black hole, only in the other direction – stuff comes out from it), whom I didn’t want to report a bug to (again).

So why FreshRSS?

  1. FreshRSS was really easy to set up, even without using Docker. The documentation is really good, and it took me only about an hour from start to finish (all feeds migrated, refresh cronjob set up, app installed and connected to the webapp’s API, etc.)
  2. It actually feels snappier than TT-RSS, but of course I now have a nearly empty database. It also supports two common APIs: greader and fever, which makes it compatible with various mobile clients. I picked FeedMe for now, let’s see whether I’ll stick with it.
  3. I read that the community around FreshRSS is not centered around a supermassive asshole, which is definitely a plus.

That’s it. I should now be able to consume my news and blog articles the way I like it… without having to manually refresh every feed, deployed how I like it, and with the PHP version I like.

Wayland, finally.

I’ve been watching the Wayland development from afar for a couple of years now, probably since 2014. But whenever I gave it a try, after less than 10 minutes something was so obviously broken that I immediately went back to X11.

Until yesterday, when I decided to give it another try. The trigger was, that KDE/Plasma felt sluggish on my machine. Even though it has decent specs (12 core Ryzen, Nvidia 4060 Ti, fast NVMe), opening a simple application like Konsole takes 1.5+ seconds. Even clicking the start menu button has a noticeable delay (~300-500ms). On X11 that is.

After rebuilding a bunch of packages (because I had to toggle the ‘wayland’ USE flag on, which had previously been off in my Gentoo installation), I chose the “Plasma (Wayland)” item in the SDDM dropdown and logged in. To my surprise KDE/Plasma instantly felt much better. No more delays, very smooth animations, etc.

IMO there must be serious bugs in Qt or KDE to have such bad performance on X11 nowadays. Using a simple Window Manager (Fluxbox) I didn’t feel any lags on X11. Even launching Konsole or other KDE apps from an xterm is snappy. But I don’t have the time and energy to do serious profiling, and I also really want to use KDE/Plasma.

So I’m happy that I didn’t find any issues with Wayland in the hours since. For a few minutes I thought screen recording was broken, but then it turned out that I just had to enable the ‘screencast’ USE flag and do a few rebuilds.

Will have to spend some time learning all the underlying concepts and new terms – but that doesn’t prevent me from using Wayland.

I’ll post updates here if / when I encounter issues.

Update (2025-01-05)

Today I wanted to write in German for the first time, and noticed that my .Xmodmap keyboard remapping for Umlauts no longer works. That was already problematic in X11 for a while, but it was a good solution that I’d been using for many years (and even “ported” to Windows – see here – when I had to use Windows at work).

So now I had to figure out something new. A guy in the always helpful German #gentoo-de@libera.chat IRC channel told me about the “EurKEY” keyboard layout – “The Layout for Europeans, Coders and Translators” – covers pretty much all European languages with one layout. Love it. And they took the exact same approach that I did: on an English keyboard, use a modifier key and when it’s pressed, “a” becomes “ä”, “o” becomes “ö” and so on. It comes out of the box in KDE, just had to choose it from the dropdown list!

The only issue with that is: they’re using the right ALT key as modifier, and I have nearly two decades worth of muscle memory using the Meta/Windows key as modifier. It would take a while to retrain myself, so I decided to instead remap the Meta/Windows key to the right ALT key. Works perfectly. Phew, problem solved.

Fix / workaround for non-linear volume control on Linux

Alright, it’s the time of the year where I find time to tinker a little. This time I wanted to find out why changing the volume didn’t feel “linear” for my beloved Teufel CONCEPT 8 2.1 sound system that’s connected to my PC via USB.

First of all I probably have to clarify what I mean by “didn’t feel linear”. I remember learning that human sound perception isn’t linear at all, so that’s probably not accurate. But what I mean here is that: When I slide the volume slider (or make discrete jumps via pactl set-sink-volume alsa_output.usb-NXP_SEMICONDUCTORS_Teufel_CONCEPT_8-00.analog-stereo 60%, for example), the loudest point is reached at already 40, maybe 45%, and after that it doesn’t get any louder. Or maybe it does? But if so, only marginally, and definitely not at the rate it does left of the 40% mark.

So I did some googling, but that turned up nothing specific to these speakers. And also nothing much helpful in general. I suspected some kind of quirk that nobody bothered adding a workaround for in the kernel so far. So I dove into the Linux kernel sources and tried a bunch of changes in sound/usb/mixer_quirks.c – e.g. setting cval->dbMin to different values for the USB ID of the Teufel CONCEPT 8, but also played around with cval->max as well as cval->res. It was rather tedious, because after every change I had to reboot, lacking the knowledge on how to test the changes “on the fly”. While I did observe changes to how the volume changed – e.g. the range where the volume changes fast shifted to the higher end – none of them yielded the results I wanted, i.e. “linear” volume change and no “dead zones” along the slider. So after a while I concluded that with my limited knowledge of the system’s inner workings, I could not understand how the numbers related to what I observed. So I wanted to learn more about the Linux USB audio subsystem, but gave up after a while because I figured that this would take up more time than I was willing to invest.

Just when I wanted to give up completely, I came across a bug report where someone recommended to choose the “Pro Audio” profile for the audio device instead of the “Analog Stereo Output” profile to get rid of this issue. And what can I say: works for me! The PipeWire FAQ states that using the “Pro Audio” profile “disables the hardware mixers, it only enables software volume/mute“. That’s probably what fixes the issue for me. I’d still love to understand why the issue exists in the first place though, and what the underlying layers are doing to mess up something seemingly simple as the volume slider. Maybe next Xmas holidays…?

See below a screenshot of the KDE System Settings / Sound. You can also use pavucontrol or its -qt variant to change the setting.