Reminds me of when it was smelly as hell in our house a few years ago and when we checked just by chance the roller shutter of one of the windows, we found a dead bird in there which probably got stuck there and was crushed to death.
according to https://nitter.net/onbeeper/status/1733385534545052129 it's only Beeper Cloud they're talking about in the update, they're saying "work continues on Beeper Mini" meaning it's likely not operational yet and users in that thread seem to confirm it
Biased opinion here as I haven't used GNOME since they made the switch to version 3 and I dislike it a lot: the animations are so slow that they demand a good GPU with high vRAM speed to hide that and thus they need to borrow techniques from game/GPU programming to make GNOME more fluid for users with less beefy cards.
You just need more EXP to unlock the Appraisal skill
It's as if you are in an isekai
Double and triple buffering are techniques in GPU rendering (also used in computing, up to double buffering only though as triple buffering is pointless when headless).
Without them, if you want to do some number crunching on your GPU and have your data on the host ("CPU") memory, then you'd basically transfer a chunk of that data from the host to a buffer on the device (GPU) memory and then run your GPU algorithm on it. There's one big issue here: during the memory transfer, your GPU is idle because you're waiting for the copy to finish, so you're wasting precious GPU compute.
So GPU programmers came up with a trick to try to reduce or even hide that latency: double buffering. As the name suggests, the idea is to have not just one but two buffers of the same size allocated on your GPU. Let's call them buffer_0 and buffer_1. The idea is that if your algorithm is iterative, and you have a bunch of chunks on your host memory on which you want to apply that same GPU code, then you could for example at the first iteration take a chunk from host memory and send it to buffer_0, then run your GPU code asynchronously on that buffer. While it's running, your CPU has the control back and it can do something else. Here you prepare immediately for the next iteration, you pick another chunk and send it asynchronously to buffer_1. When the previous asynchronous kernel run is finished, you rerun the same kernel but this time on buffer_1, again asynchronously. Then you copy, asynchronously again, another chunk from the host to buffer_0 this time and you keep swapping the buffers like this for the rest of your loop.
Now some GPU programmers don't want to just compute stuff, they also might want to render stuff on the screen. So what happens when they try to copy from one of those buffers to the screen? It depends, if they copy in a synchronous way, we get the initial latency problem back. If they copy asynchronously, the host->GPU copy and/or the GPU kernel will keep overwriting buffers before they finish rendering on the screen, which will cause tearing.
So those programmers pushed the double buffering idea a bit further: just add an additional buffer to hide the latency from sending stuff to the screen, and that gives us triple buffering. You can guess how this one will work because it's exactly the same principle.
it's possible that you have the IzzyOnDroid repo on your app and the latter automatically picks up the IzzyOnDroid entry once it extracts the "com.akylas.documentscanner" name from the URL
“these bots”: Yeah, you are being an asshole
I'm pretty sure he didn't mean his colleagues and is rather talking about the UiPath bots, it's an IT automation tool... 🤖
If he's a contractor it's unlikely he'll stay there for too long. I'd bring up the improvements and potential gains (faster processing, ideally no more UiPath license costs) directly with your boss. If they're still not open to that then yeah I'd look elsewhere, because even as an IT automation job it just screams laziness.
but some of these processes involve going through Excel files which can take these bots 10s of minutes, which can be done instantly in any scripting language
The key is being proactive. Have you tried suggesting that to them? Do a small POC with say a Python script and show them the difference on one of the Excel files, they're likely to like your alternative. They're likely to have poor data warehousing too and it could be an opportunity for you to shine and at the same time get to learn to do that for them from scratch.
You're maybe referring to this app: https://apt.izzysoft.de/fdroid/index/apk/com.akylas.documentscanner
It's not on the main F-Droid repo (hence the 404), but it's on the IzzyOnDroid repo.
The thread link points to the fixes and enhancements brought by the December update. At the same time there's also a feature drop for Pixel devices, a summary of which you can see below:
For now, Video Boost seems to be exclusive to the Pixel 8 Pro despite it being done on the cloud.
I also compiled the update schedule into a table for those who prefer it this way:
The "(?)" are for when the precise day isn't known yet.
Google now not only acknowledges the bumps that some users noticed but also tries to reassure them that those bumps are nothing to worry about:
Pixel 8 phones have a new display. When the screen is turned off, not in use and in specific lighting conditions, some users may see impressions from components in the device that look like small bumps. There is no functional impact to Pixel 8 performance or durability.
For instance, here's one photo from Google's official Pixel forums:
they obviously have upscalers in their brains