You can do with a static dither pattern (I've done it, and it works well). It's a bit of a trade-off between banding and noise, but at least static stuff stays static and thus easily compressable.
Or more precisely, lukefreed.xyz has NS records pointing to ns[1234].afraid.org, and the DNS servers for _afraid.org_ are subtly misconfigured (one of the six nameservers for afraid.org is evergreen.v6.afraid.org, and since you are trying to look up something in afraid.org but you already trying to resolve afraid.org, you'll need some extra “glue records” as part of the NS response, which is missing for that specific server).
The article specifically points out that this isn't about optimization. A temporary will not be created even with -O0 (you can observe this by putting logging into the copy and move constructors).
It’s not a cargo cult if the actions directly cause cargo to arrive based on well understood mechanics.
Regardless of whether it would be better in some situations to align to 128 bytes, 64 bytes really is the cache line size on all common x86 cpus and it is a good idea to avoid threads modifying the same cacheline.
It indeed isn't, but I've seen my share of systems where nobody checked if cargo arrived. (The code was checked in without any benchmarks done, and after many years, it was found that the macros used were effectively no-ops :-) )
Android and iOS both use filesystem-based disk encryption with fine-grained keys, not only a global encryption key. There's a subset of the OS data available before first unlock to have basic functionality available there. Three examples are installed apps, saved Wi-Fi networks including passwords and alarms with the system clock apps being available before first unlock via explicitly storing it in the before first unlock encrypted data. All of the data and metadata blocks are encrypted, but not all of it is encrypted with keys tied to the user's credentials. Android uses per-profile encryption so it gets security benefits from it too, but both operating systems mainly use it for usability benefits needed to make always on disk encryption suitable for their broad audience. They were able to deploy disk encryption to everyone without complaints partly because they did it this way, so in that sense the before first unlock data has a security benefit.
Apps are installed so that their packages are available before first unlock and can explicitly opt-in to supporting a specific subset of their components and data before available before first unlock. An app can implement push notifications before first unlock if the developers want to do it, and they could do that in a way where no message data, etc. is available before first unlock. The OS leaves it up to apps to decide what to do, and nearly all apps stick with the default of all their functionality and data available After First Unlock instead of either making it available Before First Unlock or having it go back at rest while locked again.
> I certainly don't need or want their rack augmented reality... 'feature'? fad?
I find it mind-boggling that you can hardly buy _RAM_ anymore without programmable RGB LEDs, but that managed switches do not come with a per-port RGB LED to let me mark VLANs or cables that need replacements or whatever. Come on! A nice little square all around the port, please. Instead, we get the QR code plus an app that needs to talk with the cloud.
Yes, if you have special Ubnt-brand cables. And still, I want this to be standard everywhere, not a niche thing from one manufacturer :-) (I know Facebook has some on their 100G switches, too.)
reply