Your actual browsing of lemmy is moderately private, provided you trust your server.
Not exactly. Many of the big instances have Cloudflare (or similar) sitting between you and the server, providing the HTTPS layer while watching everything you read and write on Lemmy. In cryptography circles, we call this a man-in-the-middle.
Your instance (sh.itjust.works) is one such instance, by the way, as is lemmy.world.
Electronics technician with 48 years in the industry here.
The common cause of the buttons losing sensitivity is that the silicone absorbs skin oils and these oils act as insulation on the pads and tracks.
If you look at the tracks under the pads that are least sensitive , you will see the oily residue. You can clean the tracks and pads with alcohol for a short term fix but the pads will exude more of the oil that is within the silicone.
A longer term fix is to soak the whole key pad sheet in Fuelite (Petroleum Spirit) Fuelite is the main ingredient in CRC Contact Cleaner (in fact it is the only ingredient). Use liquid Fuelite to do this , not Contact Cleaner because you have to immerse the silicone sheet.
Soak the sheet for 5 minutes , it will swell a little , let it dry thoroughly and it will return to normal dimension.
While the silicone has still some absorbed Fuelite in it , it will be easily torn so treat it carefully.
Then reassemble the device.
This fix should last several months depending on the state of the silicone sheet
It's a bit of a leap to say the "owner" changed. Ryujinx is MIT licensed, allowing anyone to clone the original code locally, build upon it, and publish it to a public host. Looks to me like that's what happened here: a fork, but without using github's built-in "fork" feature, perhaps to avoid being included in a mass take-down. There are others on non-github sites, although I don't know if they have been getting new commits.
I don't see any reason to think the original repo was renamed or moved to another user's account. The top contributor is gdkchan presumably because gdkchan's commit history was preserved.
For the record, gdkchan's last commit to the original repo was on 2024-10-01.
Edit: The README confirms what I thought:
This fork is intended to be a QoL uplift for existing Ryujinx users. This is not a Ryujinx revival project.
Don't assume too much from the headline, folks. They're not saying everything has to be rewritten by 2026. They're saying new product lines serving critical infrastructure should be written in memory-safe languages, and existing ones should have a memory safety roadmap.
If you're about to post about how you think that's unreasonable, I think you should explain why.
It's one thing to make a reasonable assumption/prediction about how things probably are based on surrounding circumstances.
It's quite another thing to have objective, quantifiable data showing how things actually are. Even better if it includes the fine details: the underlying reasons behind the scenes that might not be exactly what we expected.
Nobody finds a report like this surprising, but it is important nevertheless.
You could always test the waters by writing up a few of your workarounds in Lemmy posts, and seeing how much interaction they draw. If they're well-received, the effort of building and maintaining a blog might be worthwhile.
You can’t know with certainty on Signal that the client and the server are actually keeping your messages encrypted at rest, you have to trust them.
This is untrue. By design, messages are never decrypted on servers when end-to-end encryption is in use. They would have to break the encryption first, because they don't have the keys.
Debian is also chill. There’s always unstable (can’t remember the current name. Debian Trixie?) For something that’s more up to date
Debian Unstable's code name is always Sid. Debian Testing's code name is always the one that will become the next Debian Stable release, currently Trixie.
Room membership and various other room state events are not currently end-to-end encrypted, which means a nosy admin on a participating homeserver could peek at them. (They're still not visible on the wire, though, nor on homeservers whose users haven't been invited.)
I don't know if Signal is actually much better here, since I haven't looked at their protocol. They hyped their Sealed Sender feature as a solution to some of this, but it can't really protect from nosy server admins who are able to alter the code, and they fundamentally cannot hide network-level meta-data like who is talking with whom. There's a brief and pretty accessible description of why in the video accompanying this paper.
I don't have a list of Matrix events that remain unencrypted in encrypted rooms. You could read the spec to find them if you're motivated enough to slog through it, but be warned that network protocol specs tend to be long and boring. :) Unfortunately, the few easy-to-digest blog posts about it that I've encountered have been both alarmist and inaccurate on important points (one widely circulated one was so bad that the author even retracted it), so not very useful for getting an objective view of the issue.
However, the maintainers have publicly acknowledged the issue as something they want to fix, both in online forums and in bug reports like this one:
Not exactly. Many of the big instances have Cloudflare (or similar) sitting between you and the server, providing the HTTPS layer while watching everything you read and write on Lemmy. In cryptography circles, we call this a man-in-the-middle.
Your instance (sh.itjust.works) is one such instance, by the way, as is lemmy.world.