Actually there is support for using WASM as a container runtime. You could in theory have WASM containers and Linux containers next to each other on the same K8s cluster. Not sure that I’d recommend it in production just yet, but it’s certainly usable
I think your comparison to CGI is unfair, since CGI in containers is quite different from "classic" CGI imo.
Wikipedia describes CGI as "In computing, Common Gateway Interface (CGI) is an interface specification that enables web servers to execute an external program, typically to process user requests.[1]
Such programs are often written in a scripting language and are commonly referred to as CGI scripts, but they may include compiled programs.[2]
A typical use case occurs when a web user submits a web form on a web page that uses CGI. The form's data is sent to the web server within an HTTP request with a URL denoting a CGI script. The web server then launches the CGI script in a new computer process, passing the form data to it. The output of the CGI script, usually in the form of HTML, is returned by the script to the Web server, and the server relays it back to the browser as its response to the browser's request.[3]"
Is it possible you don't have direct experience with CGI?
The typical way to deploy CGI during the '90s was to have a compiled program in C/C++, which would be executed once per request. There were entire frameworks built around this "process per request" model, with various optimizations like pre-warming (start the process, connect to db, wait for request on stdin) and variant protocols (SCGI).
Any time you have an execution model based on running a single address space per request, it's fundamentally CGI-ish. It doesn't have anything to do with the implementation language. The limitation of CGI is that state can't be persisted in-process between requests.
---
Going back to the thread, there's multiple aspects when thinking about the structure of a hosted service:
1. Whether state is shared between requests (CGI vs long-lived process).
2. Whether the binary is native code (x86/ARM/) or bytecode (WASM/JVM/).
3. Whether the binary is standalone or comes with additional files.
4. If it needs additional files, whether it's distributed as a package (apt/rpm) or chroot (container image).
Does breaking those different concepts down into a list help? You can see that trying to compare the performance of "WASM deployed as standalone binary with CGI execution model" and "native code deployed in container image" just isn't meaningful. The article is mixing up too many different ideas when trying to benchmark.
I ran PHP in CGI mode a long time ago if that counts :-)
I think what the article is implicitly doing is comparing WASM bytecode running under a container runtime that executes it directly (e.g., without a full chroot). Your point, iiuc, is that there are many variables here, of which x86 vs WASM is only one, and that the benefits here might not be due so much to WASM so much as they are due to the other factors.
I didn't understand where CGI-ness comes into it though, as I don't think there's any difference between this kind of container and any other in terms of the duration or when it's starter up, but perhaps your point is that it's lacking some "full" environment, which makes is akin to CGI? I guess a more accurate comparison would be against an x86 binary being executed with some kind of minimal docker runtime, then? I guess the article could be interpreted generously then as a comparison between a thin docker runtime and a thick docker runtime.
I guess that across the board vendors are experimenting and evaluating the impact of introducing WASM/WASI-based technologies and that may constitute something of a paradigm shift.
On the container side Docker also has native WASM support in a technical preview [0]. I don't think they see WASM as a threat, but rather as an addition to how apps and services can be delivered.
The other day I found an InfoWorld article "Solving the SBOM crisis with WebAssembly Components" [1] that features a diagram on the evolution of Application Development Stacks (by Cosmonic, one early adopter Wasm vendor) that indicates the trend. Idea is to tackle some of the complexity in current infra setups that have become like "Rube Goldberg machines".
Right now most early examples alas boot a container with a wasm runtime for each wasm instance, which is a sad waste. The whole advantage of wasm should be very lightweight low overhead wasm runtime instances atop a common wasm process. Having a process or container for each instance loses a ton of the benefit, makes it not much better than a regular container.
It's still being used to spawn a wasm processes per instance for now, but container runtime project Kuasar is already using the Sandbox API to save significant resources, and has already chimed in in comments on HN to express a desire to have shared-process/multi-wasm-instamxe runtimes, which could indeed allow sub ms spawning that could enable instance per request architectures. https://github.com/kuasar-io/kuasar
Not an expert, but couldn’t the mRNA vaccine target only part of the virus genome that’s stable across mutations/variants? That would give you a broad vaccine resistant to mutations
Stable across mutations? On what timeframe.. Its been stable so far.
However, create a population with narrow immunity based on a single protein, and you create a selection pressure that incentivizes mutations in that protein. Once a successful mutation exists, it has a wide open field to spread unchecked. With broad immunity (multiple proteins) it is much less likely that a variant can realize the multiple simultaneous mutations that would be required to spread effectively.
Regarding SponsorBlock, one of the channels I started watching about a year ago I'd never seen their sponsored segments before.
I had SponsorBlock temporarily off (because some channels get crazily over blocked -- How Ridiculous comes to mind) and realized that their sponsored segments were these short little skits comprised of the couple doing funny voices and wearing minimalist but funny costumes and generally hilarious. Still shilling products but if you have to see some ads that's exactly what you want and I'd missed it because of SponsorBlock!
Right now I’m working on a heads up display using a pair of AR glasses and a pinephone. At the moment you just get the time and a battery level in the corner of your vision, but the interesting thing is the platform. Every hud app is just a Wayland client, and the apps get positioned absolutely on the screen by the compositor
Are the wolves that eat the young and weak who cannot escape from predators "evil"?
The idea that corporations who optimize their costs is evil can be analogous to wolves above.
If you believe that corporations cannot be allowed to do this, then change the rules of "nature". Luckily, this rule of nature is easier to change in a democracy.
Sorry, I wasn’t specific. I was talking about how cImport works in Zig. I didn’t know `zig cc` worked differently.
“ Zig’s @cImport builtin is unique in that it takes in an expression, which can only take in @cInclude, @cDefine, and @cUndef. This works similarly to translate-c, translating C code to Zig under the hood.”
https://ziglearn.org/chapter-4/
GPU passthrough has been a game changer for me. I stream all my games from a computer in a closet running Proxmox. Windows is still there in the background, but I almost never have to interact with it
The game output is pushed out of the GPU exactly as if you were playing on bare metal. Streaming assumes some form of processing and pushing bits down a pipe.
The GPU passthrough is relevant because it means that you don't need to build out a whole machine for just windows to isolate it. Instead you put a GPU in either your server (or your main machine) pass it through to a windows VM and then stream from it (through something like steam big picture, nvdia streaming, sunlight/moonlight, etc) knowing that the only info Microsoft slurps up is gaming related. You can even isolate windows from the internet if your gaming habits don't require it.
https://next.redhat.com/2023/02/01/running-webassembly-workl...