I still haven’t gotten any popups at all on Firefox with uBlock, not sure what’s different about my setup

the PineTime can run for over a week in my experience, but it runs at 64 MHz and has 64kb of RAM, so telling time is pretty much its limit

the only good part of the last one was the mac-'n-cheese-induced divorce flashback, somehow that doesn't give me hope for the future of the series

deleted by creator

the last game I played was Duskers, so I'm probably either immediately dying in the vacuum of space or trapped in a derelict space station without any power.

I know that Calckey and its descendants support it since I verified my account on a Calckey instance, and Akkoma mentions it in this blog post.

ah wack, XWayland then? that should at least stop it from snooping on Wayland apps

It could, so while you're using it you should make sure you don't have anything sensitive onscreen.

If your desktop supports Wayland at all, you could switch to it while using Zoom, even if other things don't work as well, then switch back when you aren't.

If you're using X, it would be able to read your inputs for other applications and such, but if you don't do anything sensitive while it's running it still won't be able to do anything.

If you put zoom in a flatpak and tighten its permissions, it won't be able to touch the rest of your system

My big killer feature for Linux phones is running Wayland/X11 apps mostly unmodified, if AOSP added support for that I wouldn’t be too disappointed about sticking with it. I’ve tried to make android apps before, but doing things the Android Way™ basically requires you to use java and their bespoke UI primitives, and it always makes me wish I could just use the tools I’m already used to.

Being able to have intricate control over my phone is nice, but I’d rather do it with a KDE-like settings maze than a terminal because of how tiny the screen is, and if I’m doing something serious that would require a terminal I would rather do it at my desk.

I definitely think the Android ecosystem has some serious problems, but I already run a custom ROM without Google Play Services installed so I’m fairly well-insulated from that. I do plan on installing a mobile Linux system on my old phone to experiment, but I doubt it will become my system of choice.

You need to use root or pass through some other access control mechanism to control network interfaces or audio devices on Linux too, Android’s access control mechanism for those things just isn’t built with shell scripting in mind because using a terminal on a phone is a pain…

There’s a concept I call “rule zero of cybersecurity”: “the user can and will exploit trust you place in them or anything they can touch.”

You can make it more difficult to exploit the trust you put in the user by hiding it behind obfuscation, but ultimately the user can desolder your secure enclave, reverse engineer your anti-tampering measures, and falsify any check your program wants to do, if it happens on their computer.

Client-side anticheat on Windows doesn’t “work” in the pure sense either, it’s just enough of a pain to bypass that most people don’t because you can’t recompile the kernel to change how it behaves. On Linux, it’s easier to take advantage of the fact that perfect client-side anticheat is fundamentally impossible.

Same with device attestation, DRM, and other client-side verification measures: they’re doomed to be in an endless back-and-forth because what they’re trying to do is fundamentally incompatible with reality.

The correct choice for anti-cheat is to detect cheaters like humans do: watch a player’s actions as they are received by the server, and use your knowledge of typical player patterns to detect if the player is cheating. Your server’s knowledge of the network messages coming from the user’s computer is the only thing you can trust (because it exists on hardware you control), so you should make your decision by analyzing that.