So great that they worked on it! It seemed to be part of the arti work for a couple of years but I wasn't sure it was really on the roadmap. Wanted to do something like this since 2017 with smoltcp and also had a glued together version of it via badvpn/tun2socks (large DNS responses were broken though).
What's truly missing for Wasm and WASI to be an alternative to POSIX is dynamic instatiation so that a Wasm program/component can start another Wasm program/component by providing the bytecode at runtime. So far I don't think anyone is working on that.
if the host provides the guest wasm module via imports a function to create and run from an array of bytes then it can be done today (if I understand you correctly).
Yes, this can be done today, though it needs some gluing together. On the Web (and in Node etc.) you can use JavaScript to create and link the modules, which is how dynamic linking support for wasm works there:
Many apps depend on running an "official" Android distro from Google, Samsung, etc. and don't work with Waydroid's Lineage-based distro. I think the Wine-like approach from https://gitlab.com/android_translation_layer/android_transla... might help to trick apps into believing that they run on an "official" Android distro.
There is a set of specific APIs you have to simulate to trick apps like this. On “real” Android, such simulation is done with things like Magisk modules (which mock certain things) or microG (which reimplementats Google services as a whole). The Wine-like approach used in ATL is certainly more straightforward for simulating APIs, but it’s still needs to be reimplemented specifically for ATL. Waydroid, on the other hand, can probably reuse Magisk or microG, since it’s running a whole Android setup.
There was also the similar project Kerla¹ but development stalled. Recently people argued that instead of focusing on Rust-for-Linux it would be easier to create a drop-in replacement like these two. I wonder if there are enough people interested to make this happen as a sustained project.
> Recently people argued that instead of focusing on Rust-for-Linux it would be easier to create a drop-in replacement like these two
I guess it depends on what they mean by "easy". Certainly it's easier in the sense that you can just write code all day long, and not have to deal with the politics about Rust inside Linux, or deal with all the existing C interfaces, finding ways to wrap them in Rust in good, useful ways that leverage Rust's strengths but don't make it harder to evolve those C interfaces without trouble on the Rust side.
But the bulk of Linux is device drivers. You can build a kernel in Rust (like Asterinas) that can run all of a regular Linux userland without recompilation, and I imagine it's maybe not even that difficult to do so. But Asterinas only runs on x86_64 VMs right now, and won't run on real hardware. Getting to the point where it could -- especially on modern hardware -- might take years. Supporting all the architectures and various bits of hardware that Linux supports could take decades. I suppose limiting themselves to three or four architectures, and only supporting hardware made more recently could cut that down. But still, it's a daunting project.
You can embed attachments in PDFs. This way you could include CSV or JSON files into your PDF report. For a quick way doing it with CLI see `qpdf --help=add-attachment`
A major problem is that one can only have a single connection. It would be nice to do WiFi Direct or AdHoc mode while being connected to an AP. Being able to use WiFi without losing the AP connection (or having a standardized AdHoc channel for discovery) would replace uses of Bluetooth in consumer devices where Bluetooth is used for the initial connection to join a WiFi - some devices rely on WiFi Direct but the UX is very bad because the AP connection gets lost.
Great to see it getting ready. Since the USB-C Power Delivery port doesn't support Display Port output, maybe there is a complex adapter that could splice the HDMI signal in (converted to Display Port) while still supporting data and Power Delivery?
I have been wondering about something similar myself. It seems like each interface on the port boards has a separate internal cable, so even though by default PD is on the left port board and HDMI is on the right it might be possible?
I don't understand what the advantages are over Servo's inbuilt web browser¹. So far they look the same when opening but the inbuilt web browser is more stable (I see rendering bugs with Verso and it panics when entering a domain without the http(s):// prefix).
