/home/orva

Troubleshooting flaky multi monitor setup with RX 9060 XT

2026-02-26T00:00:00+00:00

This was originally tooted</a> a while ago.

I "recently" moved my Radeon RX 9060 XT GPU from my Windows gaming PC to my Linux box so I could test how well games run under Proton. There was just one extremely annoying problem: if I had both of my monitors connected, one of them would repeatedly disconnect. There was no system logs or dmesg output, monitor just flickers. Everything worked in previous PC: same monitors and same cables, just different OS.

So I have been running with only one monitor for while because games have been running really well on this machine (even though CPU and RAM are not near as good as the ones in the Windows box). Which is lovely! But this monitor situation has been bothering me more and more as time went on.

Debugging these kind of display problems is bit painful for me as flickering monitors can trigger migraine and low refresh rates trigger dyslexia.. which in turn can trigger migraines. So I kinda had to collect some spoons and annoyance/spite for debugging to happen. Well, spite was collected and it was time to collect some observations:

one of the monitors started flickering, not both of them</li>

display refresh rate list was bit weird looking 143.98, 120, 59.95</li>

having same/different refresh rates didn't have effect</li>

curiously having 59.95 on both monitors stopped monitor disconnecting!</li>

everything above repeats on KDE and Gnome, both on Wayland</li> </ul>

This was not solution though, I can't stand the sluggish cursor with 60hz refresh rate and it is absolutely no-go for games. It would also tire my eyes quicker -> migraine territory.

So now hypothesis was that maybe the GPU cannot keep the refresh rate stable and monitor does not like it? This could also explain why there was no log output, issue happens at too low level for default logging? Time to enable "variable refresh" in monitor settings and put "adaptive sync - always" on. Idea was that if refresh rate doesn't stay stable but monitor somewhat expects this, it might be fine?

....aaaaaand this seems to work? So far there hasn't been monitor flickering/disconnecting. Been running these settings for about a month now and there has been no issues, even under heavy load.

Hopefully this is useful for someone else as well.

My little GoToSocial installation tweaks

2025-04-27T00:00:00+00:00

I started hosting my own GoToSocial</a> instance this weekend and "bravely" moved from the old instance immediately. Configuration was straightforward operation, I mostly just followed upstream documentation and went with defaults. I do have some opinions how I like to maintain servers, so "obviously" I had to tweak things a little regarding how and where things are installed.
This post is mostly about those little tweaks. So basically thoughts about how I want to install software that is not packaged for distribution server is running and how I applied that to GoToSocial.
What upstream GoToSocial recommends</h2>
Steps from installation</a> and configuration</a> steps could be summarized to this:

download and extract release tarball to /gotosocial</code></li>
copy /gotosocial/example/config.yaml</code> to /gotosocial/config.yaml</code> and edit according to the documentation</li>
copy /gotosocial/example/gotosocial.service</code> to /etc/systemd/system/gotosocial.service</code> and edit according to the documentation</li>
systemd service sets working directory to /gotosocial</code> and all state is stored there</li>
when updating, extract new tarball on top of the /gotosocial</code></li> </ol> Now, these are wonderfully simple instructions for people who do not have that much experience about CLI or maintaining servers. I really like that! It is a really, really lovely that hosting this kind of nontrivial service is made to be approachable as possible. I just have opinions how I want my servers to look like, which differs from that.
Why I want something different?</h2>
I want to be able to roll back to older release if there are problems. Obviously it probably is not going to be possible with GoToSocial which is often running big database migrations between updates and is pre-1.0. I still like to approach the installation like I could do rollbacks for consistency’s sake.
With software packaged for the distribution, downgrade is just simple pacman/apt/dnf incantation. With non-packaged software some work is needed to get there, I need to keep old versions around and make it relatively easy to switch between them. For the most recoverable solution I would do something like this:

