I don't understand any of these "bottle" solutions. All they're doing is running Wine. You can already run Wine without any of this.
I don't understand any of these "bottle" solutions. All they're doing is running Wine. You can already run Wine without any of this.
Bottles has certain sandboxing capabilities on top of wine. Plus, Bottles can download and manage various wine versions, separate from your distro's offerrings. It's pretty neat. Of course, technically, you could do almost everything it offers manually via scripting and your own wrappers, but that can be said about almost any software. Heck, C and C compilers are nothing else than syntax sugar for writing assembly.
To expand on this, at least historically, Wine unfortunately didn't progress in a straight line, often new versions came with additional features or bug fixes which made some applications run or run better, while others ran worse.
Wine can get quite complicated to configure.
It tends to work best when each app has its own isolated wine prefix. This lets you tweak wine settings/params as needed for each app.
This is how I do it for games using Lutris. I have a few games that work best on particular wine versions that won't be able to share the same prefix.
Title made me think of Lutris. I thought Lutris allowed exactly this with a "fancy" launcher UI on top. You have the game you want to run and then it is installed into a per-game WINE prefix.
From my experience, Bottles and Lutris are pretty similar in terms of the overall experience they try to provide. The main difference (at least at the last time I had used each of them) was that Lutris has a lot of flexibility in being able to have third-parties define and publish configs to be usable, whereas Bottles seemed to have more of a "batteries included" approach to having recipes mostly built-in but with the ability to swap out individual pieces manually (e.g. "use this exact distribution of wine, override this DLL with these flags", etc.). I don't recall Lutris having as good support for modifying configs without having to manually modify the JSON recipes, or Bottles having as much support for sharing recipes to be able to automate them rather than manually clicking around in the GUI to make the choices, but it's possible one or both of them has improved in those areas since I last tried them.
Nowadays, I tend to just run pretty much everything through Steam/Proton. I set `Proton-GE` as the default override for all my games, and then "install" things by adding them via the menu for third-party apps in the Steam UI. In the rare cases that I need to tweak something, I use `protontricks` to invoke `winetricks` on the prefix for the game, and things tend to just work after maybe installing 1-2 things at most.
And I can manually create a container with cgroups, namespaces, seccomp, etc...
But I still prefer a management tool on top like docker/podman/rancher.
Having used both manual wine prefixes and Bottles... I quite like Bottles and keep using it.
Your comment has serious "But dropbox is just rsync!" vibes. The ease of use is the point.
And at least Bottles does ease of use without losing too much control, unlike some of the very "game" specific tooling like heroic or lutris.
Bottles is a fancy GUI for Wine that makes it a lot more friendly to many users. It also includes Installers/presets for many software/games that makes it even easier.
When you install multiple apps or games into the same wine prefix, it can get pretty messed up. I haven't tried bottles, but I imagine they make a separate prefix for each app so things dont get cluttered up as much.
By analogy, not to make fun but to clarify, "I don't understand any of these "Chat" solutions. All they're doing is running the LLM. You can already run the LLM through the API without any of this."
It is about convenience. For people willing to leave Windows but not their games, any hurdle taken down, no matter how small, is a win.
Do you also not understand docker? It lets you create separate wine sandboxes with different wine versions, they are isolated from each other, and they are independent of the system-wide wine installation.
Wine prefixes are not sandboxes.
They are not system sandboxes. They are wine sandboxes.
[dead]
It’s all about isolation I think
It is a bad idea to use wine in isolation. Even if it comes with bottles
Its just another iteration of snap, docker, etc. Basically allows you to create a platform independent distribution of a windows app by sacrificing storage space and a little bit of performance.
It has nothing to do or in common with Snap or Docker, it's just a way of making sure windows game/app has the best wine configuration (including libraries) to allow it to run.
Wine bottles are not a software distribution method.
It's an easy way to spin up wine prefixes, and it also installs known working environments for many applications.
In that sense - it's actually incredibly similar to docker/snap. It's isolating the application with all the needed dependencies in it's own prefix, with a nice user experience on top.
It also distributes a large number of things: https://usebottles.com/database
It's not distributing software, it's distributing config files to setup a prefix.
A prefix is no more isolated than a folder and setting an env variable to control library lookup location.
This is in stark contrast to docker/snap which distribute actual software packages and use name spacing for isolation.
What point do you think you're making here?
A prefix isolates a wine install. Bottles intentionally pushes users into a "one per application" strategy with Wine prefixes, isolating the wine install and deps for that application from other applications. Generally a great strategy for using Wine, even if you'd prefer to do it yourself.
And Bottles is a much more convenient wrapper compared to doing that manually and managing them yourself (which I've also done).
Bottles also distributes the instructions to configure a "generally working" prefix for a large number of desired applications.
If we go back to the docker analogy - they're giving you the Dockerfile, not the image. I'm not actually convinced that's such a "stark" contrast. If anything, it's semantic peanuts (and mostly for legal reasons given the popular applications tend to be copyright protected games, rather than OSS software which makes up most docker images).