Blanket blocking socketcall() caused regressions for all 32-bit applications trying to make sockets. In theory, glibc disables socketcall when running on kernel version >= 4.3. In practice, Debian/Fedora/Ubuntu all set glibc's "expected kernel version" to 3.2, so socketcall() is still used on most 32-bit glibc binaries shipped.
I don't make any efforts to make mobile devices work, since usually their GPUs and drivers are not good enough for this, but PRs and patches are welcome. At one point Mobile Safari was working.
That Wayland keylogger is not the same thing. X11 has several mechanisms (XTest, XRecord, XI raw inputs) to receive a global raw key input stream, accessible to anyone who connects to the X server, without even making a visible window surface. It even bypasses grabs, meaning that your lock screen password entry can be snooped on.
The Wayland keylogger acts like an application; all Wayland compositors will only send key events to the focused surface, so the user has to focus an active surface in order to get key events. Even in the scenario where you've LD_PRELOAD-hooked all applications, you still will never get the lock screen password, as the compositor never sends it out across the wire.
LD_PRELOAD is problematic from a security perspective, but it's not Wayland-specific: the same issue is true for CLI applications and X11 applications, and any attacker with the ability to write files could also just replace your binaries with malicious ones (stuff them somewhere into ~/.hidden, and then add a $PATH entry to the start).
Most GPU drivers these days are DRM drivers, which implement fbdev support for backwards compatibility only [0]. The fbdev API is primarily "fake" these days.
DRM/KMS using dumb buffers are the preferred API if you want to do software rendering and modesetting. You can find several examples of this online if you search for drm_mode_create_dumb.
The words "virtual machine" and "interpreter" are mostly interchangeable; they both refer to a mechanism to run a computer program not by compiling it to machine code, but to some intermediate "virtual" machine code which will then get run. The terminology is new, but the idea is older, "P-code" was the term we used to use before it fell out of favor.
Sun popularized the term "virtual machine" when marketing Java instead of using "interpreter" or "P-code", both for marketing reasons (VMware had just come on the scene and was making tech headlines), but also to get away from the perception of classic interpreters being slower than native code since Java had a JIT compiler. Just-in-time compilers that compiled to the host's machine code at runtime were well-known in research domains at the time, but were much less popular than the more dominant execution models of "AST interpreter" and "bytecode interpreter".
There might be some gatekeepers that suggest that "interpreter" means AST interpreter (not true for the Python interpreter, for instance), or VM always means JIT compiled (not true for Ruby, which calls its bytecode-based MRI "RubyVM" in a few places), but you can ignore them.
Basis also drops quality on the floor by targeting subsets (ETC1s and UASTC) in hopes of having a "common transcodeable subset". In practice, a number of runtime transcoders seem to just decode to RGBA and then fully re-encode anyway, but on the CPU.
metal-tt/metal-nt require you to specify the exact architecture, and that's not forward-compatible unless you update your application for every new device release. Even minor SKU revisions like applegpu_g13p/applegpu_g13g/applegpu_g13s/applegpu_g13c are different compilation targets, and that doesn't help you when Apple releases applegpu_g14.
Microcode was only used for the RSP, which was a modified MIPS coprocessor and could only realistically be used for T&L. After that, the RSP then sends triangles to the RDP for rasterization, pixel pipeline, and blending, all of which are fixed-function, admittedly with some somewhat flexible color combiner stuff.
Ubershader actually has three different opposite meanings, unfortunately.
The classic usage is a single source shader which is specialized using #define's and compiled down to hundreds of shaders. This is what Christer uses in that blog post above (and Aras does as well in his ubershader blog post)
Dolphin used it to mean a single source shader that used runtime branches to cover all the bases as a fallback while a specialized shader was compiled behind the scenes.
The even more modern usage now is a single source shader that only uses runtime branches to cover all the features, without any specialization behind the scenes, and that's what Dario means here.
It happened all the time. I've played plenty of D3D11 games where clicking to shoot my gun would stutter the first time it happened as it was compiling shaders for the bullet fire particle effects.
Driver caches mean that after everything gets "prewarmed", it won't happen again.
Encryption without authentication is not very useful; if unauthenticated, your ISP could middle-man your connection and effectively decrypt everything while making you think you're encrypted.
If that's not in your threat model, and you want encryption for another purpose, then I could understand that, but currently, protecting the endpoints against malicious attackers in the middle is the big value of TLS.
No, they don't do any of that. There are 100 different blockchain implementations at least, and none of them are standardized across any of those metrics. Everything from the consensus mechanism to the packet format to the bytecode is different. The standard way to interop between the Tezos blockchain and the Polygon blockchain is to create a token on both sides and attach a tag saying "don't touch me I'm actually somewhere else".
The only way to standardize ~all companies would be to have them all run the same exact ledger system, and if it was easy enough to make them do that, it would be easy enough to have them standardize a different reporting system for the same purpose.
The blockchain can't do anything with stablecoins, because that's interfacing with a financial system that's out of the reach of smart contracts. Even if we assume that a stablecoin is backed by real USD sitting in a bank account, there's nothing stopping anyone from just taking money out of the bank account, and the smart contract is none the wiser. You still have to trust someone at the end of the day.
https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/...
https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glib...