I wonder how much more surveillance they can feasibly justify to prevent remote access to new secure phones from old, insecure, non-compliant devices used by Elucalidavah and other un-American activists.
All maps need to have an extra time penalty for turns, merging, etc. Even if the data is taken with an average driver, average driver probably isn't there for the first time, and for someone unfamiliar with the area any extra turn adds an extra chance to take a wrong turn.
It's amazing how bad this is in the Bay area. I wonder how map engineers don't dogfood. Or what is it that prevents them from making the maps better? They sure have no problem making changes that make maps worse.
> its a system design issue or system availability issue on the client side
If all events need to arrive, then the problem is not "notification" (which would be solved by webhooks) but "database replication": subscribe to new events, fetch the full snapshot, fetch the updates in range, have the monotonic value to establish the "range" in the first place. Reach the eventual consistency.
The proposed SCROLL handles half of these, which limits its use-cases.
Arguably, that's exactly the one action that will need to be hash-pinned, since all the consecutive actions will at least be verified against the lockfile.
Thanks to this post, I checked my ultrasonic filled with tap water. With it running all night in a bedroom with an open door, morning pm2.5 readings are ~30 and the meter is in the kitchen.
If you have a privilege to replace the kernel or bootloader, you effectively have all privileges on that system. Therefore, there's no need to complicate the access limitations when you get full access anyway.
It was involved in the previous one, but not in this latest one. All FL2 did was prevent the outage being even wider spread than it was. None of this had anything to do with migration.
If FL2 didn't have the outage, and FL1 did, the pace of the migration did have an impact.
Though this is showing the problem with these things: Migrating faster could have reduced the impact of this outage, while increasing the impact of the last outage. Migrating slower could have reduced the impact of the last outage, while increasing the impact of this outage.
This is a hard problem: How fast do you rip old working infrastructure out and risk finding new problems in the new stack, yet, how long do you tolerate shortcomings of the old stack that caused you to build the new stack?
EasyOCR is significantly worse than Tesseract for clean printed text and , while being orders of magnitude slower; far better than Tesseract for low-quality clean scans and extracting text from pictures (e.g. comics), which Tesseract does not as well.
I wonder how feasible is it to use a separate phone and access it remotely from the main phone.
reply