That is not true. Many attacks (e.g. the recently revealed Operation Triangulation) do not have persistence.

Alright, tried to give it a go but I encountered the same build issues that are filling up the issues tracker. I tried making the same changes locally that are in the PR and that didn’t work. Given that it seems like this isn’t being maintained, and relies on deno which I guess is making breaking API changes, I’m going to pass on peek.

Thanks! I’ll give peek a try and report back.

For me, once Apollo officially stops working I won’t have any ingrained habit for reaching out to reddit. I stopped using the website years ago except for reading search results that point there.

I’ll admit I’m not the biggest FOSS evangelist, so this comes with a grain of salt. From a right to repair standpoint, I don’t care for Apple’s policies at all. But from a security and (perhaps counterintuitively) user experience standpoint, I agree with Apple’s walled garden approach, locked down OS, and single app store. We see the alternatives in Android, and we see how much worse its security is.

I bought Gloomhaven right at the beginning of the pandemic, and my roommates and I spent basically that whole summer playing together. We still keep in touch by playing the digital version as our schedule allows. So that one has a special place in my heart.

I don’t, but a coworker uses an ergodox and I’ve been eyeing it lately

Yes it is. While I’d heard of Mastodon in the context of Elon’s Twitter dumpster fire, I had no idea it was federated or what the fediverse was. I like it so far, with the obvious caveats that there’s plenty of room for improvement. I’m hoping to learn more about how the platform works technically so that I can contribute a bit.

Current place:

• Work is done on a feature branch on a personal fork of the repo
• Codebase requires 100% functional coverage, and you’re responsible for writing the tests for your code and including that in the same PR
• Run pre-commit hooks for style auto-formatters before you can commit and push your code to your origin fork
• Ideally run local tests as well
• Create a PR to pull feature branch into the upstream repo’s main branch, which triggers the CI pipeline for style and tests
• At least 1 other person must review the code before a PR can be approved and merged into upstream main
• There’s a separate CI pipeline for testing of publishing the packages to TestPyPI
• Releases to PyPI are currently done manually

I’d be happy to help contribute as best I can. I don’t have much Rust experience but I’d like to learn more. One thing I’m noticing: I like that there are a good deal good first issue tags for the backend repo, but only one for the frontend. I’m not sure if there’s really that far fewer intro tasks for the frontend or if they’re just not tagged as thoroughly.