My understanding is that just offering a request object with lazy accessors would solve this issue, although the accessor itself would have some overhead in repeat accesses.

> Elysia has two special optimizations for response mapping functions: mapResponse and mapCompactResponse.

This section feels a bit abstract - some transformation examples would be nice.

Sure, if they don't make it everybody else's problem. Not to defend MS too hard, but they supported Windows XP with security updates for 18 years. At some point software needs to be "finished", and once it is, all responsability falls upon the user.

The enterprises with competent IT that will airgap their XP machines to keep running the control plane for their factory probably "know better" than MS, the power user who refuses to use a Linux distro for their Pentium 3 box or who will disable Windows Defender and run random scripts on the internet to "debloat the OS" without understanding it, or the ones who run LTSC and then complain that their games aren't working - they all absolutely don't know better, but unfortunately they tend to be the louder voices in the conversation.

By comparison, WASM is really more like traditional assembly, only running inside a sandbox.

Besides running on a weaker CPU, IOS can access (for exclusive use) some of the main system memory, but it was usually about 12-16MB to not starve the actual games running on the main CPU (https://wiibrew.org/wiki/Memory_map), which can help explain why everything except for the actual games was so slow.

Originally, code running on the main PPC CPU could not access directly most of the IO related hardware at all (only GPU/display output and wired controllers - the bluetooth stack was also on IOS AFAIK, but the Wiimote drivers themselves were userspace), so even the Linux ports had to "proxy" some hardware access through the IOS, but later after reverse-engineering the full boot process, people were able to create a replacement IOS that could enable full access through a special register: https://wiibrew.org/wiki/MINI, enabling full-speed Linux ports, and since that functionality is about a decade old now, I would guess that the NetBSD port also takes advantage of that.

Although, from reading the Foundation DB docs and checking the Deno KV API, I honestly suspect it is a thin layer.

Self-hosting FDB is somewhat inscrutable though, so their value add is in not having to handle infrastructure while being backed by FDB.

SQL is low hanging fruit in this regard, because you just need to standardize the lowest common denominator flavors of SQL types for deserialization and then it's just juggling SQL queries around.

JDBC for Java does the same as database/sql and it's from 1997. ODBC is from 1992.

I hope Oracle will let it drip it down to the CE, but it's their project, their monetization strategy.

No, vfio is still the most recommended option.

This is essentially something like VirtualBox or VMWare 3D acceleration - the host is still the "owner" of the GPU, and has to juggle receiving OpenGL commands from the guest and sending the render results back to it, with lots of overhead. But easier for users than setting up passthrough or using proprietary GPU virtualization solutions.

People pointed out that there is a similar project for Vulkan, already being used in production for ChromeOS, called Venus. Should be the one to watch nowadays.

I don't know much about R, but if it considers the whole memory space of the R process, it probably counted the memory consumption of the libraries themselves as well.

Still, the fact that Corretto 11 had so few backports is encouraging.