[HN Gopher] Bottles - Easily run Windows software on Linux
___________________________________________________________________
Bottles - Easily run Windows software on Linux
Author : manaskarekar
Score : 59 points
Date : 2023-07-04 21:47 UTC (1 hours ago)
(HTM) web link (usebottles.com)
(TXT) w3m dump (usebottles.com)
| pipeline_peak wrote:
| What's the point of this isolated "bottle" concept? It seems like
| the bloated nature of containers is now pouring into emulation.
|
| Why fix underlying problems when you can just put things in a
| bottle/container? Like that won't use more resources.
| worble wrote:
| A bottle is basically just a wine prefix, everything you run in
| that bottle runs in that prefix.
| wtfishackernews wrote:
| Storage space is cheap
| [deleted]
| mmastrac wrote:
| Bottles have been around longer than Linux containers, I'm
| afraid. The world of Windows emulation on Linux pre-bottle was
| extremely difficult to say the least.
|
| 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).
| beebmam wrote:
| Can you explain how containers are bloated?
| denuoweb wrote:
| In my case, BTCPayServer was wrapped in a docker container
| because the developer loves docker... but I took the docker
| out of the project after I forked it because I felt putting
| the project in a docker container was extra bloat that was
| convoluted and unnecessary. In other words, a "container"
| didn't have to wrap the project, it was just implemented
| because of a dev insisting on it. That is bloat to me, extra
| and unnecessary.
| mmastrac wrote:
| It's pretty easy to Google this particular example you've
| cited and see that they have non-docker instructions
| available, and don't recommend them because you can easily
| screw things up.
|
| Seems fair to me.
|
| https://docs.btcpayserver.org/Deployment/ManualDeployment/
| naikrovek wrote:
| given that Docker mostly (entirely?) gives a single UI to
| various related Linux kernel features, I don't see how it
| is bloat at all. Docker just tells the kernel to create a
| separate cgroup and networking, CPU, and RAM namespaces and
| then launches one or more processes within the confines set
| up with those things.
|
| 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.
| tiagod wrote:
| Bloat is relative.
|
| 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.
| xcv123 wrote:
| > That is bloat to me, extra and unnecessary.
|
| 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.
| ghotli wrote:
| You've been downvoted but I suppose I'm willing to ask.
|
| 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.
| LASR wrote:
| > In my case, BTCPayServer was wrapped in a docker
| container because the developer loves docker...
|
| 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.
| Jenk wrote:
| That is remarkably a non-answer.
|
| Not least because you don't even need to run the container
| at all when developing.
| rzzzt wrote:
| Settings like which version of Windows to impersonate, what
| TrueType fonts and DLLs need to be downloaded, what runtime to
| use (classic Wine or Proton), etc. can change from one
| application/game to another.
|
| 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.
| hnlmorg wrote:
| This uses Wine, which isn't emulation.
|
| 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.
| actionfromafar wrote:
| A rose by another name
| xcv123 wrote:
| > Why fix underlying problems when you can just put things in a
| bottle/container? Like that won't use more resources.
|
| 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.
| thriftwy wrote:
| This reminds me of playonlinux tool which does the same with
| reasonable success.
| mordae wrote:
| Just use Lutris. It can fetch various flavours of wine and manage
| your bottles.
|
| https://lutris.net/
| RangerScience wrote:
| How's gaming performance? (It's pretty much the only reason I
| still use Windows at all)
| [deleted]
| mrpippy wrote:
| Basically a free clone of CrossOver, which has used "bottles" to
| refer to separate Wine prefixes for 20 years.
|
| (disclaimer: I work for CodeWeavers)
| nailer wrote:
| I don't work for codeweavers and will still say that this is
| unfairly benefiting from the existing terminology created by
| codeweavers.
|
| They could have literally picked any other name.
| greenknight wrote:
| What if they didnt know about codeweavers using the name?
| Wine goes into bottles (in the real world)... its a play on
| words.
| canadiantim wrote:
| Using Bottles to play ultimate online again, my productivity
| wishes it hadn't been possible tho
| jdright wrote:
| https://crossuo.com/
| XorNot wrote:
| Can this run MS Teams is my question?
| [deleted]
| Kalanos wrote:
| Can I use this and docker at the same time?
| smoldesu wrote:
| Yep.
| Kalanos wrote:
| I attempted to use Wine yesterday to run a Windows app and it
| failed. How is this different from Wine?
| dark-star wrote:
| I am wondering about that as well. I can (and do) use different
| WINEPREFIXes for different programs with regular Wine too.
|
| I assume this just takes the setup of those WINEPREFIXes out of
| the equation? Like having pre-defined
| configs/winetricks/tweaks/DllOverrides/whatever for certain
| games? Maybe with a couple of patches to Wine that are not yet
| upstream?
| throw_m239339 wrote:
| It comes with a bunch of "fixes" (AKA DLL straight from
| Windows) you can optionally download if the app doesn't start.
| I actually managed to run Cinema 4D R21 with Bottles quite
| painlessly. I had harder time installing flatpak (to install
| bottles) on a Porteus distrib than running Cinema 4D.
___________________________________________________________________
(page generated 2023-07-04 23:00 UTC)