store application bundles under /opt/software/<version>/</code> and symlink currently in use bundle to /opt/software/current</code></li>
store configurations under /opt/software/configs/<version>/</code> and symlink current configuration to /opt/software/configs/current</code>or /etc/application/<version></code> and /etc/application/current</code></li> </ul> </li> </ul> With that setup both bundles and configurations can be rolled back, together or individually. I don't bother going that complicated with my own server setup as these are rather simple and slow moving targets where I don't need to recover catastrophes fast. Those capabilities are really handy in work context though! Other approach would be to package software by myself. I just find above approach be less painful than trying to get apt/rpm tooling happy. Or use containers. Containers are just are still in a phase where setup breaks after every distro upgrade. That is not something I want to deal with in server I maintain with my free time and where I don't benefit from the flexibility of containerization. Ansiblefy everything</h2> I might not be big fan of Ansible</a>, but it is rather pragmatic and widely used tool. It is also a tool that I am somewhat familiar with, and it breaks in expected ways. So my ansiblefied install/upgrade flow for GoToSocial this: download and extract release to /opt/gotosocial/<version></code></li> generate /etc/gotosocial/config.yaml</code> from jinja template, required to parametrize following config options: web-template-base-dir</code>: /opt/gotosocial/<version>/web/template/</code></li> web-asset-base-dir</code>: /opt/gotosocial/<version>/web/assets/</code></li> also set storage-local-base-path</code>: /var/lib/gotosocial/storage</code></li> also set db-address</code>: /var/lib/gotosocial/sqlite.db</code></li> </ul> </li> generate /etc/systemd/system/gotosocial.service</code> from jinja template, required to parametrize ExecStart</code> to point to the correct /opt/gotosocial/<version>/gotosocial</code> binary</li> </ol> Of course there is a bit more fluff around that to make sure required directories exist, have proper access rights, (re)starts happen, etc. But that is something I cannot avoid with the more manual approach either. Now updates are just "read release notes for special steps", put new version number into playbook and few moments later a brand new service is running.
Why I don't use Node.js for hobby projects? 2024-04-06T00:00:00+00:00 At previous work the most common tech stack by far was PostgreSQL + Node.js + React. Even if main portion of the project was not built with that stack, there usually was some Node.js component lurking nearby. If I recall correctly the earliest Node.js version I have seen in production environment is v0.8</a>, that is almost 12 year old release! I have seen the io.js fork</a> saga unfold. I remember the JS ecosystem evolving from CSP</a> to CSP helpers, from CSP helpers to Promise/Thenable</a> libraries (q</a>, bluebird</a>), from Promise libraries to native Promises and latest syntactic iteration: async-await. That is around 10 years of mainly using JavaScript and Typescript at work, even when taking into account all the C++ and embedded projects I was involved with. So amount of JS/TS diffs I have written is probably in hundreds of thousands of lines. So why I don't have any hobby projects with Node.js stack? Even with all the pros? What are the Node.js pros?</h2> The amount of good enough libraries is astounding! There probably isn't protocol or file format which doesn't have usable library readily available. Node.js ecosystem is popular enough that there is often multiple competing libraries or tools for the same task, with different tradeoffs and advantages. Developer experience for starting new projects is astounding! Dependencies require just simple npm install</code> and are ready to use, in both locally and in the host/container you are deploying to. For more complex project setups there is often popular project template</a> available which requires just npx <template> my-project</code> and off you go. One cannot deny how convenient the npm</a> ecosystem is when project is starting or in full swing. Node.js scaling! Hobby projects probably won't need the upwards scalability from asynchronous approach, but the Node's quite miniscule minimum requirements and resource usage when not under load are very nice. Running Node.js projects on single board computers like Raspberry Pi is not a problem. Node.js cons</h2> The most pressing issue is that ecosystem feels inherently unstable. There hasn't been huge shifts like iojs or Promises in a long time, but there is constant shuffle in library ecosystem. Which can be frustrating even when project has people working on it every day and thus amortizing all the work caused by the shifting foundation over longer time period. But this is horrible when touching a project maybe few time a year! Even isolated "update dependency to fix CVE" has real potential to evolve into cascading "update everything and everything is incompatible without code changes" nightmare. The nightmare situation is even more likely to happen when there are only bursts of development activity with long pauses between. One can argue that solution is just not to use dependencies, but that npm ecosystem is one of the strong points of Node.js, not taking advantage of it would be kind of silly. Other sanity saving option would be to use older and maybe more stable libraries, but there are few gotchas. It feels like more stable libraries are properly old (in JS timeframe) like Knex.js</a> or Express</a>, which comes with all the baggage from that age. Those libraries are born in times when there was no Promises, there was no TypeScript</a> (or flow</a>), no ECMAScript modules</a> (CommonJS</a> was not yet universal, like it was for while) and many other small ergonomic issues from modern standpoint. These old libraries have evolved with the times (causing, you guessed it, some minor compatibility problems), but they still come with some API warts that cannot be fixed without breaking every downstream project. Then there is the more experimental libraries which might have really nice ergonomics but come with high risk of being abandoned or API instability. It is very difficult to guess which of those newer libraries will be around after a year or two. I can guess few reasons for the instability part: those libraries and tools tend to be either one person hobby projects or built by VC funded startups. Both of which have been in spotlight lately for issues related to them: abuse/burnout in case of hobby projects and walled gardens in case of company backed projects. It feels like there is no middle ground between these two extremes. So sadly it is hard to see situation getting better in the near future, which means that I won't be using JS/TS for my few hobby coding hours. Maybe that is good thing, doing my part to keep extra churn out of the ecosystem.