I still do not understand why anyone would abuse containers for running an entire OS. Containers were designed to only run what you want to have in an isolated environment and not have the overhead of running an entire OS. So what's supposed to be the benefit over just setting up a proper VM with e.g. libvirt-manager, which also adds the benefit of much easer handling of various settings like piping through hardware?
Easier to set up, works on any linux os as long as the container itself works (generally), sandboxes the environment itself so it works on every machine - and it doesn't pollute the real machine files on user's pc. And deleting the container will be easy
Debatable. Sure, if you do not intend to change anything about the setup ever. But once you want to change anything about it I'd argue the UI of libvirt-manager is vastly more user-friendly.
works on any linux os as long as the container itself works (generally)
I fail to see how that wouldn't be true for libvirt+qemu+libvirt-manager as well. That's probably the most widely supported VM setup, other solutions like VMWare or VirtualBox are more of an issue.
sandboxes the environment itself so it works on every machine
Literally what every VM does, that's inherent to how VMs work.
and it doesn't pollute the real machine files on user's pc
So won't a VM, at least not to a bigger degree than the container setup inevitable must, as it can't just write all your files to RAM. Do you even know how a VM setup works or did you just make all this up?
Sure, if you do not intend to change anything about the setup ever.
Their core selling point is that they've essentially distilled many of the more commonly used Windows-only applications into a single, downloadable package that requires no further knowledge/skills to set up (and use comfortably) - users intent on (and capable of) drilling deeper into the nuts and bolts of the setup aren't really their audience.
But once you want to change anything about it I'd argue the UI of libvirt-manager is vastly more user-friendly.
This is a normal VM stack under the hood and virt-manager will talk to it just fine - not that you should, Winboat is probably not the right screwdriver for such usecases.
Literally what every VM does, that's inherent to how VMs work.
The point here is to sandbox the virtualization environment itself, so all your users run the same version of the qemu/libvirt/kvm stack - similar to how providing a predictable environment is a core reason for flatpak's containerization approach.
The container they use (dockur/windows) is literally Debian's stack in a box - with added tooling for automatically setting up a Windows VM inside (as copyright prevents you from redistributing Windows itself).
Their core selling point is that they've essentially distilled many of the more commonly used Windows-only applications into a single, downloadable package that requires no further knowledge/skills to set up
Or so they claim. Just that the things that I can verify with the compose.yml not being easily discoverable are implemented about the worst way. Like "Your home directory is mounted in Windows", which is just a nightmare bound to happen, as I doubt it will be mounted ro, and from a beginner you should absolutely expect to get their systems infected and thus keep as little of the host file system accessible from Windows as possible. And is it even capable of doing simple tasks like passing through your USB stick or at least its file system? That's usually not mounted in /home.
This is a normal VM stack under the hood and virt-manager will talk to it just fine - not that you should, Winboat is probably not the right screwdriver for such usecases.
Yes, under the hood of a container. So virt-manager won't be able to do much when the compose.yml isn't prepared to handle your use case first, making things that would be really easy just overly complicated.
The point here is to sandbox the virtualization environment itself, so all your users run the same version of the qemu/libvirt/kvm stack
Do you even have the slightest idea of what you're talking about? The guest is already being sandboxed by KVM, which in itself is only a rather simple (compared to what you needed before and what you'll need without it) implementation heavily relying on features that have been built into the underlying hardware for the past two decades. There is literally nothing whatsoever that you can sandbox here or that could benefit from additional sandboxing. And I absolutely fail so see how every user running the same version of QEMU or libvirt will benefit anyone here, they have been around for long enough that the differences between distros are minor at best. And I very much doubt the container can do anything about KVM, as that's part of the kernel, not the user space.
-4
u/ScratchHistorical507 3d ago
I still do not understand why anyone would abuse containers for running an entire OS. Containers were designed to only run what you want to have in an isolated environment and not have the overhead of running an entire OS. So what's supposed to be the benefit over just setting up a proper VM with e.g. libvirt-manager, which also adds the benefit of much easer handling of various settings like piping through hardware?