The "cool" part was that I ran a cronjob that rendered the map to a png file once and hour, and at some point a friend asked why there were holes in the map. Back then, Minecraft stored every 16x16 chunk of the map in an individual gzipped file. When the raid1 decided to read the chunk from the bad drive, it couldn't unzip it. If that happened to the renderer, there was a hole on the map. If that happened to the game server, it would regenerate the chunk, and overwrite the old one on both drives, even the healthy one. Luckily as far a I remember that only happened on random terrain, otherwise someone would have ended up with half their house missing.

1) you dated a guy on tinder, he became all pushy on your first date, touched you inappropriately even though you said no. Or some guy became violent during your relationship and you even found out he has a history of that.

2) you dated a nice guy but he dumped you for whatever reason, and now you want to get back at him so you make up stuff like mentioned above, and post it there.

Invite issue: https://github.com/element-hq/element-web/issues/29028

And several ones opened against synapse, but as it happens a fix was finally merged a day ago: https://github.com/element-hq/synapse/pull/18696

- The web client doesn't load any images/media anymore for me in new sessions. I log in, I cross authenticate with another client, no images load. At work I've a very old browser session going and everything works.

- We host synapse at work to explore feasibility. Been going on for about 9 months now. Public profile lookup is disabled. This breaks inviting anyone from our company from another server, when the inviting user is using element. Because element tries to query the user info first, and if that fails with an unexpected error code, it will not allow you to continue sending the invitation. There's obviously an issue open for months now, where multiple people suggested they just add a warning that it couldn't check if the user exists, with a "continue anyways" button, but the devs prefer to come up with idiotic excuses why that would be a bad idea.

I did some quick research myself then, and it looks like the profile lookup is relayed through the server of the inviting user to the server of the user to be invited. The inviter's server converts any http error code from the invitee's server that is "not valid" to a generic error, that element then chokes on, here: https://github.com/element-hq/synapse/blob/1920dfff40ad10780...

i.e. Only 404 is valid, according to code and comment there.

But IN THE SAME FUCKING SOURCE FILE, they return a 403 if profile lookup is disabled: https://github.com/element-hq/synapse/blob/1920dfff40ad10780...

Can't get any better than this I guess. Cobbled together bullshit. I hope my company will consider this experiment failed soon and switch to slack or something. Anything.

1) even though reality has proven us wrong time and time again, we can just not look at the dependency too closely and just act as if it's written and maintained by competent, caring people and is of highest quality. No worries!

2) in case shit hits the fan, let's assume worst case and there is a vuln in the dep and you get hacked... It's somebody else's fault! \o/

Dangit, the fact that you had to explain it like that makes me feel old. There was a time when that software was found on everyone's PC and held the top spot on sourceforge's most downloaded list.