If I get some time to circle back, I'll be sure to incorporate these into some new tests and address them.
I want to set up a qemu-system emulator based testing approach so I can incorporate things like AppArmor and SELinux into end to end tests that include different environment configurations.
Part of that will be setting up software defined networking so I can have things like DNS and wireguard VPN servers in a box and then test and evaluate the wg-wrap behavior at the packet level.
You have to apply a lot of careful architecture and TDD to your approach. Eliminate technical risk by tackling hard things early and wrapping them up in a simple, easy to use interface.
I find I can get some projects done 2-3 times faster than if I wrote them by hand. It can also save about 5-10x time on mundane or broadly scoped projects by helping me consolidate and try out ideas very quickly.
Setup-wise, I switch between vLLM using nvidia/Gemma-4-31B-IT-NVFP4 and llama.cpp using unsloth/gemma-4-31B-it-qat-GGUF with MTP. I throttle the GPU power usage to 400W.
My current llama.cpp setup gets token generation rates between 60-150 t/s depending on MTP draft acceptance rates. Prefill is between 1500-4000 t/s depending on context length/depth.
The container is a Linux container running a virtual machine inside.
WinApps needs a Windows RDP server to work. Most of the functionality doesn't care where that Windows RDP server is actually running as long as its FreeRDP client can connect to it. The container or libvirt VM options are just ways to accomplish that via virtualization.
I imagine the container part makes it easier to automate QEMU virtualization using bash scripting without worrying about distribution specific differences in the environment. These kinds of scripts become fairly ossified to their environment. Making them run consistently on different Linux distributions is its own adventure unrelated to installing and running Windows, so the containerization eliminates the need for a lot more bash scripting to account for those differences.
The container's bash scripts download the Windows installer ISOs and run them in an unattended mode inside a QEMU VM. The unattended installation is configured to skip activation:
Once the container is running, WinApps configures RDP via some scripts and registry settings exposed into the container via a volume so the container's scripts can copy and run them in the Windows VM:
I haven't seen any of this before, but I think it's a pretty clever use of scripting and containers on top of some fairly mature but hard to use pieces of software.
Browsers implement what they call the "same-origin policy" as a cross-site scripting prevention measure. This prevents you from using XMLHttpRequest calls on other hostnames/ports, which effectively means if you're making a static website on a host with no API endpoints, your website can't interact with any backend services. As a result, you can't save or load data from a server-side database or do a lot of other operations that traditional web applications can do.
There's pre-CORS workarounds. You could build an HTML multipart/form-data POST form inside an iframe and submit it with JavaScript for example. And if the server API supports JSONP, you can inject a script tag into your page that loads the target content as a script which then executes the data in a callback to read it back into the client page.
If you don't care about REST, and you only need to do GET/POST requests with a limited set of mime types, you could make a client-side application that gets around the same-origin policy without using CORS. But it's ugly.
With CORS though, you can potentially make any type of request across origins, because the CORS preflight OPTION requests allow a server to specify what request methods and what headers a client from a certain origin can access at a given URI. And these days, you can find CORS-enabled third-party REST APIs that you can use with things like client-side OAuth to provide all the same functionality that you would have in a traditional web applications.
I've been thinking about using a completely split API/client-side app architecture in my own projects lately, because scaling a bare API is much easier and cheaper than scaling a web application.
So yes, CORS is just a security measure, but it gives you more functionality in a client-side application by allowing you to bypass an older security measure, the same-origin policy, in a very clean and explicit way.
If I get some time to circle back, I'll be sure to incorporate these into some new tests and address them.
I want to set up a qemu-system emulator based testing approach so I can incorporate things like AppArmor and SELinux into end to end tests that include different environment configurations.
Part of that will be setting up software defined networking so I can have things like DNS and wireguard VPN servers in a box and then test and evaluate the wg-wrap behavior at the packet level.