They don't advertise themselves as such, for obvious reasons, but there is at least one online CPAP dealer in the US that will sell to you without prescription verification. (Why should I wait 3 months for an appointment, drive an hour round trip, and $50 copay, to renew my rx so I can buy more masks, which wear out after a year or two?)
I don't know who will do it without any kind of prescription, but it's pretty trivial to get an at-home test from someone like 1800cpap and they'll write a prescription based on the results. I bet they have a nearly 100% rate of writing prescriptions, given the obvious conflict of interest.
> I bet they have a nearly 100% rate of writing prescriptions, given the obvious conflict of interest.
Even if they are honest I'd expect near 100% - people who don't expect they have issues are not going to be getting the at home test in the first place.
> The component model is addressing this but it's sprawled out into literally rebuilding "worlds" and turning wasm modules into sort of lightweight virtual machines. I wish there was just more of a focus on getting data into and out of modules first.
As someone who works on the Component Model, this perception is interesting to me, can you explain your thinking a bit more? From my perspective, getting data in and out of modules is indeed solved. Worlds are a type signature that describe what datatypes and methods are available in a particular embedding, with standards for command line and http proxies, but easy to define whatever your situation requires.
As someone who wanted to try to use WASM ~1yr ago, I was unable to find any reasonable way to get data in/out of wasm from the local environment, and gave up on trying to learn it because of this.
Could you please provide links/info for how to do so? I want to be able to learn how to use it, but without this ability it seems entirely useless for me.
Yep, this is one of the initial motivations for creating Extism: https://github.com/extism/extism -- and it works across 16 host languages & 8 guest languages.
WASI Co-chair here: WASI is for the Web as well as beyond. The jco project (https://github.com/BytecodeAlliance/jco) provides an implementation of the Component Model and WASI Preview 2 for JavaScript systems. Right now, node.js support is complete, but support for Web embeddings is in progress and coming soon.
We have already made big improvements in using SpiderMonkey on WASM, and have more work in progress that will enable SpiderMonkey to have "native"-like codegen for WASM: https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/
An additional benefit of using a fast JS runtime inside of WASM, even on a WASM engine that natively supports JS, is to use a Wasm Component as a security boundary around JS code. This could be used as an means of isolating supply-chain security issues, or allowing users to provide (untrusted) JS code that extends an existing system while having a clear and strong boundary on how untrusted JS code can affect the host JS code.
> WASI-Preview2's benefits are not going to be realized in a browser, it's more for the non-web world
The jco project (https://github.com/BytecodeAlliance/jco) provides an implementation of the Component Model and WASI Preview 2 for JavaScript systems. Right now, node.js support is complete, but support for Web embeddings is in progress and coming soon.
> These interpreted languages can run in WASM, but only as language interpreter inside the WASM interpreter - so they work, but they are not efficient.
The Bytecode Alliance has made big improvements to SpiderMonkey performance on WASM/WASI systems, and has work in progress to take advantage of SpiderMonkey's "native" codegen targeting WASM: https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/. We targeted JS first for this work because it is the most popular language with our customers and users, but we expect that this will show the path to adding similar improvements to Ruby, Python, and other languages commonly thought of as "interpreted".
WASI Co-chair here. Nothing in WASI is "somehow blocked by Google", or indeed blocked by anyone at all. Graphics support in WASI hasn't been developed simply because nobody has put energy into developing graphics support in WASI.
At the end of 2023 we counted around 40 contributors who have been working on WASI specifications and implementations: https://github.com/WebAssembly/meetings/blob/main/wasi/2023/... . That is a great growth for our project from a few years ago when that issue was filed, but as you can see from what people are working on, its all much more foundational pieces than a graphics interface. Also, if you look at who is employing those contributors, its largely vendors who are interested in WASI in the context of serverless. That doesn't mean WASI is limited to only serverless, but that has been the focus from contributors so far.
By rolling out WASI on top of the WASM Component Model we have built a sound foundation for creating WASI proposals that support more problem domains, such as embedded systems (@mc_woods and his colleagues are helping with this), or graphics if someone is interested in putting in the work. Our guide to how to create proposals is found here: https://github.com/WebAssembly/WASI/blob/main/Contributing.m... .
The component model is already shipping in Wasmtime, and will be stable for use in Node.js and in browsers via jco (https://github.com/bytecodealliance/jco) soon. WASI Preview 2 will be done in December or January, giving component model users a stable set of interfaces to use for scheduling, streams, and higher level functionality like stdio, filesystem, sockets, and http on an opt-in basis. You should look at wit-bindgen (https://github.com/bytecodealliance/wit-bindgen) to see some of the languages currently supported, and more that will be mature enough to use very soon (https://github.com/bytecodealliance/componentize-py)
Right now jco will automatically generate the JS glue code which implements a Component Model runtime on top of the JS engine's existing WebAssembly implementation. So, yes, Components are a composition of Wasm Modules and JS code is handling passing values from one module/instance to another. You still get the performance benefits of running computation in Wasm.
One day further down the standardization road, we would like to see Web engines ship a native implementation of the Component Model, which might be able to make certain optimizations that the JS implementation cannot. Until then you can consider jco a polyfill for a native implementation, and it still gives you the power to compose isolated programs written in many languages and run them in many different contexts, including the Web.
(Disclosure: I am co-chair of WASI, Wasmtime maintainer, implemented many parts of WASI/CM)
Hm, ok so it seems there has finally been progress since I stopped looking (around a year ago, I was very actively following developments for a couple of years before that but got tired). I will check wit-bindgen and jco and see if I can finally make my little compiler emit code that can be called from other languages and vice versa without myself generating any JS glue code.
