hosaka

Double Commander is also worth mentioning

I think it's is not aimed to protect against potential attacks, this is aimed at a developer using/writing modules of code. This is not a security guard

Glad you figured it out! A separate network for a set of services that need to talk to eachother is the way I do it for my selfhosted tools, if you want some more ideas on setting up the *arr apps using docker compose, this is my current setup: https://github.com/hosaka/selfhosted/blob/main/servarr.yml

I think you're using docker internal IPs, which are not static and can change between docker compose runs. You can instead address them by name if you connect then to a same virtual network: https://docs.docker.com/compose/networking/#specify-custom-networks

This allows two service to "see eachother". For example "calibre:8081" will resolve to an internal IP address. I'm general, this is a better approach when you need to connect apps to each other.

When setting up nvim-treesitter neither clang nor msvc worked. Rather, it worked and compiled the necessary libs but the treesitter plugin failed to load the necessary .so libs. The common troubleshooting steps didn't help (setting up clang as preferred compiler etc.), so I just ended up installing zig and that helped to get it working.

Also allows you to use hardware acceleration for inference. Quite a comprehensive set of tools actually, also the new revamped UI is on the horizon with version 0.14

In a game that is production ready you would be going through individual assets with the person who designed them and you'd establish when to spawn and despawn them. As designers tend to go crazy and not worry about memory at all, I tend to guide them to think about memory availability in a particular scene. Really depends on the game you're making though

You can push mirror your fork back to GitHub when you deem necessary (e.g when it's in a good shape) and create a PR to the parent repo automatically using forgejo runner script, you'd just need to make an API token. If the goal is to automate PRs. If the goal is to not use GitHub for your forks but still continue to make PRs, you can't work around that I think. Unless there's a way to PR a bunch of patch files perhaps?

Yeah I can make a list of features that I'd like to have and annoyances that exist now, but I wouldn't call it stuck in a single monitor paradigm either. Depends on what your needs are I guess!

JetBrains IDEs can be easily configured for multi monitor setups. I use Rider daily and have a couple layouts saved for different purposes that make full use of 3 monitors, never really had a problem with it. Can you be more specific about what you want to achieve?

Yeah it's a ci/cd runner, using a tool called "act". I self-host forgejo and the runner is a docker-in-docker container, but one could set it up with the public forgejo as well. It's pretty neat!

Did exactly this recently and it's been quite good. Forgejo-runner was a bit tricky to setup but overall a great experience.