The thing about WINE is that it's not necessarily solid enough to rely on at work. You never know when the next software upgrade will break something that used to work.
That's always true, of course. But, compared to other options, relying on WINE increases the chances of it happening by an amount that someone could be forgiven for thinking isn't acceptable.
In my mind, I almost feel like the opposite is true. Wine is getting better and better, especially with the amount of resources that Valve is putting into it.
If you want a stable, repeatable way to wrangle a Windows tool: Wine is it. It's easy to deploy and repeat, requires no licenses, and has consistent behavior every time (unless you upgrade your Wine version or something). Great integration with Linux. No Windows Updates are going to come in and wreck your systems. No licensing, no IT issues, no active directory requirements, no forced reboots.
You can fix this issue by using a wine "bottle manager" like... Bottles. This allows you to easily manage multiple instances of wine installations (like having multiple windows installations) with better and easy to use tooling around it. More importantly, it also allows you to select across many system agnostic versions of wine that won't be upgraded automatically thus reducing the possibility of something that you rely breaking on you.
If your at work, it's probably a Windows shop. Use windows. At home you can chance a bad update, and probably also have access to windows. Can always use a VM, wine is great in some cases, like WSL. Both don't meet every use case.
why bring wine into a vm discussion? just run windows in a vm too. problem solved without entering the whining about wine not being better than windows itself
I work in embedded systems. In that space, it's pretty common to need some vendor-provided tool that's Windows-only. I often need to automate that tool, maybe as part of a CI/CD pipeline or something.
If I were to do it with a Windows VM, I'd need to:
1. Create the VM image and figure out how to build/deploy it.
2. Sort out the Windows licensing concerns.
3. Figure out how to launch my tool (maybe put an SSH server into the VM).
4. Figure out how to share the filesystem (maybe rsync-on-SSH? Or an SMB fileshare?).
If I do it with Wine instead, all I need to do is:
1. Install some pinned version of Wine.
2. Install my tool into Wine.
3. Run it directly.
bunderbunder|9 months ago
That's always true, of course. But, compared to other options, relying on WINE increases the chances of it happening by an amount that someone could be forgiven for thinking isn't acceptable.
nrclark|9 months ago
If you want a stable, repeatable way to wrangle a Windows tool: Wine is it. It's easy to deploy and repeat, requires no licenses, and has consistent behavior every time (unless you upgrade your Wine version or something). Great integration with Linux. No Windows Updates are going to come in and wreck your systems. No licensing, no IT issues, no active directory requirements, no forced reboots.
amlib|9 months ago
realusername|9 months ago
the__alchemist|9 months ago
damion6|9 months ago
russfink|9 months ago
skyyler|9 months ago
xxpor|9 months ago
1oooqooq|9 months ago
nrclark|9 months ago
If I were to do it with a Windows VM, I'd need to:
If I do it with Wine instead, all I need to do is: