Rentlar

Following best practice would be ideal, I agree with you, but for FOSS projects I can settle for best effort, and ability to configure/correct any serious errors if it is brought up constructively. Every dev has their own biases and they make tools to fit their needs, not necessarily everyones. Like if it was by accident that a personal filter was pushed to all instances, and then immediately fixed when made public, personally, I could forgive the dev for the mistake. But available evidence shows this was not a mistake, and intentionally hiding things this dev didn’t like, pushing the upstream changes without telling anyone.

I don’t do racing sims but with Train Sims I have used other accompanying software, and modlaunchers etc. in the past. I assume Simhub etc. are programs that launch the main game or run concurrently.

If you want to install it semi-manually, have you tried setting it up with Lutris? Set the wine prefix to be a folder insids your steam user folder steamapps/compatdata/[gameid]/pfx on the drive the racing game is installed. Other guides I found:

https://www.simhubdash.com/community-2/simhub-support/guide-simhub-on-linux/

https://github.com/srlemke/SimHub_on_Linux

If it’s hardware connection issues, that’s another whole beast

Interesting choice to give the developer who already violated user trust by imposing a secret blacklist the benefit of the doubt on their bigotry.

I never did that, sorry I kind of suggested I did in my last reply, when I meant in general to devs that don’t break peoples’ trust. In a vacuum, a configurable blocklist with biased defaults is acceptable, even if I wouldn’t set it myself that way. Their work, their choice. However, it is specifically the concealment of the biased defaults that is the breach of trust which calls into question the dev’s motivations.

Requiring users to enable “toxic mode” in order to access queer spaces isn’t evidence of bigotry to you?

Alone, no, that would be mere speculation, if combined with the shady practice or if you have antiLGBTQ quotes then yes, I could say that fact potentially supports that conclusion. Consider that blahaj.zone is not the only LBGTQ+ safe space on Lemmy (see beehaw !lgbtq_plus@beehaw.org). Any admin or dev could have beef with Ada, not with queer folks, that could be motivation to block blahaj.zone. I never gave the tesseract dev that grace, because that blocklist with blahaj was never publicized, until the clandestine filter list was discovered and decoded.

If they come out and say they don’t like blahaj.zone for bigoted reasons, let them, don’t support their project, done. I’ll defend blahaj.zone’s strictly enforced any pronoun policy as much as a dev who clearly chooses to include or exclude certain instances by default, as long as the intentions are clear, not hidden away and easily rectifiable for your needs. What I am saying is a breach of trust is worse than bigotry, which itself is worse than mere ideological disagreements. A < B < C.

You can read into how you like the presence of certain instances/words/users on the blocklist, but putting BZ on a blocklist = bigot seems to me like a jump to conclusion.

you are being far too charitable with an obviously bad faith actor.

Like I said, I afford FOSS devs lots of grace and benefit of doubt, that’s just me, if the issue was solely over the choice of instances being blocked by default, I’d excuse it, but that isn’t the main issue. Call me too charitable, sure, it’s in my nature and you don’t have to be me.

The issue is the blocklist was hidden away in base64, not documented anywhere, while constantly being updated, without any justification (like pulling from a public spamlist), and was secretly affecting every server’s Tesseract frontend. It was the trust that the so-called “Toxic mode” could remove all filtering, but it didn’t, and the trust that connection errors were simply configuration problems and not intentionally obfuscated filtering routines, these formed the trust that was broken.

One note/minor correction, it is in the git repo: https://github.com/db0/tesseract/commits/main/static/data/policy.dat

You can see when asimons04 changed the static base64 filter .dat file. The changes happen in completely unrelated or nondescript commits. Looking at the commit when it was implemented, it does say filter, but the error messages and code comments creating the folder indicate “cache” folder creation, when the variable name and function is for the policy, which might technically be correct, is misleading and is quite suspect to me.

Like I would have zero problems with developers that do this, if they could come out clearly and document/announce: “I don’t like these accounts or words, if you do then this is what you do to change it or shut it off.”

Stuff like Lemmy’s word list, Piefed’s default blocklist, you can turn off or change the words. Even if I think the daily vote quota is a stupid default on setting, if you’re a Piefed admin and don’t like that, set the limit to 10000, 99999999 or whatever. I usually have tons and tons of sympathy for FOSS devs, take their side and give the benefit of doubt in grey areas. They work for free and share it for free so I don’t expect perfection or how I would want things to be.

Undocumented shit like this, intentionally hidden is way past the line, and I have no patience for it whatsoever. You never know when this could be somehow used as an attack vector.