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).
>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.
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.
> 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.
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.
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.
It has slightly higher overhead than normal process, because the process will use a different set of userland libraries than your host normally uses (increasing memory usage) and the filesystem inside the container has a high chance to be a convoluted mess of overlaysfs mounts.
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.
Spend the resources and get the reward, or don’t spend the resources and don’t get the reward. That’s not bloat, bloat contributes nothing, it’s just waste.
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.
BTCPayServer’s container setup was quite trivial, granted I used it last a few years ago. I had no issues with the container itself. You are free to install deps in whichever you want, but not sure how containerizing setup makes it bloat and/or unnecessary.
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.
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.
> 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.
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.
wine isn't emulation and wine prefixes are not containers. whenever you use wine you are using a wine prefix. all bottles is is a tool for managing wine prefixes.
I'm sure Microsoft was familiar with not only windows on buildings, but also other OSes' use of the term "window" as a GUI element (dating back to Xerox Alto in 1973), and called their 1985 product "Windows" anyway, so there's precedent.
Microsoft literally researched every tech article about GUIs to extract all the terms journalists used to describe them. They then chose the most common word from all these articles.
I've been using wine for well over a decade and I was not aware of it. I'm not so confident that your characterization here is accurate.
Everyone I know that uses wine just follows some youtube video to get some game working on linux. They don't spend a lot of time learning about the ecosystem.
i've been in linux for decades and listen to multiple linux podcasts every week and follow multiple linux communities. valve, proton, lutris, wine, all of these things are mentioned constantly. codeweavers is mentioned almost never. it definitely isn't living under a rock to not be familiar with codeweavers. i would go so far as to say that most people who use wine have never heard of codeweavers.
I have to partially agree. When I started, codeweaver was hard to miss. I guess it was a different time back then? Must have been 15 years. For me, it was the other way around. My first wine experience was using codeweavers, and then I learned about wine itself. If you searched to run MS Office apps on Linux / Mac, codeweavers was the first result. Perhaps this was only true for Linux beginners. They had (have?) an easy to use commercial wrapper around it, with different Windows apps (especially office) working with no additional configuration.
I think you may be misunderstanding me to say that I was unaware that codeweavers existed, but that wasn't the issue. The issue at hand is whether "bottles" ripped that terminology from codeweavers. I have been plenty aware of codeweavers existence, but that doesn't mean I had any reason to believe they were the originators of using "bottles" to mean what it means today. What my previous comment intended to say, was that I had no idea codeweavers coined the term "bottles" and I don't know that it's fair to assume "bottles" assumed it was something exclusive to codeweavers.
Why would anyone assume that was some pseudo-trademark of codeweavers? It's not particularly clever and anyone could come up with it. I would've assumed literally anyone in the wine ecosystem could've come up with it and given codeweavers (nor anyone else) did not file for a trademark then that suggests they don't care that it was "ripped" from them to begin with.
My whole point of view is that there seems to be some assumption of malice or feelings slighted where there's no evidence that codeweavers feels slighted or that bottles was being malicious. I generally think the internet would be a much better place without assumptions of malice.
Wow that is actually super rude. I paid 500 dollars for crossover and tried to use it and found that it lacked features that bottles offered. To flippantly call it a clone and imply that it doesn't offer anything special is really unnecessary.
Clones can develop their own features and go their own way. I don't think calling something a clone is necessarily rude.
At some point it will be significantly different that it probably shouldn't be called a clone though, but if it currently has the same name as a feature in a pre-existing, popular software, "clone" seems like the right word.
I imagine whomever built "bottles" (the clone, not the Crossover feature), probably used code, or at least was inspired by code, that CodeWeavers upstreamed to Wine.
Basically, that's false information. The reason why Bottles is called that is because, well, wine is normally stored in bottles. I think it's the most straightforward reasoning one can make. (Disclaimer: Bottles creator here).
I have never been inspired by CrossOver, never used CrossOver (maybe the version for Chromebook, but I'm not certain), and was not aware of CrossOver's terminology Taking a look (from what can be understood from the screenshots), well, the two software are extremely different, and the only similarity is actually their purpose, which is to simplify and automate Wine.
If I were you, I wouldn't have mentioned that you're on the CrossOver team because it's not a wise statement to make.
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?
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.
In addition to Windows software, it also works with web applications, DOS, retro computers and consoles as well.
For wine, it has installation scripts that automatically implement the necessary workarounds for specific software. Such as picking a wine version, setting overrides, installing libraries, etc. It also creates a wineprefix for you with a recommended Windows version for that software.
For example, you can get The Sims 1 complete collection from Internet Archive (abandonware at this point), and then add that game to your collection. That will download and run the installation script for it, saving you most of the manual steps involved in installing that game.
On one hand, this is also what I use, and it kind of works.
On the other hand... Wine and NVidia seem to not like each other... at all. Every game will require tinkering with Wine and a bunch of things that are supposed to wortk with various NVidia drivers and video adapters. And there's non-zero chance that it simply won't work. Or won't work with your display manager / desktop manager / monitor connection etc.
For instance, I play GuildWars 2, and after a long struggle to find a Wine version that would work with it, I still cannot get 3rd-party extensions to work (eg. arcdps)... and I abandoned all hope of figuring out why: way too many randomly but similarly named libraries with obscure purpose.
My laptop is all AMD (AMD Ryzen 6800HS) and I think people have rose-colored glasses of the AMD situation. I certainly prefer it for many reasons: it's driver stack is open source, it has full DRI2 support, it works with Wayland, etc. That being said, it has plenty of it's own problems and I've run into many of them with Proton/Wine. I would dare say, more than my Nvidia laptop did (though, this was before Steam Deck launched; so I'm certain of it having improved).
Ironically, Intel's embedded GPUs have the least issues overall; but are the least capable pieces of hardware.
Yeah, I think this is how I feel after using AMD GPUs to try to game on Wine for the past year after a few years of trying nvidia. I definitely prefer AMD, but there are _always_ weird things to try to work around on Wine; for more actively updated games (like MMOs), sometimes things will suddenly stop working even if they were running smoothly for a while. I think things are on average better now than there were a few years ago, and I hope they continue getting better, but right now I'm not sure there's any option for gaming with Wine/proton that doesn't require a lot of tweaking for performance at the moment.
It's not just on Linux though. My wife and I had literally identical setups with the one difference being the video card. I had an AMD card, she a NVidia. And the compatibility issues are real. For a specific example, Nvidia cards and Grim Dawn just don't (or didn't at least) get along, even on Windows - with about a zillion threads of such in the Steam forums for it, indicating it wasn't just e.g. a hardware failure type issue. And that wasn't the only game issues cropped up in. That's when we decided to replace her card with an AMD one, and we've had zero issues since.
Another fun thing (again, on Windows at least) is NVidia's drivers forcibly installing telemetry, even when disabled in the install settings. NVidia was king of cards for quite a number of years, but they're really not the company they once were anymore.
Are AMD cards any use for compute tasks such as machine learning though? I would like to build a gaming PC that I can use for stuff like that as well and I feel like there is no real alternative to CUDA at the moment
I used to have that problem, then just switched to AMD video cards, and it magically went away. It just works. Whatever graphics penalty I pay is unnoticeable in comparison to the time lost troubleshooting and tweaking Nvidia for Wine.
I am running GW2 through Steam Proton on Fedora with a custom install location so I don't have to look through the absolutely obscure (heh, forth expansion pun!) directory structure steam hides its games in. Especially non-native ones.
Even arcdps works w/o issues.
In wine for arcdps to work, a dll-override is needed somewhere in the wine settings in some really weird place.
I don’t know if I’m an outlier as an NVidia guy, but my frank experience is that Lutris is a janky PoS on any distro I’ve ever tried it on (Ubuntu, Manjaro, Arch, NixOS)
Everything I haven’t gotten to work in Lutris has worked in Steam Proton by importing it as a non-Steam game. With far less hassle.
Since Lutris predates Steam Proton and thus likely suffers as a result, I think it’s no longer necessary if you are a Steam user.
The short answer is that you can squeeze some significant extra performance if you are clever, and make it run very close to Windows. If you do absolutely nothing, the baseline is often fine.
It's worth remembering that all of these solutions are Wine (or Proton which is a fork) underneath, it's just a question of packaging.
The Steam Deck is a Linux Gaming machine that uses Proton to make the vast majority of the Steam Library available. It works extremely well on not the most powerful hardware. You can basically play any game as long as it doesn't rely on some hardcore anti-cheat (so counts out some online multiplayer games like R6 Siege).
Bing Chat is also crashing in Firefox on Linux when I go to use it, just the tab itself crashes :c
Microsoft is coming full circle with their most recent embrace, extend, extinguish cycle it seems. Just gotta dodge, duck and dive around any attempts they make to get us dependent on their ecosystem...
Bummer! That sucks as a freelancer with customers frequently relying on MS out of laziness. OTOH, at this point it's just another nail in the coffin for the Linux desktop that ceased to be usable anyway, even for work supported by the few age-old apps it has. Sadly, I can't even say I'm surprised, with Linuxers busy for well over a decade now to dutifully and sheepishly bring their workloads to "the cloud" and Chrome exclusively, and occupied with meta (non-)problems (wayland, containers). Looking forward to projects on Windows notebooks using Docker Desktop on x86!
I just run MS Teams at work using linux port of Microsoft Edge web browser. Handles screen sharing with wayland fine with 2 special arguments added to my local .desktop file that may not even be needed anymore.
I only use Windows because of gaming purposes. Is there anything around the internet that can show benchmarks for something like Bottles vs Proton vs Windows? WSL works well but I’d personally want to stay stick to native and not dual boot.
Honestly proton is really all you need at this point. I've completely switched over to Linux and have had absolutely zero problems. How Linux mint even found all of my drivers for me it took literally no effort.
That being said you can always check proton db to see if your games work with it
plenty of proton games support online multiplayer (natively or otherwise), its just games which use EAC thats the problem. Even then it can be fixed with (what I've heard) minimal work from the developer, but sadly thats still not quite universal.
I think there are a few other anti-cheats which can be problematic, but again I think it can be worked around
Yeh see I was thinking of FACEIT because I heard reports that Battlebit (which uses FACEIT) wouldnt work on the steam deck, but checking protondb it seems it runs fine, so I guess there are workarounds.
Wouldn't doubt that Ricochet and Vanguard have no support for it at all though
You're right, they talked about adding Faceit AC, but they still need time. Once they actually implement Faceit and and thereby block Steam Deck/proton users. At that point Battlebit simply won't work anymore. (Hopefully Steam'll refund my game or BB will have good community servers.)
Oh, my assumption was that they either found a way to make FACEIT work with proton or dropped it due to the lack of support. Seems odd that they'd plan to update a game that actively eliminates a section of the playerbase, especially for a multiplayer game from a relatively small studio that relies on having a big enough playerbase for the game to function
Another is peripheral support. I have a trackir which doesn't really work right in Linux on the games I'd like to use it. It also takes a lot more fiddling to get even supported devices (like my Logitech gaming wheel) working correctly.
Same, it really is amazing coming from the days of using Lokis and WineX and Wine trying to make things work. It was often a struggle but still some triple A games would work out of the box back then, COD1+2, quake 4 had a linux installer, MoH: Pacific Assault.
No, the best solution is just to use protondb and see if it works there, and read some comments. Then try it. Performance really doesn't matter for most titles because generally speaking the first problem is "Does it work under Proton or not" and then "Does it work reliably." You can get the Proton build of Wine a number of ways like Lutris, from what I understand, or just install Steam on Linux.
Again, do not read what anyone says as gospel, check the games you have and want to play even if people say they're perfect. Lots of things work but a lot of high-profile stuff still doesn't, so it won't work for everybody. And if a game requires 20 minutes of fucking around to get working reliably, it's very possibly not worth it; but IME people who desperately want to use Linux will excuse any amount of issues except for literally not being able to boot.[1] For example, Dragon Ball FighterZ and Destiny 2 don't work well under Proton (for different reasons) but ultimately, I have to use Windows as a result, no matter what anyone says here. Lots of games do work on my Steam Deck though, so that's nice.
[1] You can find tons of reports on ProtonDB like the following: marked "Playable", but then it says "You must launch the game with a custom environment variable to boot it, then it will crash every 10 minutes, which sucks, but it's playable." Literally the definition of "not playable" by any metric...
Specifically which part of "record the variables" do you not understand?
The amount of variables simply has no impact on the difficulty of running a benchmark. The amount of variables will impact the relevance or use value of the benchmark, but interpretation and application is the user's problem. The amount of variables has zero impact on the process of performing or recording the benchmark, and this matters because interpretation and application is easier with more benchmarks covering more cases, but your insistence that it's "hard" could only reduce that number, making you the only variable that is actually a problem.
I have not done extensive testing and the testing I have done is only on the Steam Deck.
I found that when comparing a normal Windows 10 installation to SteamOS, SteamOS performed better (slightly more consistent FPS and better battery).
When I switched to the LTS version of Windows 10 (which doesn't have a lot of the bloat in it and you don't run the risk of screwing things up by running a debloat tool) I got slightly better performance on Windows than I did on SteamOS.
This is also not on a higher end PC. I choose to keep my gaming PC windows right now just to not deal with lower performance, I paid a lot for this computer since I value performance on it.
I will say however that I am finding myself using Windows on my Steam Deck more often. Like right now I am replaying through the Kingdom Hearts series. It feels like jumping through hoops to get that to work on SteamOS where on Windows I just installed the Heroic Game Launcher (alternate app for epic games), installed it and it just works.
Cool, but after reading "All the gaming platforms you already know, right here" and searching for Xbox Game Pass or Forza Horizon and finding nothing, I gave up.
they do not use winetricks. they built their own system for installing dependencies and managing prefixes. you are right that it fills the same role, but that's not what you asked. it also does a lot more than just the things that winetricks does.
Haven't used winetricks in what feels like 10+ years, but as I recall it only dealt with a single wine prefix (~/.wine most likely). Bottles are namespaced prefixes (usually one for each application installed this way).
I don't know in practice how much that is needed in wine in order to avoid one "trick" interfering with another "trick" for another app. However, makes it easier to remove the extra cruft of uninstalled applications (like the dozen variants of the .net runtime, or whatever else it was that you had to install ad-nauseum in the past for some windows apps/games).
While the Windows OS is far from perfect, it's always going to be better than one of these emulator projects. I know that wine is mature etc etc but at the end of the day, if you want to run Windows software, just run Windows.
I can't find anything that does. It's like they intentionally wrote their software so that it can't work with anything. I wish they would just give us a proper linux release. makes me sad.
Between Steam and Heroic Launcher ( Epic and GOG client) I've been having a really good gaming experience on Linux. Things just work and the UIs are really polished.
This looks great too.
Get the FlatPak version of Heroic Launcher as it does a lot of tricks out of the box, like letting you be seen as online by friends to be added directly to games, cloud save and dealing with DRM
I think so, but the solution may be convoluted. Waydroid users can spin up an Android container to run Roblox post-Wine ban: https://youtu.be/E0BLQCEU8ZI
It's like one of those "edit Windows Registry to get around the library time restrictions" videos from 2009. The fact that I'm seeing these for Linux is a sign that nature is healing, I think.
Semi-related: Having no windows machine or console, I recently tried out one of those gaming streaming services to play Diablo IV and wow: 10 bucks/month to be able to play it without the need to tinker with anything or building a PC.
Getting 30ms latency is good enough for this casual gamer.
I'm still astonished that I could have a better experience playing Cyberpunk 2077 on Stadia that's hosted in ??? than I could have playing Ghostwire: Tokyo that was hosted on another computer in my local network, connected to the same Gigabit switch. Stadia had both lower input latency and higher stream quality.
I have long had a theory for why Stadia handled CP77 so well compared to the other platforms. CDPRs management of CP77s development was, to put it mildly, less than ideal and any extensive period of crunch will always come at the detriment of the employer's health (both mental and physical) and the quality of the end product. Personally, I always view crunch on any project as a failure, most often by management.
CDPR higher-ups though, in large part fueled by experiences with similar situations that lead to success in the past[0], were unconcerned by. If the situation had stayed similar to The Witcher 3s last few months of development, CP77 would have potentially still released in a less than perfect state (considering W3s bugs at launch, new technology, more SKUs, less dev time overall and any form of crunch, in my opinion, being a failure in itself), but likely not nearly as bad as what we ended up getting. COVID-19 happened though, as we all know, and that had its fair share of consequences for everyone and everything involved.
What I'd like to focus on are dev kits. PC gaming has the up- and downsides that come with flexible hardware choices, leading to consoles generally having more targeted optimization and often receiving more testing. But when dev kits are inaccessible due to agreements with manufacturers, those become impossible.
Stadia though, for all its flaws, had two key advantages in the work-from-home world. Whilst physical devkits exist for Stadia, they also offered the ability to access development environments via the internet[1]. Because Stadia was a targeted platform with one specific, testable hardware configuration (like a console), but allowed development and QA from anywhere with a decent internet connection, that likely explains why the Stadia version at launch was more playable and stable than any console SKU or PC experience.
There was, as far as I know, never any public confirmation of this speculation and as Stadia has seized to be, we will likely never know, but this always seemed like a reasonable assumption to me.
Bottles for me fills a very specific niche that nobody else does: launching multiple apps in the same prefix.
For example, if I want to launch Titanfall 2+ Northstar, I need to launch a Northstar launcher in the same prefix as the EA launcher (nowadays these Northstar launchers have a button to launch the EA launcher so it's no longer an issue but still). Each bottle feels like a separate windows install, so if you need a dependency that's not bundled you can just press the big "launch program from file" button and go on with your day.
Games that are DRM free and programs that you download on windows in general can be installed in proton or lutris but doing it always feels like a hack. On the flip side, using bottles is just "launch installer, an entry for the installed program is added". It really is a fantastic piece of software.
197 comments
[ 3.3 ms ] story [ 187 ms ] threadWhy fix underlying problems when you can just put things in a bottle/container? Like that won’t use more resources.
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.
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.
https://docs.btcpayserver.org/Deployment/ManualDeployment/
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.
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.
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.
that Wine is not an emulator is a good tagline, but it emulates Windows behaviour really well.
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.
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.
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.
(disclaimer: I work for CodeWeavers)
They could have literally picked any other name.
Everyone I know that uses wine just follows some youtube video to get some game working on linux. They don't spend a lot of time learning about the ecosystem.
Why would anyone assume that was some pseudo-trademark of codeweavers? It's not particularly clever and anyone could come up with it. I would've assumed literally anyone in the wine ecosystem could've come up with it and given codeweavers (nor anyone else) did not file for a trademark then that suggests they don't care that it was "ripped" from them to begin with.
My whole point of view is that there seems to be some assumption of malice or feelings slighted where there's no evidence that codeweavers feels slighted or that bottles was being malicious. I generally think the internet would be a much better place without assumptions of malice.
> and CodeWeavers’ usage of it.
To clarify, what do you mean by this? Does CodeWeavers use the term "Wine" somewhere in a product? (I thought that's CrossOver?)
Seems like a stretch. I don't see a problem with reusing good terminology. It's not like it's trademarked.
I can see "bottles" becoming the generic term, it makes more sense than "prefixes".
(disclaimer: I don't work for CodeWeavers)
At some point it will be significantly different that it probably shouldn't be called a clone though, but if it currently has the same name as a feature in a pre-existing, popular software, "clone" seems like the right word.
I imagine whomever built "bottles" (the clone, not the Crossover feature), probably used code, or at least was inspired by code, that CodeWeavers upstreamed to Wine.
I have never been inspired by CrossOver, never used CrossOver (maybe the version for Chromebook, but I'm not certain), and was not aware of CrossOver's terminology Taking a look (from what can be understood from the screenshots), well, the two software are extremely different, and the only similarity is actually their purpose, which is to simplify and automate Wine.
If I were you, I wouldn't have mentioned that you're on the CrossOver team because it's not a wise statement to make.
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?
https://lutris.net/
For wine, it has installation scripts that automatically implement the necessary workarounds for specific software. Such as picking a wine version, setting overrides, installing libraries, etc. It also creates a wineprefix for you with a recommended Windows version for that software.
For example, you can get The Sims 1 complete collection from Internet Archive (abandonware at this point), and then add that game to your collection. That will download and run the installation script for it, saving you most of the manual steps involved in installing that game.
https://wiki.playonlinux.com/index.php/Installing_PlayOnMac
https://github.com/IsaacMarovitz/Whisky
On the other hand... Wine and NVidia seem to not like each other... at all. Every game will require tinkering with Wine and a bunch of things that are supposed to wortk with various NVidia drivers and video adapters. And there's non-zero chance that it simply won't work. Or won't work with your display manager / desktop manager / monitor connection etc.
For instance, I play GuildWars 2, and after a long struggle to find a Wine version that would work with it, I still cannot get 3rd-party extensions to work (eg. arcdps)... and I abandoned all hope of figuring out why: way too many randomly but similarly named libraries with obscure purpose.
Ironically, Intel's embedded GPUs have the least issues overall; but are the least capable pieces of hardware.
Another fun thing (again, on Windows at least) is NVidia's drivers forcibly installing telemetry, even when disabled in the install settings. NVidia was king of cards for quite a number of years, but they're really not the company they once were anymore.
That's coming from someone who just ordered a 7900xtx anyway.
In wine for arcdps to work, a dll-override is needed somewhere in the wine settings in some really weird place.
Everything I haven’t gotten to work in Lutris has worked in Steam Proton by importing it as a non-Steam game. With far less hassle.
Since Lutris predates Steam Proton and thus likely suffers as a result, I think it’s no longer necessary if you are a Steam user.
The ArchWiki has some tips that can help tuning your system: https://wiki.archlinux.org/title/gaming
This launcher does help too: https://github.com/FeralInteractive/gamemode
On top of that, you can use a patched kernel like: https://xanmod.org/
You can check support status for games here: https://www.protondb.com/
If you run games via Proton with DXVK, you can use the environment variable DXVK_HUD=1 to show a HUD with a FPS meter. Some others prefer mangohud.
Setting your CPU frequency scaling governor and GPU to performance mode also helps.
In some obscure cases, removing unused network interfaces will make Windows games that use certain Windows APIs run significantly faster.
Proton is known to interfere with controller support so disabling steam input + overriding DirectInput DLLs can be helpful in some cases.
https://www.gloriouseggroll.tv/how-to-get-out-of-wine-depend...
The Steam Deck is a Linux Gaming machine that uses Proton to make the vast majority of the Steam Library available. It works extremely well on not the most powerful hardware. You can basically play any game as long as it doesn't rely on some hardcore anti-cheat (so counts out some online multiplayer games like R6 Siege).
There's so much focus on video games.
Edit: Luckily I haven't had the displeasure of using MS Teams a couple of years, so I didn't know it was discontinued on Linux.
https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
https://techcommunity.microsoft.com/t5/microsoft-teams/end-o...
Bing Chat is also crashing in Firefox on Linux when I go to use it, just the tab itself crashes :c
Microsoft is coming full circle with their most recent embrace, extend, extinguish cycle it seems. Just gotta dodge, duck and dive around any attempts they make to get us dependent on their ecosystem...
Not sure what nail you are talking about.
This is annoying because Firefox containers are ideal for managing the multiple teams sessions I have for different clients.
That being said you can always check proton db to see if your games work with it
EAC for Linux works
I think there are a few other anti-cheats which can be problematic, but again I think it can be worked around
But many other AC's like EA's Ricochet, Vanguard or Faceit AC don't support proton at all.
Wouldn't doubt that Ricochet and Vanguard have no support for it at all though
And that's without even considering vr goggles...
Again, do not read what anyone says as gospel, check the games you have and want to play even if people say they're perfect. Lots of things work but a lot of high-profile stuff still doesn't, so it won't work for everybody. And if a game requires 20 minutes of fucking around to get working reliably, it's very possibly not worth it; but IME people who desperately want to use Linux will excuse any amount of issues except for literally not being able to boot.[1] For example, Dragon Ball FighterZ and Destiny 2 don't work well under Proton (for different reasons) but ultimately, I have to use Windows as a result, no matter what anyone says here. Lots of games do work on my Steam Deck though, so that's nice.
[1] You can find tons of reports on ProtonDB like the following: marked "Playable", but then it says "You must launch the game with a custom environment variable to boot it, then it will crash every 10 minutes, which sucks, but it's playable." Literally the definition of "not playable" by any metric...
- what kernel you used + which settings
- what CPU model you used? what security mitigations were enabled?
- GPU model, GPU driver version, GPU driver configuration settings
- what wine version you used (e.g.: wine stable, staging, devel? proton? glorious eggroll? custom?)
- what wine settings you used: overrides, Windows version, installed libraries, etc.
- did it use the gamemode launcher or similar?
Playing with those knobs have a big impact on performance.
When running on wine, we could say that how you are running a game can have as much on performance impact as your specs.
Identifying the differences between setups is hard.
The amount of variables simply has no impact on the difficulty of running a benchmark. The amount of variables will impact the relevance or use value of the benchmark, but interpretation and application is the user's problem. The amount of variables has zero impact on the process of performing or recording the benchmark, and this matters because interpretation and application is easier with more benchmarks covering more cases, but your insistence that it's "hard" could only reduce that number, making you the only variable that is actually a problem.
I found that when comparing a normal Windows 10 installation to SteamOS, SteamOS performed better (slightly more consistent FPS and better battery).
When I switched to the LTS version of Windows 10 (which doesn't have a lot of the bloat in it and you don't run the risk of screwing things up by running a debloat tool) I got slightly better performance on Windows than I did on SteamOS.
This is also not on a higher end PC. I choose to keep my gaming PC windows right now just to not deal with lower performance, I paid a lot for this computer since I value performance on it.
I will say however that I am finding myself using Windows on my Steam Deck more often. Like right now I am replaying through the Kingdom Hearts series. It feels like jumping through hoops to get that to work on SteamOS where on Windows I just installed the Heroic Game Launcher (alternate app for epic games), installed it and it just works.
FH4 works out of the box on proton btw, at least when I did it via steam.
> The most popular gaming platforms (Epic Games Store, GOG Galaxy, Origin, Battle.net, EA Games..) are already available as an installer in Bottles.
They even put an "Available Installers"-button right below.
Xbox Game Pass won't work on Linux until MS decides they want to, and I don't see that happening.
aaaand done
https://usebottles.com/appstore/
I don't know in practice how much that is needed in wine in order to avoid one "trick" interfering with another "trick" for another app. However, makes it easier to remove the extra cruft of uninstalled applications (like the dozen variants of the .net runtime, or whatever else it was that you had to install ad-nauseum in the past for some windows apps/games).
Bottles: GUI front end to run Windows software on Linux - https://news.ycombinator.com/item?id=29612976 - Dec 2021 (237 comments)
Lutris tries but it still can't handle it.
https://usebottles.com/app/#fusion360
This looks great too.
Get the FlatPak version of Heroic Launcher as it does a lot of tricks out of the box, like letting you be seen as online by friends to be added directly to games, cloud save and dealing with DRM
Getting 30ms latency is good enough for this casual gamer.
CDPR higher-ups though, in large part fueled by experiences with similar situations that lead to success in the past[0], were unconcerned by. If the situation had stayed similar to The Witcher 3s last few months of development, CP77 would have potentially still released in a less than perfect state (considering W3s bugs at launch, new technology, more SKUs, less dev time overall and any form of crunch, in my opinion, being a failure in itself), but likely not nearly as bad as what we ended up getting. COVID-19 happened though, as we all know, and that had its fair share of consequences for everyone and everything involved.
What I'd like to focus on are dev kits. PC gaming has the up- and downsides that come with flexible hardware choices, leading to consoles generally having more targeted optimization and often receiving more testing. But when dev kits are inaccessible due to agreements with manufacturers, those become impossible.
Stadia though, for all its flaws, had two key advantages in the work-from-home world. Whilst physical devkits exist for Stadia, they also offered the ability to access development environments via the internet[1]. Because Stadia was a targeted platform with one specific, testable hardware configuration (like a console), but allowed development and QA from anywhere with a decent internet connection, that likely explains why the Stadia version at launch was more playable and stable than any console SKU or PC experience.
There was, as far as I know, never any public confirmation of this speculation and as Stadia has seized to be, we will likely never know, but this always seemed like a reasonable assumption to me.
[0] https://www.eurogamer.net/cd-projekt-red-this-approach-to-ma...
[1] https://developers.google.com/stadia-dev/cloud-identity-gsui...
For example, if I want to launch Titanfall 2+ Northstar, I need to launch a Northstar launcher in the same prefix as the EA launcher (nowadays these Northstar launchers have a button to launch the EA launcher so it's no longer an issue but still). Each bottle feels like a separate windows install, so if you need a dependency that's not bundled you can just press the big "launch program from file" button and go on with your day.
Games that are DRM free and programs that you download on windows in general can be installed in proton or lutris but doing it always feels like a hack. On the flip side, using bottles is just "launch installer, an entry for the installed program is added". It really is a fantastic piece of software.
What's a "prefix" in this context?