BlueAure

Screen is probably broken. You might be able to replace it by buying a replacement screen and following a guide by ifixit. Usually pretty straightforward.

Usually, not adhering to timing recommendations isn't going to damage a circuit. However, it introduces potentially undefined or unpredictable behavior. For example, if you are driving a pump with specific timing requirements to control precisely the amount of fluid passed and you skew the timing a bit. Most of the time it would probably be fine, but there would be the potential that it might pump too much or too little. For a low precision application like a sump that's ok, but for a high precision application like an medication pump it has the potential to kill someone.

At the end of the day, it depends on your tolerance for risk. Manufacturers generally certify their products for the timing on their datasheets. If you operate out of those specs, you are taking the responsibility of what happens.

Don't want to scare anyone off, but it all depends on what you're doing with it. In personal projects, yeah I'll do all kinds of squirrely out of spec shit, but I'd never do that at work cause of potential liability. It's up to you to determine if losing a couple steps on your watering pump will kill anybody or not! :D

I use mergerfs to pool a bunch of varying sized drives and then run snapraid on the whole pool to protect it. Then, I've got Kopia backups running and backup up to a remote repository. This solution has been flexible and I've already been able to recover from 2 drive failures very quickly and easily.

The Yogscast Jingle Jam! They do an annual month long Livestream where they play games and raise money for a variety of charities. Donations of 35 pounds or more also get a whole bevy of game keys as part of the collection that can be redeemed on steam. You can see the list of games or donate at jinglejam.tiltify.com

Less biased than some other media sources I've seen and makes it more likely that I'll read it. Since the opinions are clearly marked it's possible to skip them as well and just read the facts as presented. I just keep it in mind as I read and it works for me.

I recently found out about Axios which does short bullet point coverage of just the interesting/most important parts of stories. It seems to be a bit biased liberal overall, but being able to get the highlights without wasting time reading all the fluff is pretty convenient.

It's the best one that I've found since the old ES File Explorer sold out and became adware

AndrOBD for connecting to my car OBD2 Bluetooth adapter. It lets you read any diagnostic codes and let's you reset warning lights.

Aegis for managing 2FA tokens. Weawow for weather. MiXplorer for file management.

Purdue University still has a campus-only file sharing network called DTella that's DC++. It been getting smaller, but there were a few members that shared 50+ TB at one point.

Assuming that there is at least some amount of slippage between the wheel and ground, it seems to me that you'll need to regularly check the ToF sensors anyway. I've found that encoders are fantastic for a lot of things, but not so much for measuring distance because of the problems you've described. Perhaps a recurring local check on a reduced set of points to verify location then forward the full cloud less often for further remote processing? It really sounds like you have a tradeoff depending on whether you value accuracy of location or accuracy of wheel rpm (analogous to speed). Using both would give you a nice way to calculate the ideal motor rpm to minimize slippage in a surface agnostic way.