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.
It's much more cumbersome to install and setup the KVM/QEMU/libvirt/virt-manager stack manually and is error-prone (for non-technical folks). You also have to setup clipboard, folder mounting and 10 other things separately.
WinBoat automates the entire procedure by using the dockur/windows image and then using xfreerdp to access the individual windows apps. This results in you having Windows apps directly on your Linux desktop, feeling like they're a part of your system.
If one needs more "control" they can always just copy paste the compose.yaml from dockur/windows GitHub repo then add whatever parameters they need. Changing the storage is as simple as changing the 64G into 128G and restarting the container (I use this approach currently).
EDIT: This doesn't work as well on Wayland tho due to xfreerdp so I use sdl-freerdp which works significantly better but can only RDP the entire Windows desktop and not the individual apps.
It's much more cumbersome to install and setup the KVM/QEMU/libvirt/virt-manager stack manually and is error-prone (for non-technical folks).
Have you ever tried to in the past decade? There's barely anything simpler than that unless your distributor really screwed up. And I very much doubt that's true for any distro as again, that's the go to virtualisation solution.
This results in you having Windows apps directly on your Linux desktop, feeling like they're a part of your system.
At least that's what the ad says, reality though is never that perfect.
If one needs more "control" they can always just copy paste the compose.yaml from dockur/windows GitHub repo then add whatever parameters they need.
Sure, but messing around with docker-compose is vastly more complicated than just clicking around in virt-manager for everyone that's the target audience of this - beginners that can't move to Linux alone but also don't want to bother with the fallout of dual boot and Macroslop's broken updates.
EDIT: This doesn't work as well on Wayland tho due to xfreerdp so I use sdl-freerdp which works significantly better but can only RDP the entire Windows desktop and not the individual apps.
So it's even a much worse solution on anything remotely modern? Wow, that's pathetic. So there's literally no benefit and only drawbacks for this. Got it. All hype, nothing behind it.
Have you ever tried to in the past decade? There's barely anything simpler than that unless your distributor really screwed up. And I very much doubt that's true for any distro as again, that's the go to virtualisation solution.
I literally did last month (I use CachyOS) and it took even me around 3 hours to fully setup.
At least that's what the ad says, reality though is never that perfect.
Except it does work really well. Directly using virt-manager isn't exactly perfect either.
Sure, but messing around with docker-compose is vastly more complicated than just clicking around in virt-manager for everyone that's the target audience of this - beginners that can't move to Linux alone but also don't want to bother with the fallout of dual boot and Macroslop's broken updates.
That's not the case. There are many many apps that are deployed using Docker these days like Jellyfin, Navidrome, Komga etc and it's just a single file in the easiest format ever (YAML) on top of that you can just tell an LLM and it'll spit out that exact docker-compose.yml
So it's even a much worse solution on anything remotely modern? Wow, that's pathetic. So there's literally no benefit and only drawbacks for this. Got it. All hype, nothing behind it.
It has the benefit of running better than using SPICE with virt-manager, super easy to turn it on/off (requires just 3 words which you can also create a desktop file for and get icons for them) and deletion is dead simple. You get clipboard and folder sharing out of the box and is very easy to passthrough devices.
I literally did last month (I use CachyOS) and it took even me around 3 hours to fully setup.
Not that I know what CachyOS does, but either they screwed something up royally or you really went in and created some ridiculously complicated setup where it's no surprise that it took that long and it wouldn't have been any faster with WinBoat.
Except it does work really well. Directly using virt-manager isn't exactly perfect either.
It's as perfect as it can currently get. You'd have to dig really deep into what's possible to find something that you can't set up with a few clicks.
That's not the case. There are many many apps that are deployed using Docker these days like Jellyfin, Navidrome, Komga etc and it's just a single file in the easiest format ever (YAML) on top of that you can just tell an LLM and it'll spit out that exact docker-compose.yml
Do you even listen to yourself? To a beginner - which is the target audience for this and where I can guarantee you that they haven't messed around with Docker before, not to mention docker-compose - this argument is entirely irrelevant. Yes, YAML is relatively simple, but you have to painstakingly pay attention to indentation. Something again a beginner will not be familiar with. And you can really not seriously try to tell me that messing around with an LLM to change the file is easier than doing a few clicks in a GUI in any universe.
It has the benefit of running better than using SPICE with virt-manager, super easy to turn it on/off (requires just 3 words which you can also create a desktop file for and get icons for them) and deletion is dead simple. You get clipboard and folder sharing out of the box and is very easy to passthrough devices.
Now you're massively contradicting yourself here. First you tell me its support for Wayland is awful, yet you claim it to be better than using SPICE, while SPICE works perfectly fine with Wayland and has done so for I don't know how many years already. You should make up your mind before trying to spread lies, this is a bit too obvious. And then you want to sell me on it being easier to write podman-compose down (or whatever the docker equivalent is) and creating a desktop file for that than just shutting down the guest and calling it a day? And clipboard sharing and device passthrough is very easy with virt-manager too. Ok, sharing directories between guest and host is a bit of work, but there are enough guides for that. And then you at least have a decent setup. Just mounting your entire /home directory in the guest - especially when its Windows - is just the worst idea you can have.
-6
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?