You're juggling a dozen dependencies, some of which are closed-source binaries, some are blackbox replacements, and each game or application is a special snowflake requiring very specific versions of these (and perhaps some tweaks here and there).
It's worth emphasizing every time this subject rolls around just how impressive Microsoft's commitment to backwards compatibility in Windows really is.
This is WINE (not an emulator). Constrained by the design of Windows. Cannot fix that underlying problem. The resource cost is only tens of megabytes of storage and it provides clean isolation. It's not an entire copy of the OS. It's mostly just configuration.
Also since when were containers more “bloated” than emulation? The whole point of containers is that they don’t need to virtualise the entire stack because they are reusing parts of the host stack.
The Wine documentation admits that it is emulating the Windows API.
https://wiki.winehq.org/Wine_Developer%27s_Guide/Architectur...
Of course there is no hardware emulation, so all Windows binary code is running natively with no performance drop. That's why it was called WINE. But still there are two meanings of the word. Hardware emulation or OS emulation at API level.
In the context of computers, “emulation” has a specific meaning and one which isn’t applicable to WINE.
Right. But one example doesn’t mean the entire world of containers is “bloat and unnecessary”.
I’ve encountered many use cases where packaging dependencies and deployments become significantly simpler due to containers.
True that there are possibly several other solutions that also solve similar problems. But that doesn’t mean containers don’t also solve actual problems.
Not least because you don't even need to run the container at all when developing.
Seems fair to me.
it's the same overhead/bloat as launching any normal process in the default cgroup and contexts.
> ... wrapped in a docker container because the developer loves docker
I think you maybe don't love Docker and that's coloring some things for you, unjustly.
That said, it is hardly a "bloat".
On one hand, a docker container will include duplicates of libraries, many versions, and sometimes unnecessary stuff.
On the other hand, I can run a lot of software on my machine by running a single command, without installing tools and libraries in my system I won't ever use again, and I can, with reasonable confidence, get rid of everything with another.
A lot of people prefer wasted disk space, and potentially memory and cycles, to wasted time and patience.
Docker method is supported. Non-Docker method is available but unsupported, at your own risk.
It reduces the community support load. Eliminates massive amounts of wasted time dealing with distro specific configuration issues. These are volunteers who have better things to do with their spare time than debug that pointless soul destroying shit that Docker eliminates.
Why would defining the runtime dependencies needed for the execution environment of the software ever be a bad thing? Unless it's a statically linked binary as the final artifact I can't come up with a reason the stuff you ripped out would be anything but useful. Directly, or as executable documentation.
Here the reward for the developer is not needing to debug your operating system installation, because the container specifies what, as far as the application can see, is the operating system installation. Your reward is an application that has been tested in the environment it is running in.
DOSBox also has similar front-ends that can start Doom with a Sound Blaster 16 but Duke Nukem with a Sound Canvas by applying different configuration files.
Why fix underlying problems when you can just put things in a bottle/container? Like that won’t use more resources.